Re: [U-Boot] [PATCH RFCv2 0/6] Beginning of migration of MPC8xx to DM model

2018-05-03 Thread Christophe LEROY

Hello,


Le 16/03/2018 à 17:32, Christophe Leroy a écrit :

This serie is the beginning of MPC8xx migration to DM model.


I didn't get any feedback on this serie. I don't feel totally 
confortable as it is my first implementation of DM and also the first 
time powerpc uses DT for U-boot.


I'd rather someone look at it.

Thanks
Christophe




It applies on top of the serie "[v4] Powerpc: mpc8xx: cleanup before migration to DM 
model"

Christophe Leroy (6):
   board: MCR3000: Activate CONFIG_DM and CONFIG_OF_CONTROL
   drivers: watchdog: add a DM driver for the MPC8xx watchdog
   board: MCR3000: use new DM watchdog
   drivers: serial: migrate mpc8xx to DM
   board: MCR3000: migrate to DM_SERIAL
   drivers: serial: get rid of non DM mpc8xx driver

Change since initial RFC:
   Migrated serial driver in addition
   Few changes on the watchdog

  arch/powerpc/dts/Makefile  | 16 ++
  arch/powerpc/dts/mcr3000.dts   | 22 ++
  board/cssi/MCR3000/MCR3000.c   | 16 ++
  board/cssi/MCR3000/u-boot.lds  |  6 
  configs/MCR3000_defconfig  |  6 
  drivers/serial/serial.c|  2 --
  drivers/serial/serial_mpc8xx.c | 66 ++
  drivers/watchdog/Kconfig   |  7 +
  drivers/watchdog/mpc8xx_wdt.c  | 51 
  include/configs/MCR3000.h  |  1 +
  include/serial.h   |  1 -
  11 files changed, 159 insertions(+), 35 deletions(-)
  create mode 100644 arch/powerpc/dts/Makefile
  create mode 100644 arch/powerpc/dts/mcr3000.dts


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


Re: [U-Boot] mainline u-boot on radxarock (rockchip rk3188) from SDcard

2018-05-03 Thread Jaehoon Chung
Dear Trevor,

On 05/04/2018 12:13 AM, Trevor Woerner wrote:
> Hi Jaehoon and Kever,
> 
> On Wed, May 2, 2018 at 4:11 AM, Jaehoon Chung 
> wrote:
> 
>> Hi,
>>
>> On 05/02/2018 04:10 PM, Kever Yang wrote:
>>> Hi Trevor,
>>>
>>> It looks like the mmc driver does not work correctly, and no
>>> emmc/sdcard found.
>>>
>>> Maybe you can enable 'DEBUG' and get more detail about what happen.
>>
> 
> Is enabling DEBUG just a matter of increasing the logging levels
> (CONFIG_LOGLEVEL and CONFIG_LOG_MAX_LEVEL) to 7, or is something else
> required?

I think you can just add the CONFIG_MMC_TRACE in include/configs/.h
Then we can see the command sequence. It's helpful to debug.

> 
> 
>>>
>>>
>>> Thanks,
>>> - Kever
>>> On 04/29/2018 01:35 PM, Trevor Woerner wrote:
 Hello,

 I am able to generate a bootable image (bootloader, parameter, kernel,
 filesystem) for my radxarock (pro) on an SDcard if I use the bootloader
>> from
 https://github.com/radxa/u-boot-rockchip. When I try to use mainline
 u-boot_2008.01 it doesn't seem to be able to find or boot from the
>> SDcard:
>>
>> Do you use the dwmmc driver? or which driver are you using?
>> And Could you share which defconfig is used?
>>
>> Plz, CC'd me.
>>
>>
> I'm using rock_defconfig, currently without any changes, as such
> MMC_DW_ROCKCHIP is enabled.

Did you try to check v2018.03? Your log seems that "didn't initialize any card."
You didn't any change? Your bootloader added "-dirty"

U-Boot 2018.01-dirty (Apr 29 2018 - 05:19:18 +)

When i didn't work SD-card or eMMC, i follow the below sequence.

1. Check the correct gpio and power.
2. Check the device tree.
3. Check the clock.
4. And then check the device driver.
5. Check the mmc core.

Now. I need to get your information more.
dt file, board name, etc...

If you have a version that it's working fine, then you can try to find a 
trouble patch with git bisect command.

Best Regards,
Jaehoon Chung

> 

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


Re: [U-Boot] Logo for U-Boot

2018-05-03 Thread Marek Vasut
On 05/03/2018 11:57 PM, Alexander Graf wrote:
> 
> 
> On 01.05.18 04:09, Marek Vasut wrote:
>> On 04/30/2018 08:22 PM, Heinrich Schuchardt wrote:
>>> U-Boot has currently no logo that we can use in presentations.
>>>
>>> On the U-Boot IRC channel the following propositions where made:
>>>
>>> Source: https://commons.wikimedia.org/wiki/File:Circle-icons-submarine.svg
>>> License: GPL2+
>>> (Alex used this in some presentations.)
>>
>> Yellow submarine, nice.
>>
>> Maybe we should make it a bit more toward teal and orange to improve the
>> contrast ? Although, maybe just replacing the depressive gray background
>> with a light blue one would do.
> 
> How about this?
> 
>   http://csgraf.de/tmp2/uboot.svg

Lacks the teal.

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


Re: [U-Boot] [PATCH 2/2] net: add Kconfig for MVGBE

2018-05-03 Thread Chris Packham
On Fri, May 4, 2018 at 9:36 AM Joe Hershberger 
wrote:

> On Thu, May 3, 2018 at 6:00 AM, Chris Packham 
wrote:
> > Add Kconfig for MVGBE and update boards to select this.
> >
> > Signed-off-by: Chris Packham 
> > ---
> >
> >  arch/arm/mach-kirkwood/include/mach/config.h | 1 -
> >  configs/d2net_v2_defconfig   | 2 ++
> >  configs/dns325_defconfig | 2 ++
> >  configs/dockstar_defconfig   | 2 ++
> >  configs/dreamplug_defconfig  | 2 ++
> >  configs/ds109_defconfig  | 2 ++
> >  configs/goflexhome_defconfig | 2 ++
> >  configs/guruplug_defconfig   | 2 ++
> >  configs/ib62x0_defconfig | 2 ++
> >  configs/iconnect_defconfig   | 2 ++
> >  configs/inetspace_v2_defconfig   | 2 ++
> >  configs/km_kirkwood_128m16_defconfig | 2 ++
> >  configs/km_kirkwood_defconfig| 2 ++
> >  configs/km_kirkwood_pci_defconfig| 2 ++
> >  configs/kmcoge5un_defconfig  | 2 ++
> >  configs/kmnusa_defconfig | 2 ++
> >  configs/kmsugp1_defconfig| 2 ++
> >  configs/kmsuv31_defconfig| 2 ++
> >  configs/lschlv2_defconfig| 2 ++
> >  configs/lsxhl_defconfig  | 2 ++
> >  configs/mgcoge3un_defconfig  | 2 ++
> >  configs/nas220_defconfig | 2 ++
> >  configs/net2big_v2_defconfig | 2 ++
> >  configs/netspace_lite_v2_defconfig   | 2 ++
> >  configs/netspace_max_v2_defconfig| 2 ++
> >  configs/netspace_mini_v2_defconfig   | 2 ++
> >  configs/netspace_v2_defconfig| 2 ++
> >  configs/nsa310s_defconfig| 2 ++
> >  configs/openrd_base_defconfig| 2 ++
> >  configs/openrd_client_defconfig  | 2 ++
> >  configs/openrd_ultimate_defconfig| 2 ++
> >  configs/pogo_e02_defconfig   | 2 ++
> >  configs/portl2_defconfig | 2 ++
> >  configs/sheevaplug_defconfig | 2 ++

> Would it be better to default y if KIRKWOOD || ORION5X? That's a fair
> number of defconfigs.

I thought about that. But we'd still need to set CONFIG_NETDEVICES=y so
even if CONFIG_MVGBE defaulted to enabled we'd still need to touch them.

> Maybe far fewer boards don't have it enabled?

As far as I can tell "far fewer" == 0 because the old code automatically
enabled it if CONFIG_CMD_NET was set. I'm not sure if any of these boards
used other Ethernet devices (USB or PCI) instead of the built-in port(s)
and it would be hard to find out without inspecting each one.

> >  drivers/net/Kconfig  | 8 
> >  include/configs/edminiv2.h   | 1 -
> >  include/configs/km/km_arm.h  | 1 -
> >  37 files changed, 74 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-kirkwood/include/mach/config.h
b/arch/arm/mach-kirkwood/include/mach/config.h
> > index 9d6ad5387c7c..5772182babf2 100644
> > --- a/arch/arm/mach-kirkwood/include/mach/config.h
> > +++ b/arch/arm/mach-kirkwood/include/mach/config.h
> > @@ -78,7 +78,6 @@
> >  #ifdef CONFIG_CMD_NET
> >  #define CONFIG_NETCONSOLE  /* include NetConsole support   */
> >  #define CONFIG_MII /* expose smi ove miiphy interface */
> > -#define CONFIG_MVGBE   /* Enable Marvell Gbe Controller Driver
*/
> >  #define CONFIG_SYS_FAULT_ECHO_LINK_DOWN/* detect link using
phy */
> >  #define CONFIG_ENV_OVERWRITE   /* ethaddr can be reprogrammed */
> >  #define CONFIG_RESET_PHY_R /* use reset_phy() to init mv8831116
PHY */

> [ ... ]

> > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > index 3a374d887183..c962d7a72c0c 100644
> > --- a/drivers/net/Kconfig
> > +++ b/drivers/net/Kconfig
> > @@ -178,6 +178,14 @@ config FTMAC100
> > help
> >   This MAC is present in Andestech SoCs.
> >
> > +config MVGBE
> > +   bool "Marvell Orion5x/Kirkwood network interface support"
> > +   depends on KIRKWOOD || ORION5X
> > +   select PHYLIB
> > +   help
> > + This driver supports the network interface units in the
> > + Marvell Orion5x and Kirkwood SoCs

> Please remove CONFIG_MVGBE from scripts/config_whitelist.txt

Yeah sorry keep forgetting. moveconfig.py failed me on this one because I
needed to add CONFIG_NETDEVICES as well so I had to do a bit of a manual
process. Will include in v2.

> > +
> >  config MVNETA
> > bool "Marvell Armada XP/385/3700 network interface support"
> > depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
> > diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h
> > index 6a92e7fde816..ee63311b4759 100644
> > --- a/include/configs/edminiv2.h
> > +++ b/include/configs/edminiv2.h
> > @@ -118,7 

[U-Boot] [PATCH v2 2/2] drivers: spi: migrate cf_spi to DM

2018-05-03 Thread Angelo Dureghello
This patch adds DM support to cf_spi.c.

---
Changes from v1:
- split into 2 patches

Signed-off-by: Angelo Dureghello 
---
 drivers/spi/cf_spi.c| 406 +++-
 include/dm/platform_data/spi_coldfire.h |  22 ++
 2 files changed, 278 insertions(+), 150 deletions(-)
 create mode 100644 include/dm/platform_data/spi_coldfire.h

diff --git a/drivers/spi/cf_spi.c b/drivers/spi/cf_spi.c
index 68317ed633..ae8b7ef524 100644
--- a/drivers/spi/cf_spi.c
+++ b/drivers/spi/cf_spi.c
@@ -6,16 +6,23 @@
  * Copyright (C) 2004-2009 Freescale Semiconductor, Inc.
  * TsiChung Liew (tsi-chung.l...@freescale.com)
  *
+ * Support for device model:
+ * Copyright (C) 2018 Angelo Dureghello 
+ *
  * SPDX-License-Identifier:GPL-2.0+
  */
 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 
-struct cf_spi_slave {
+struct coldfire_spi_priv {
+#ifndef CONFIG_DM_SPI
struct spi_slave slave;
+#endif
uint baudrate;
int charbit;
 };
@@ -39,12 +46,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define SPI_MODE_MOD   0x0020
 #define SPI_DBLRATE0x0010
 
-static inline struct cf_spi_slave *to_cf_spi_slave(struct spi_slave *slave)
-{
-   return container_of(slave, struct cf_spi_slave, slave);
-}
-
-static void cfspi_init(void)
+static void __spi_init(void)
 {
volatile dspi_t *dspi = (dspi_t *) MMAP_DSPI;
 
@@ -82,7 +84,123 @@ static void cfspi_init(void)
 #endif
 }
 
-static void cfspi_tx(u32 ctrl, u16 data)
+int __spi_set_speed(struct coldfire_spi_priv *cfspi, uint bus, uint mode)
+{
+   /*
+* bit definition for mode:
+* bit 31 - 28: Transfer size 3 to 16 bits
+* 27 - 26: PCS to SCK delay prescaler
+* 25 - 24: After SCK delay prescaler
+* 23 - 22: Delay after transfer prescaler
+* 21 : Allow overwrite for bit 31-22 and bit 20-8
+* 20 : Double baud rate
+* 19 - 16: PCS to SCK delay scaler
+* 15 - 12: After SCK delay scaler
+* 11 -  8: Delay after transfer scaler
+*  7 -  0: SPI_CPHA, SPI_CPOL, SPI_LSB_FIRST
+*/
+   volatile dspi_t *dspi = (dspi_t *)MMAP_DSPI;
+   int prescaler[] = { 2, 3, 5, 7 };
+   int scaler[] = {
+   2, 4, 6, 8,
+   16, 32, 64, 128,
+   256, 512, 1024, 2048,
+   4096, 8192, 16384, 32768
+   };
+   int i, j, pbrcnt, brcnt, diff, tmp, dbr = 0;
+   int best_i, best_j, bestmatch = 0x7FFF, baud_speed;
+   u32 bus_setup = 0;
+
+   tmp = (prescaler[3] * scaler[15]);
+   /* Maximum and minimum baudrate it can handle */
+   if ((cfspi->baudrate > (gd->bus_clk >> 1)) ||
+   (cfspi->baudrate < (gd->bus_clk / tmp))) {
+   printf("Exceed baudrate limitation: Max %d - Min %d\n",
+  (int)(gd->bus_clk >> 1), (int)(gd->bus_clk / tmp));
+   return -1;
+   }
+
+   /* Activate Double Baud when it exceed 1/4 the bus clk */
+   if ((CONFIG_SYS_DSPI_CTAR0 & DSPI_CTAR_DBR) ||
+   (cfspi->baudrate > (gd->bus_clk / (prescaler[0] * scaler[0] {
+   bus_setup |= DSPI_CTAR_DBR;
+   dbr = 1;
+   }
+
+   /* Overwrite default value set in platform configuration file */
+   if (mode & SPI_MODE_MOD) {
+   /*
+* Check to see if it is enabled by default in platform
+* config, or manual setting passed by mode parameter
+*/
+   if (mode & SPI_DBLRATE) {
+   bus_setup |= DSPI_CTAR_DBR;
+   dbr = 1;
+   }
+   }
+
+   pbrcnt = sizeof(prescaler) / sizeof(int);
+   brcnt = sizeof(scaler) / sizeof(int);
+
+   /* baudrate calculation - to closer value, may not be exact match */
+   for (best_i = 0, best_j = 0, i = 0; i < pbrcnt; i++) {
+   baud_speed = gd->bus_clk / prescaler[i];
+   for (j = 0; j < brcnt; j++) {
+   tmp = (baud_speed / scaler[j]) * (1 + dbr);
+
+   if (tmp > cfspi->baudrate)
+   diff = tmp - cfspi->baudrate;
+   else
+   diff = cfspi->baudrate - tmp;
+
+   if (diff < bestmatch) {
+   bestmatch = diff;
+   best_i = i;
+   best_j = j;
+   }
+   }
+   }
+   bus_setup |= (DSPI_CTAR_PBR(best_i) | DSPI_CTAR_BR(best_j));
+   dspi->ctar[bus] |= bus_setup;
+
+   return 0;
+}
+
+static int __spi_set_mode(struct coldfire_spi_priv *cfspi, uint bus, uint mode)
+{
+   volatile dspi_t *dspi = (dspi_t *)MMAP_DSPI;
+   u32 bus_setup = 0;
+
+   if (mode & SPI_CPOL)
+   bus_setup |= DSPI_CTAR_CPOL;
+   if (mode & SPI_CPHA)
+   bus_setup |= 

[U-Boot] [PATCH v2 1/2] drivers; add DM_NO_OF Kconfig option

2018-05-03 Thread Angelo Dureghello
To be able to build spi driver with DM support, a new config
option has been introduced (DM_NO_OF) since m68k architecture
does not support fdt.

---
Changes from v1:
- split into 2 patches

Signed-off-by: Angelo Dureghello 
---
 arch/Kconfig |  1 +
 drivers/core/Kconfig |  4 
 drivers/spi/spi-uclass.c | 12 +++-
 3 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index dd5a887001..c96cbfa2bd 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -28,6 +28,7 @@ config M68K
select HAVE_PRIVATE_LIBGCC
select SYS_BOOT_GET_CMDLINE
select SYS_BOOT_GET_KBD
+   select DM_NO_OF
 
 config MICROBLAZE
bool "MicroBlaze architecture"
diff --git a/drivers/core/Kconfig b/drivers/core/Kconfig
index e8ba20ca82..47960a8a6a 100644
--- a/drivers/core/Kconfig
+++ b/drivers/core/Kconfig
@@ -244,4 +244,8 @@ config DM_DEV_READ_INLINE
bool
default y if !OF_LIVE
 
+config DM_NO_OF
+   bool
+   default n
+
 endmenu
diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index 15d90a54a1..908be1d4cf 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -107,7 +107,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen,
return dm_spi_xfer(slave->dev, bitlen, dout, din, flags);
 }
 
-#if !CONFIG_IS_ENABLED(OF_PLATDATA)
+#if !CONFIG_IS_ENABLED(OF_PLATDATA) && !defined(CONFIG_DM_NO_OF)
 static int spi_child_post_bind(struct udevice *dev)
 {
struct dm_spi_slave_platdata *plat = dev_get_parent_platdata(dev);
@@ -121,7 +121,7 @@ static int spi_child_post_bind(struct udevice *dev)
 
 static int spi_post_probe(struct udevice *bus)
 {
-#if !CONFIG_IS_ENABLED(OF_PLATDATA)
+#if !CONFIG_IS_ENABLED(OF_PLATDATA) && !defined(CONFIG_DM_NO_OF)
struct dm_spi_bus *spi = dev_get_uclass_priv(bus);
 
spi->max_hz = dev_read_u32_default(bus, "spi-max-frequency", 0);
@@ -274,7 +274,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int 
mode,
bool created = false;
int ret;
 
-#if CONFIG_IS_ENABLED(OF_PLATDATA)
+#if CONFIG_IS_ENABLED(OF_PLATDATA) || defined(CONFIG_DM_NO_OF)
ret = uclass_first_device_err(UCLASS_SPI, );
 #else
ret = uclass_get_device_by_seq(UCLASS_SPI, busnum, );
@@ -283,6 +283,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int 
mode,
printf("Invalid bus %d (err=%d)\n", busnum, ret);
return ret;
}
+
ret = spi_find_chip_select(bus, cs, );
 
/*
@@ -321,6 +322,7 @@ int spi_get_bus_and_cs(int busnum, int cs, int speed, int 
mode,
}
 
plat = dev_get_parent_platdata(dev);
+
if (!speed) {
speed = plat->max_hz;
mode = plat->mode;
@@ -427,7 +429,7 @@ UCLASS_DRIVER(spi) = {
.id = UCLASS_SPI,
.name   = "spi",
.flags  = DM_UC_FLAG_SEQ_ALIAS,
-#if !CONFIG_IS_ENABLED(OF_PLATDATA)
+#if !CONFIG_IS_ENABLED(OF_PLATDATA) && !defined(CONFIG_DM_NO_OF)
.post_bind  = dm_scan_fdt_dev,
 #endif
.post_probe = spi_post_probe,
@@ -436,7 +438,7 @@ UCLASS_DRIVER(spi) = {
.per_child_auto_alloc_size = sizeof(struct spi_slave),
.per_child_platdata_auto_alloc_size =
sizeof(struct dm_spi_slave_platdata),
-#if !CONFIG_IS_ENABLED(OF_PLATDATA)
+#if !CONFIG_IS_ENABLED(OF_PLATDATA) && !defined(CONFIG_DM_NO_OF)
.child_post_bind = spi_child_post_bind,
 #endif
 };
-- 
2.17.0

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


Re: [U-Boot] Logo for U-Boot

2018-05-03 Thread Alexander Graf


On 01.05.18 04:09, Marek Vasut wrote:
> On 04/30/2018 08:22 PM, Heinrich Schuchardt wrote:
>> U-Boot has currently no logo that we can use in presentations.
>>
>> On the U-Boot IRC channel the following propositions where made:
>>
>> Source: https://commons.wikimedia.org/wiki/File:Circle-icons-submarine.svg
>> License: GPL2+
>> (Alex used this in some presentations.)
> 
> Yellow submarine, nice.
> 
> Maybe we should make it a bit more toward teal and orange to improve the
> contrast ? Although, maybe just replacing the depressive gray background
> with a light blue one would do.

How about this?

  http://csgraf.de/tmp2/uboot.svg


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


Re: [U-Boot] [PATCH 2/2] net: add Kconfig for MVGBE

2018-05-03 Thread Joe Hershberger
On Thu, May 3, 2018 at 6:00 AM, Chris Packham  wrote:
> Add Kconfig for MVGBE and update boards to select this.
>
> Signed-off-by: Chris Packham 
> ---
>
>  arch/arm/mach-kirkwood/include/mach/config.h | 1 -
>  configs/d2net_v2_defconfig   | 2 ++
>  configs/dns325_defconfig | 2 ++
>  configs/dockstar_defconfig   | 2 ++
>  configs/dreamplug_defconfig  | 2 ++
>  configs/ds109_defconfig  | 2 ++
>  configs/goflexhome_defconfig | 2 ++
>  configs/guruplug_defconfig   | 2 ++
>  configs/ib62x0_defconfig | 2 ++
>  configs/iconnect_defconfig   | 2 ++
>  configs/inetspace_v2_defconfig   | 2 ++
>  configs/km_kirkwood_128m16_defconfig | 2 ++
>  configs/km_kirkwood_defconfig| 2 ++
>  configs/km_kirkwood_pci_defconfig| 2 ++
>  configs/kmcoge5un_defconfig  | 2 ++
>  configs/kmnusa_defconfig | 2 ++
>  configs/kmsugp1_defconfig| 2 ++
>  configs/kmsuv31_defconfig| 2 ++
>  configs/lschlv2_defconfig| 2 ++
>  configs/lsxhl_defconfig  | 2 ++
>  configs/mgcoge3un_defconfig  | 2 ++
>  configs/nas220_defconfig | 2 ++
>  configs/net2big_v2_defconfig | 2 ++
>  configs/netspace_lite_v2_defconfig   | 2 ++
>  configs/netspace_max_v2_defconfig| 2 ++
>  configs/netspace_mini_v2_defconfig   | 2 ++
>  configs/netspace_v2_defconfig| 2 ++
>  configs/nsa310s_defconfig| 2 ++
>  configs/openrd_base_defconfig| 2 ++
>  configs/openrd_client_defconfig  | 2 ++
>  configs/openrd_ultimate_defconfig| 2 ++
>  configs/pogo_e02_defconfig   | 2 ++
>  configs/portl2_defconfig | 2 ++
>  configs/sheevaplug_defconfig | 2 ++

Would it be better to default y if KIRKWOOD || ORION5X? That's a fair
number of defconfigs. Maybe far fewer boards don't have it enabled?

>  drivers/net/Kconfig  | 8 
>  include/configs/edminiv2.h   | 1 -
>  include/configs/km/km_arm.h  | 1 -
>  37 files changed, 74 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-kirkwood/include/mach/config.h 
> b/arch/arm/mach-kirkwood/include/mach/config.h
> index 9d6ad5387c7c..5772182babf2 100644
> --- a/arch/arm/mach-kirkwood/include/mach/config.h
> +++ b/arch/arm/mach-kirkwood/include/mach/config.h
> @@ -78,7 +78,6 @@
>  #ifdef CONFIG_CMD_NET
>  #define CONFIG_NETCONSOLE  /* include NetConsole support   */
>  #define CONFIG_MII /* expose smi ove miiphy interface */
> -#define CONFIG_MVGBE   /* Enable Marvell Gbe Controller Driver */
>  #define CONFIG_SYS_FAULT_ECHO_LINK_DOWN/* detect link using phy */
>  #define CONFIG_ENV_OVERWRITE   /* ethaddr can be reprogrammed */
>  #define CONFIG_RESET_PHY_R /* use reset_phy() to init mv8831116 PHY */

[ ... ]

> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 3a374d887183..c962d7a72c0c 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -178,6 +178,14 @@ config FTMAC100
> help
>   This MAC is present in Andestech SoCs.
>
> +config MVGBE
> +   bool "Marvell Orion5x/Kirkwood network interface support"
> +   depends on KIRKWOOD || ORION5X
> +   select PHYLIB
> +   help
> + This driver supports the network interface units in the
> + Marvell Orion5x and Kirkwood SoCs

Please remove CONFIG_MVGBE from scripts/config_whitelist.txt

> +
>  config MVNETA
> bool "Marvell Armada XP/385/3700 network interface support"
> depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
> diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h
> index 6a92e7fde816..ee63311b4759 100644
> --- a/include/configs/edminiv2.h
> +++ b/include/configs/edminiv2.h
> @@ -118,7 +118,6 @@
>   */
>
>  #ifdef CONFIG_CMD_NET
> -#define CONFIG_MVGBE   /* Enable Marvell GbE Driver 
> */
>  #define CONFIG_MVGBE_PORTS {1} /* enable port 0 only */
>  #define CONFIG_SKIP_LOCAL_MAC_RANDOMIZATION/* don't randomize MAC */
>  #define CONFIG_PHY_BASE_ADR0x8
> diff --git a/include/configs/km/km_arm.h b/include/configs/km/km_arm.h
> index c6761921c76f..8813557a2ab0 100644
> --- a/include/configs/km/km_arm.h
> +++ b/include/configs/km/km_arm.h
> @@ -134,7 +134,6 @@
>   */
>  #define CONFIG_NETCONSOLE  /* include NetConsole support   */
>  #define CONFIG_MII /* expose smi ove miiphy interface */
> -#define CONFIG_MVGBE   /* Enable Marvell Gbe Controller Driver */
>  #define CONFIG_SYS_FAULT_ECHO_LINK_DOWN/* detect link using phy */
>  #define 

Re: [U-Boot] [RFC PATCH v2 20/20] fastboot: net: Split fastboot protocol out from net

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Separate the fastboot protocol handling from the fastboot UDP code in
> preparation for reusing it in the USB code.
>
> Signed-off-by: Alex Kiernan 

This is the last patch, yet you are preparing for something to follow,
so I'll review when you get to that point.

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


Re: [U-Boot] [RFC PATCH v2 19/20] fastboot: Add missing newlines

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Add newlines so we format our output correctly.
>
> Signed-off-by: Alex Kiernan 

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


Re: [U-Boot] [RFC PATCH v2 18/20] fastboot: Check if part_name is NULL before using it

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> If we don't have a partition name passed, report it as not found.
>
> Signed-off-by: Alex Kiernan 

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


Re: [U-Boot] [RFC PATCH v2 17/20] fastboot: Guard getvar:partition-type/size with MMC

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Add guard for partition-type/size against MMC as we need that in order
> to lookup partitions.

Why? It seems you should just be using mtdparts when NAND is enabled instead.

>
> Signed-off-by: Alex Kiernan 
> ---
>
> Changes in v2: None
>
>  drivers/fastboot/fb_getvar.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> index aa68371..7989a19 100644
> --- a/drivers/fastboot/fb_getvar.c
> +++ b/drivers/fastboot/fb_getvar.c
> @@ -55,6 +55,7 @@ void fb_getvar(char *cmd_parameter, char *response)
> fastboot_okay("yes", response);
> else
> fastboot_okay("no", response);
> +#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> } else if (!strcmp_l1("partition-type", cmd_parameter) ||
>!strcmp_l1("partition-size", cmd_parameter)) {
> disk_partition_t part_info;
> @@ -74,6 +75,7 @@ void fb_getvar(char *cmd_parameter, char *response)
> fastboot_response("OKAY", response,
>   "0x%016x", (int)part_info.size);
> }
> +#endif
> } else {
>  #define FASTBOOT_ENV_PREFIX"fastboot."
> char envstr[FASTBOOT_RESPONSE_LEN];
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2 16/20] fastboot: net: Add NAND support

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Add NAND support to fastboot UDP flash/erase commands
>
> Signed-off-by: Alex Kiernan 

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


Re: [U-Boot] [RFC PATCH v2 15/20] fastboot: Merge boot common across USB and UDP

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Merge USB and UDP boot code. The USB implementation stays the same, but
> UDP no longer passes an fdt. We introduce a new environment variable
> 'fastbootcmd' which if set overrides the hardcoded boot command, setting
> this then allows the UDP implementation to remain the same. If after
> running 'fastbootcmd' the board has not booted, control is returned
> to U-Boot and the fastboot process ends.
>
> Signed-off-by: Alex Kiernan 

Nit below...

Acked-by: Joe Hershberger 

> ---
>
> Changes in v2: None
>
>  drivers/fastboot/fb_common.c| 27 +++
>  drivers/usb/gadget/f_fastboot.c | 22 +++---
>  include/fastboot.h  |  1 +
>  net/fastboot.c  | 16 ++--
>  4 files changed, 37 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
> index 36ef669..73d8f94 100644
> --- a/drivers/fastboot/fb_common.c
> +++ b/drivers/fastboot/fb_common.c
> @@ -107,3 +107,30 @@ int __weak fb_set_reboot_flag(void)
>  {
> return -1;
>  }
> +
> +void fastboot_boot(void *addr)
> +{
> +   char *s;
> +
> +   s = env_get("fastbootcmd");
> +   if (s) {
> +   run_command(s, CMD_FLAG_ENV);
> +   } else {
> +   static char boot_addr_start[12];
> +   static char *const bootm_args[] = {
> +   "bootm", boot_addr_start, NULL
> +   };
> +
> +   snprintf(boot_addr_start, sizeof(boot_addr_start) - 1,
> +"0x%lx", (long)addr);
> +   printf("Booting kernel at %s...\n\n\n", boot_addr_start);
> +
> +   do_bootm(NULL, 0, 2, bootm_args);
> +
> +   /* This only happens if image is somehow faulty so we start

Use multi-line comment format. '/*' gets its own line.

> +* over. We deliberately leave this policy to the invocation
> +* of fastbootcmd if that's what's being run
> +*/
> +   do_reset(NULL, 0, 0, NULL);
> +   }
> +}
> diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
> index 84515da..1dca4dd 100644
> --- a/drivers/usb/gadget/f_fastboot.c
> +++ b/drivers/usb/gadget/f_fastboot.c
> @@ -480,18 +480,15 @@ static void cb_download(struct usb_ep *ep, struct 
> usb_request *req)
> fastboot_tx_write_str(response);
>  }
>
> -static void do_bootm_on_complete(struct usb_ep *ep, struct usb_request *req)
> +static void do_exit_on_complete(struct usb_ep *ep, struct usb_request *req)
>  {
> -   char boot_addr_start[12];
> -   char *bootm_args[] = { "bootm", boot_addr_start, NULL };
> -
> -   puts("Booting kernel..\n");
> -
> -   sprintf(boot_addr_start, "0x%lx", (long)CONFIG_FASTBOOT_BUF_ADDR);
> -   do_bootm(NULL, 0, 2, bootm_args);
> +   g_dnl_trigger_detach();
> +}
>
> -   /* This only happens if image is somehow faulty so we start over */
> -   do_reset(NULL, 0, 0, NULL);
> +static void do_bootm_on_complete(struct usb_ep *ep, struct usb_request *req)
> +{
> +   fastboot_boot((void *)CONFIG_FASTBOOT_BUF_ADDR);
> +   do_exit_on_complete(ep, req);
>  }
>
>  static void cb_boot(struct usb_ep *ep, struct usb_request *req)
> @@ -500,11 +497,6 @@ static void cb_boot(struct usb_ep *ep, struct 
> usb_request *req)
> fastboot_tx_write_str("OKAY");
>  }
>
> -static void do_exit_on_complete(struct usb_ep *ep, struct usb_request *req)
> -{
> -   g_dnl_trigger_detach();
> -}
> -
>  static void cb_continue(struct usb_ep *ep, struct usb_request *req)
>  {
> fastboot_func->in_req->complete = do_exit_on_complete;
> diff --git a/include/fastboot.h b/include/fastboot.h
> index 9767065..64f9939 100644
> --- a/include/fastboot.h
> +++ b/include/fastboot.h
> @@ -76,4 +76,5 @@ int strcmp_l1(const char *s1, const char *s2);
>
>  int fastboot_lookup_command(const char *cmd_string);
>  int fb_set_reboot_flag(void);
> +void fastboot_boot(void *addr);
>  #endif /* _FASTBOOT_H_ */
> diff --git a/net/fastboot.c b/net/fastboot.c
> index ad8c101..119011c 100644
> --- a/net/fastboot.c
> +++ b/net/fastboot.c
> @@ -383,20 +383,8 @@ static void cb_reboot_bootloader(char *cmd_parameter, 
> char *fastboot_data,
>   */
>  static void boot_downloaded_image(void)
>  {
> -   char kernel_addr[12];
> -   char *fdt_addr = env_get("fdt_addr_r");
> -   char *const bootm_args[] = {
> -   "bootm", kernel_addr, "-", fdt_addr, NULL
> -   };
> -
> -   sprintf(kernel_addr, "0x%lx", (long)CONFIG_FASTBOOT_BUF_ADDR);
> -
> -   printf("\nBooting kernel at %s with fdt at %s...\n\n\n",
> -  kernel_addr, fdt_addr);
> -   do_bootm(NULL, 0, 4, bootm_args);
> -
> -   /* This only happens if image is faulty so we start over. */
> -   do_reset(NULL, 0, 0, NULL);
> +   fastboot_boot((void 

Re: [U-Boot] [RFC PATCH v2 14/20] fastboot: Avoid re-parsing cmd_string for boot/reboot

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> When picking up boot/reboot after we've sent our result packet, use
> the previously parsed command rather than redoing the strcmp.
>
> Signed-off-by: Alex Kiernan 

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


Re: [U-Boot] [RFC PATCH v2 13/20] fastboot: Merge reboot-bootloader handling

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Extract fb_set_reboot_flag() from USB code and ensure all the overides
> are included, then make the UDP fastboot code go through this same
> path.
>
> Note this changes the behaviour of the fastboot net code such that
> "reboot-bootloader" is no longer written to CONFIG_FASTBOOT_BUF_ADDR for
> use as a marker on reboot (the AOSP code in common/android-bootloader.c
> uses this marker - this code could be reinstated there if that gets
> merged).
>
> Signed-off-by: Alex Kiernan 

One nit below, but,

Acked-by: Joe Hershberger 

> ---
>
> Changes in v2: None
>
>  arch/arm/mach-omap2/boot-common.c |  2 +-
>  arch/arm/mach-rockchip/rk3128-board.c |  2 +-
>  arch/arm/mach-rockchip/rk322x-board.c |  2 +-
>  drivers/fastboot/fb_common.c  |  5 +
>  drivers/usb/gadget/f_fastboot.c   |  5 -
>  include/fastboot.h|  1 +
>  net/fastboot.c| 17 +
>  7 files changed, 18 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/boot-common.c 
> b/arch/arm/mach-omap2/boot-common.c
> index f9ab5da..2be5c11 100644
> --- a/arch/arm/mach-omap2/boot-common.c
> +++ b/arch/arm/mach-omap2/boot-common.c
> @@ -238,7 +238,7 @@ void arch_preboot_os(void)
>  }
>  #endif
>
> -#if defined(CONFIG_USB_FUNCTION_FASTBOOT) && !defined(CONFIG_ENV_IS_NOWHERE)
> +#if CONFIG_IS_ENABLED(FASTBOOT) && !CONFIG_IS_ENABLED(ENV_IS_NOWHERE)
>  int fb_set_reboot_flag(void)
>  {
> printf("Setting reboot to fastboot flag ...\n");
> diff --git a/arch/arm/mach-rockchip/rk3128-board.c 
> b/arch/arm/mach-rockchip/rk3128-board.c
> index 2e8393d..00ad563 100644
> --- a/arch/arm/mach-rockchip/rk3128-board.c
> +++ b/arch/arm/mach-rockchip/rk3128-board.c
> @@ -112,7 +112,7 @@ int board_usb_cleanup(int index, enum usb_init_type init)
>  }
>  #endif
>
> -#if defined(CONFIG_USB_FUNCTION_FASTBOOT)
> +#if CONFIG_IS_ENABLED(FASTBOOT)
>  int fb_set_reboot_flag(void)
>  {
> struct rk3128_grf *grf;
> diff --git a/arch/arm/mach-rockchip/rk322x-board.c 
> b/arch/arm/mach-rockchip/rk322x-board.c
> index 8642a90..0ddfac8 100644
> --- a/arch/arm/mach-rockchip/rk322x-board.c
> +++ b/arch/arm/mach-rockchip/rk322x-board.c
> @@ -140,7 +140,7 @@ int board_usb_cleanup(int index, enum usb_init_type init)
>  }
>  #endif
>
> -#if defined(CONFIG_USB_FUNCTION_FASTBOOT)
> +#if CONFIG_IS_ENABLED(FASTBOOT)
>  int fb_set_reboot_flag(void)
>  {
> struct rk322x_grf *grf;
> diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
> index 8b3627b..36ef669 100644
> --- a/drivers/fastboot/fb_common.c
> +++ b/drivers/fastboot/fb_common.c
> @@ -102,3 +102,8 @@ int fastboot_lookup_command(const char *cmd_string)
>
> return -1;
>  }
> +
> +int __weak fb_set_reboot_flag(void)
> +{
> +   return -1;

Why did you stop returning a proper errno?

> +}
> diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
> index a493c75..84515da 100644
> --- a/drivers/usb/gadget/f_fastboot.c
> +++ b/drivers/usb/gadget/f_fastboot.c
> @@ -357,11 +357,6 @@ static void compl_do_reset(struct usb_ep *ep, struct 
> usb_request *req)
> do_reset(NULL, 0, 0, NULL);
>  }
>
> -int __weak fb_set_reboot_flag(void)
> -{
> -   return -ENOSYS;
> -}
> -
>  static void cb_reboot(struct usb_ep *ep, struct usb_request *req)
>  {
> char *cmd = req->buf;
> diff --git a/include/fastboot.h b/include/fastboot.h
> index de07220..9767065 100644
> --- a/include/fastboot.h
> +++ b/include/fastboot.h
> @@ -75,4 +75,5 @@ void timed_send_info(ulong *start, const char *msg);
>  int strcmp_l1(const char *s1, const char *s2);
>
>  int fastboot_lookup_command(const char *cmd_string);
> +int fb_set_reboot_flag(void);
>  #endif /* _FASTBOOT_H_ */
> diff --git a/net/fastboot.c b/net/fastboot.c
> index 155049a..edf78df 100644
> --- a/net/fastboot.c
> +++ b/net/fastboot.c
> @@ -65,7 +65,7 @@ static void cb_flash(char *, char *, unsigned int, char *);
>  static void cb_erase(char *, char *, unsigned int, char *);
>  #endif
>  static void cb_continue(char *, char *, unsigned int, char *);
> -static void cb_reboot(char *, char *, unsigned int, char *);
> +static void cb_reboot_bootloader(char *, char *, unsigned int, char *);
>
>  static void (*fb_net_dispatch[])(char *cmd_parameter,
>  char *fastboot_data,
> @@ -83,8 +83,8 @@ static void (*fb_net_dispatch[])(char *cmd_parameter,
>  #endif
> [FB_CMD_BOOT] = cb_okay,
> [FB_CMD_CONTINUE] = cb_continue,
> -   [FB_CMD_REBOOT] = cb_reboot,
> -   [FB_CMD_REBOOT_BOOTLOADER] = cb_reboot,
> +   [FB_CMD_REBOOT] = cb_okay,
> +   [FB_CMD_REBOOT_BOOTLOADER] = cb_reboot_bootloader,
> [FB_CMD_POWERDOWN] = NULL,
> [FB_CMD_SET_ACTIVE] = cb_okay,
> [FB_CMD_UPLOAD] = NULL,
> @@ -370,12 +370,13 @@ static void cb_continue(char 

Re: [U-Boot] [RFC PATCH v2 12/20] fastboot: net: Convert command lookup to a table

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Change command lookup to use a lookup table so it matches the existing
> USB fastboot code.
>
> Signed-off-by: Alex Kiernan 
> ---
>
> Changes in v2: None
>
>  drivers/fastboot/fb_common.c |  30 
>  include/fastboot.h   |  21 +
>  net/fastboot.c   | 108 
> ++-
>  3 files changed, 127 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
> index 3b68f25..8b3627b 100644
> --- a/drivers/fastboot/fb_common.c
> +++ b/drivers/fastboot/fb_common.c
> @@ -72,3 +72,33 @@ int strcmp_l1(const char *s1, const char *s2)
> return -1;
> return strncmp(s1, s2, strlen(s1));
>  }
> +
> +static const char *const fb_commands[] = {
> +   [FB_CMD_GETVAR] = "getvar",
> +   [FB_CMD_DOWNLOAD] = "download",
> +   [FB_CMD_VERIFY] = "verify",
> +   [FB_CMD_FLASH] = "flash",
> +   [FB_CMD_ERASE] = "erase",
> +   [FB_CMD_BOOT] = "boot",
> +   [FB_CMD_CONTINUE] = "continue",
> +   [FB_CMD_REBOOT] = "reboot",
> +   [FB_CMD_REBOOT_BOOTLOADER] = "reboot-bootloader",
> +   [FB_CMD_POWERDOWN] = "powerdown",
> +   [FB_CMD_SET_ACTIVE] = "set_active",
> +   [FB_CMD_UPLOAD] = "upload",
> +};
> +
> +int fastboot_lookup_command(const char *cmd_string)
> +{
> +   int i;
> +
> +   for (i = 0; i < FB_CMD_COUNT; i++) {
> +   int len = strlen(fb_commands[i]);
> +
> +   if (!strncmp(fb_commands[i], cmd_string, len) &&

Why not use your new strcmp_l1()?

> +   (cmd_string[len] == '\0' || cmd_string[len] == ':'))

At this point the ':' is already deleted.

> +   return i;
> +   }
> +
> +   return -1;
> +}
> diff --git a/include/fastboot.h b/include/fastboot.h
> index fb58358..de07220 100644
> --- a/include/fastboot.h
> +++ b/include/fastboot.h
> @@ -18,6 +18,26 @@
>  /* The 64 defined bytes plus \0 */
>  #define FASTBOOT_RESPONSE_LEN  (64 + 1)
>
> +/**
> + * All known commands to fastboot
> + */
> +enum {
> +   FB_CMD_GETVAR = 0,
> +   FB_CMD_DOWNLOAD,
> +   FB_CMD_VERIFY,
> +   FB_CMD_FLASH,
> +   FB_CMD_ERASE,
> +   FB_CMD_BOOT,
> +   FB_CMD_CONTINUE,
> +   FB_CMD_REBOOT,
> +   FB_CMD_REBOOT_BOOTLOADER,
> +   FB_CMD_POWERDOWN,
> +   FB_CMD_SET_ACTIVE,
> +   FB_CMD_UPLOAD,
> +
> +   FB_CMD_COUNT
> +};
> +
>  void fastboot_response(const char *tag, char *response,
>const char *format, ...)
> __attribute__ ((format (__printf__, 3, 4)));
> @@ -54,4 +74,5 @@ void timed_send_info(ulong *start, const char *msg);
>   */
>  int strcmp_l1(const char *s1, const char *s2);
>
> +int fastboot_lookup_command(const char *cmd_string);
>  #endif /* _FASTBOOT_H_ */
> diff --git a/net/fastboot.c b/net/fastboot.c
> index ed13890..155049a 100644
> --- a/net/fastboot.c
> +++ b/net/fastboot.c
> @@ -57,13 +57,39 @@ static int fastboot_remote_port;
>  /* The UDP port at our end */
>  static int fastboot_our_port;
>
> -static void fb_download(char *, unsigned int, char *);
> +static void cb_okay(char *, char *, unsigned int, char *);
> +static void cb_getvar(char *, char *, unsigned int, char *);
> +static void cb_download(char *, char *, unsigned int, char *);
>  #if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> -static void fb_flash(char *);
> -static void fb_erase(char *);
> +static void cb_flash(char *, char *, unsigned int, char *);
> +static void cb_erase(char *, char *, unsigned int, char *);
>  #endif
> -static void fb_continue(char *);
> -static void fb_reboot(char *);
> +static void cb_continue(char *, char *, unsigned int, char *);
> +static void cb_reboot(char *, char *, unsigned int, char *);
> +
> +static void (*fb_net_dispatch[])(char *cmd_parameter,
> +char *fastboot_data,
> +unsigned int fastboot_data_len,
> +char *response) = {
> +   [FB_CMD_GETVAR] = cb_getvar,
> +   [FB_CMD_DOWNLOAD] = cb_download,
> +   [FB_CMD_VERIFY] = NULL,
> +#if CONFIG_IS_ENABLED(FASTBOOT_FLASH_MMC)
> +   [FB_CMD_FLASH] = cb_flash,
> +   [FB_CMD_ERASE] = cb_erase,
> +#else
> +   [FB_CMD_FLASH] = NULL,
> +   [FB_CMD_ERASE] = NULL,
> +#endif
> +   [FB_CMD_BOOT] = cb_okay,
> +   [FB_CMD_CONTINUE] = cb_continue,
> +   [FB_CMD_REBOOT] = cb_reboot,
> +   [FB_CMD_REBOOT_BOOTLOADER] = cb_reboot,
> +   [FB_CMD_POWERDOWN] = NULL,
> +   [FB_CMD_SET_ACTIVE] = cb_okay,
> +   [FB_CMD_UPLOAD] = NULL,
> +};
> +
>  static void boot_downloaded_image(void);
>  static void cleanup_command_data(void);
>
> @@ -165,28 +191,30 @@ static void fastboot_send(struct fastboot_header 
> fb_header, char *fastboot_data,
> cmd_string = strdup(cmd_string);
> if 

Re: [U-Boot] [RFC PATCH v2 11/20] fastboot: net: Change 'continue' so it matches USB fastboot

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Change the behaviour of 'continue' so that we simply exit the fastboot
> server and leave the caller to decide what to do next. This matches
> the USB fastboot behaviour.

Good, I was considering recommending this approach.

Acked-by: Joe Hershberger 

>
> Signed-off-by: Alex Kiernan 
> ---
>
> Changes in v2: None
>
>  net/fastboot.c | 13 +++--
>  1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/net/fastboot.c b/net/fastboot.c
> index cd09ada..ed13890 100644
> --- a/net/fastboot.c
> +++ b/net/fastboot.c
> @@ -218,8 +218,6 @@ static void fastboot_send(struct fastboot_header 
> fb_header, char *fastboot_data,
> if (!strncmp("OKAY", response, 4)) {
> if (!strcmp("boot", cmd_string)) {
> boot_downloaded_image();
> -   } else if (!strcmp("continue", cmd_string)) {
> -   run_command(env_get("bootcmd"), CMD_FLAG_ENV);
> } else if (!strncmp("reboot", cmd_string, 6)) {
> /* Matches reboot or reboot-bootloader */
> do_reset(NULL, 0, 0, NULL);
> @@ -313,20 +311,15 @@ static void fb_erase(char *response)
>  #endif
>
>  /**
> - * Continues normal boot process by running "bootcmd". Writes
> + * Continues normal boot process by exiting fastboot server. Writes
>   * to response.
>   *
>   * @param repsonsePointer to fastboot response buffer
>   */
>  static void fb_continue(char *response)
>  {
> -   char *bootcmd;
> -
> -   bootcmd = env_get("bootcmd");
> -   if (bootcmd)
> -   fastboot_okay(NULL, response);
> -   else
> -   fastboot_fail("bootcmd not set", response);
> +   net_set_state(NETLOOP_SUCCESS);
> +   fastboot_okay(NULL, response);
>  }
>
>  /**
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v2 10/20] fastboot: Merge USB and UDP getvar implementation

2018-05-03 Thread Joe Hershberger
 On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Merge the USB and UDP getvar implementations into one. The USB side
> gains new variables previously defined in the network side and the
> network side now supports fetching of arbitrary variables prefixed with
> 'fastboot.'
>
> Signed-off-by: Alex Kiernan 
> ---
>
> Changes in v2: None
>
>  drivers/fastboot/Makefile   |  1 +
>  drivers/fastboot/fb_common.c|  7 
>  drivers/fastboot/fb_getvar.c| 93 
> +
>  drivers/usb/gadget/f_fastboot.c | 56 +
>  include/fastboot.h  | 18 
>  net/fastboot.c  | 75 +
>  6 files changed, 121 insertions(+), 129 deletions(-)
>  create mode 100644 drivers/fastboot/fb_getvar.c
>
> diff --git a/drivers/fastboot/Makefile b/drivers/fastboot/Makefile
> index c12dfa8..9af4073 100644
> --- a/drivers/fastboot/Makefile
> +++ b/drivers/fastboot/Makefile
> @@ -1,6 +1,7 @@
>  # SPDX-License-Identifier:  GPL-2.0+
>
>  obj-y += fb_common.o
> +obj-y += fb_getvar.o
>  obj-$(CONFIG_FASTBOOT_FLASH) += image-sparse.o
>
>  obj-$(CONFIG_FASTBOOT_FLASH_MMC) += fb_mmc.o
> diff --git a/drivers/fastboot/fb_common.c b/drivers/fastboot/fb_common.c
> index f0bf53d..3b68f25 100644
> --- a/drivers/fastboot/fb_common.c
> +++ b/drivers/fastboot/fb_common.c
> @@ -65,3 +65,10 @@ void timed_send_info(ulong *start, const char *msg)
> }
>  #endif
>  }
> +
> +int strcmp_l1(const char *s1, const char *s2)
> +{
> +   if (!s1 || !s2)
> +   return -1;
> +   return strncmp(s1, s2, strlen(s1));
> +}
> diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
> new file mode 100644
> index 000..aa68371
> --- /dev/null
> +++ b/drivers/fastboot/fb_getvar.c
> @@ -0,0 +1,93 @@
> +// SPDX-License-Identifier: BSD-2-Clause
> +/*
> + * Copyright (C) 2016 The Android Open Source Project
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * Writes ascii string specified by cmd_parameter to response.
> + *
> + * @param cmd_parameterPoint to command parameter
> + * @param response Pointer to fastboot response buffer
> + */
> +void fb_getvar(char *cmd_parameter, char *response)
> +{
> +   if (!cmd_parameter) {
> +   fastboot_fail("missing var", response);
> +   } else if (!strcmp("version", cmd_parameter)) {
> +   fastboot_okay(FASTBOOT_VERSION, response);
> +   } else if (!strcmp("bootloader-version", cmd_parameter) ||
> +  !strcmp("version-bootloader", cmd_parameter)) {
> +   fastboot_okay(U_BOOT_VERSION, response);
> +   } else if (!strcmp("downloadsize", cmd_parameter) ||
> +  !strcmp("max-download-size", cmd_parameter)) {
> +   fastboot_response("OKAY", response,
> + "0x%08x", CONFIG_FASTBOOT_BUF_SIZE);
> +   } else if (!strcmp("serialno", cmd_parameter)) {
> +   const char *tmp = env_get("serial#");
> +
> +   if (tmp)
> +   fastboot_okay(tmp, response);
> +   else
> +   fastboot_fail("Value not set", response);
> +   } else if (!strcmp("version-baseband", cmd_parameter)) {
> +   fastboot_okay("N/A", response);
> +   } else if (!strcmp("product", cmd_parameter)) {
> +   const char *board = env_get("board");
> +
> +   if (board)
> +   fastboot_okay(board, response);
> +   else
> +   fastboot_fail("Board not set", response);
> +   } else if (!strcmp("current-slot", cmd_parameter)) {
> +   /* A/B not implemented, for now always return _a */
> +   fastboot_okay("_a", response);
> +   } else if (!strcmp("slot-suffixes", cmd_parameter)) {
> +   fastboot_okay("_a,_b", response);
> +   } else if (!strcmp_l1("has-slot", cmd_parameter)) {
> +   char *part_name = cmd_parameter;
> +
> +   cmd_parameter = strsep(_name, ":");
> +   if (!strcmp(part_name, "boot") || !strcmp(part_name, 
> "system"))
> +   fastboot_okay("yes", response);
> +   else
> +   fastboot_okay("no", response);
> +   } else if (!strcmp_l1("partition-type", cmd_parameter) ||
> +  !strcmp_l1("partition-size", cmd_parameter)) {
> +   disk_partition_t part_info;
> +   struct blk_desc *dev_desc;
> +   char *part_name = cmd_parameter;
> +
> +   cmd_parameter = strsep(_name, ":");
> +   dev_desc = blk_get_dev("mmc", 0);
> +   if (!dev_desc) {
> +   fastboot_fail("block device not found", response);
> +   } else if (part_get_info_by_name(dev_desc, part_name,
> +  

Re: [U-Boot] [RFC PATCH v2 09/20] fastboot: Refactor write_fb_response into fastboot_okay/fail/response

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Replace write_fb_response with fastboot_okay/fail/response. Also allow
> fastboot_okay to take NULL when we have no message to send.
>
> Signed-off-by: Alex Kiernan 

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


Re: [U-Boot] [RFC PATCH v2 08/20] net: fastboot: Support building without MMC

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> If the fastboot flash/erase commands are disabled, remove that support
> so we still build correctly.
>
> Signed-off-by: Alex Kiernan 

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


Re: [U-Boot] [RFC PATCH v2 07/20] net: fastboot: Merge AOSP UDP fastboot

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Merge UDP fastboot support from AOSP:
>
> https://android.googlesource.com/platform/external/u-boot/+/android-o-mr1-iot-preview-8
>
> Signed-off-by: Alex Kiernan 
> Signed-off-by: Alex Deymo 
> ---
>
> Changes in v2:
> - ensure fastboot syntax is backward compatible - 'fastboot 0' means
>   'fastboot usb 0'
>
>  cmd/fastboot.c   |  35 ++-
>  cmd/net.c|   6 +
>  drivers/fastboot/Kconfig |  16 +-
>  drivers/fastboot/fb_common.c |  18 ++
>  drivers/fastboot/fb_mmc.c|  34 ++-
>  include/fastboot.h   |  13 ++
>  include/net.h|   6 +-
>  include/net/fastboot.h   |  27 +++
>  net/Makefile |   1 +
>  net/fastboot.c   | 542 
> +++
>  net/net.c|   9 +
>  11 files changed, 695 insertions(+), 12 deletions(-)
>  create mode 100644 include/net/fastboot.h
>  create mode 100644 net/fastboot.c
>
> diff --git a/cmd/fastboot.c b/cmd/fastboot.c
> index 8adcca5..68a41de 100644
> --- a/cmd/fastboot.c
> +++ b/cmd/fastboot.c
> @@ -11,17 +11,41 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  static int do_fastboot(cmd_tbl_t *cmdtp, int flag, int argc, char *const 
> argv[])
>  {
> +#ifdef CONFIG_USB_FUNCTION_FASTBOOT
> int controller_index;
> char *usb_controller;
> int ret;
> +#endif
>
> if (argc < 2)
> return CMD_RET_USAGE;
>
> +   if (!strcmp(argv[1], "udp")) {
> +#ifndef CONFIG_UDP_FUNCTION_FASTBOOT
> +   pr_err("Fastboot UDP not enabled\n");
> +   return -1;

Commands should always return an enum command_ret_t.

> +#else
> +   return do_fastboot_udp(cmdtp, flag, argc, argv);
> +#endif
> +   }
> +
> +   if (!strcmp(argv[1], "usb")) {
> +   argv++;
> +   argc--;
> +   }
> +
> +   if (argc < 2)
> +   return CMD_RET_USAGE;
> +
> +#ifndef CONFIG_USB_FUNCTION_FASTBOOT
> +   pr_err("Fastboot USB not enabled\n");
> +   return -1;

Commands should always return an enum command_ret_t.

> +#else
> usb_controller = argv[1];
> controller_index = simple_strtoul(usb_controller, NULL, 0);
>
> @@ -59,11 +83,14 @@ exit:
> board_usb_cleanup(controller_index, USB_INIT_DEVICE);
>
> return ret;
> +#endif
>  }
>
>  U_BOOT_CMD(
> -   fastboot, 2, 1, do_fastboot,
> -   "use USB Fastboot protocol",
> -   "\n"
> -   "- run as a fastboot usb device"
> +   fastboot, 3, 1, do_fastboot,
> +   "use USB or UDP Fastboot protocol",
> +   "[usb,udp] \n"
> +   " - run as a fastboot usb or udp device\n"
> +   "   usb: specify \n"
> +   "   udp: requires ip_addr set and ethernet initialized\n"
>  );
> diff --git a/cmd/net.c b/cmd/net.c
> index 67888d4..668f344 100644
> --- a/cmd/net.c
> +++ b/cmd/net.c
> @@ -74,6 +74,12 @@ U_BOOT_CMD(
>  );
>  #endif
>
> +#ifdef CONFIG_UDP_FUNCTION_FASTBOOT
> +int do_fastboot_udp(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])

You should move this to cmd/fastboot.c and make it static.

> +{
> +   return netboot_common(FASTBOOT, cmdtp, argc, argv);

Is this really what you want? You are passing these command
parameters, but you don't really want them to be interpreted (as a
load address or file name), right?

I think you just want this:

int err = net_loop(FASTBOOT);

if (err < 0) {
printf("fastboot udp error: %i\n", err);
return CMD_RET_FAILURE;
}

return CMD_RET_SUCCESS;


> +}
> +#endif
>
>  #ifdef CONFIG_CMD_RARP
>  int do_rarpb(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
> index 64b94f0..53c337f 100644
> --- a/drivers/fastboot/Kconfig
> +++ b/drivers/fastboot/Kconfig
> @@ -2,6 +2,8 @@ menu "Fastboot support"
>
>  config FASTBOOT
> bool
> +   imply ANDROID_BOOT_IMAGE
> +   imply CMD_FASTBOOT
>
>  config USB_FUNCTION_FASTBOOT
> bool "Enable USB fastboot gadget"
> @@ -9,12 +11,17 @@ config USB_FUNCTION_FASTBOOT
> default y if ARCH_SUNXI && USB_MUSB_GADGET
> select FASTBOOT
> select USB_GADGET_DOWNLOAD
> -   imply ANDROID_BOOT_IMAGE
> -   imply CMD_FASTBOOT
> help
>   This enables the USB part of the fastboot gadget.
>
> -if USB_FUNCTION_FASTBOOT
> +config UDP_FUNCTION_FASTBOOT
> +   depends on NET

This is the correct level of dependency once you start using net_loop
directly, but based on how you have it now, you would have to depend
on CMD_NET.

> +   select FASTBOOT
> +   bool "Enable fastboot protocol over UDP"
> +   help
> + This enables the fastboot protocol over UDP.
> +
> +if USB_FUNCTION_FASTBOOT || UDP_FUNCTION_FASTBOOT
>
>  config FASTBOOT_BUF_ADDR

Re: [U-Boot] [PATCH] arm: mach-omap2: cache: Explicitly enable I cache

2018-05-03 Thread Tom Rini
On Thu, May 03, 2018 at 08:34:49PM +0530, Lokesh Vutla wrote:

> omap-common cache enabling sequence relies on cpu_init_cp15()
> (inside start.S) for enabling I-caches. But cpu_init_cp15()
> can be skipped if CONFIG_SKIP_LOWLEVEL_INIT is defined. So
> enable I-caches if not enabled already.
> 
> Debugged-by: Jean-Jacques Hiblot 
> Tested-by: Steve Kipisz 
> Signed-off-by: Lokesh Vutla 

Reviewed-by: Tom Rini 

-- 
Tom


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


Re: [U-Boot] [PATCHv2 2/2] stdio_names: Ensure MAX_NAMES is defined before use, don't use 3 directly

2018-05-03 Thread Tom Rini
On Thu, May 03, 2018 at 03:12:47PM +0100, Peter Robinson wrote:
> On Thu, May 3, 2018 at 2:12 PM, Tom Rini  wrote:
> > With tighter build flags the fact that  doesn't have a
> > reference back to MAX_NAMES causes an error.  Include  here and
> > then in common/console.c use MAX_NAMES rather than 3 when working with
> > stdio_names.
> >
> > Reported-by: Peter Robinson 
> > Signed-off-by: Tom Rini 
> > ---
> > Changes in v2:
> > - New patch
> > ---
> >  common/console.c| 4 ++--
> >  include/stdio_dev.h | 1 +
> >  2 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/common/console.c b/common/console.c
> > index 0e0295514b21..f1a5e95c8f39 100644
> > --- a/common/console.c
> > +++ b/common/console.c
> > @@ -847,7 +847,7 @@ done:
> >
> >  #ifdef CONFIG_SYS_CONSOLE_ENV_OVERWRITE
> > /* set the environment variables (will overwrite previous env 
> > settings) */
> > -   for (i = 0; i < 3; i++) {
> > +   for (i = 0; i < MAX_NAMES; i++) {
> 
> I think you mean MAX_FILES? With MAX_NAMES it fails, with MAX_FILES it builds.
> 
> With the that change, if it's correct:
> Tested-by: Peter Robinson 

If anyone is wonder if I'll ever learn to not post something I quickly
did and was sure it was right, the answer is no.  But I don't push those
changes out (on purpose) at least!  I'll fix it up before merging,
thanks!

-- 
Tom


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


Re: [U-Boot] [PATCH v2 02/10] sysreset: Add get_status method

2018-05-03 Thread Simon Glass
On 27 April 2018 at 06:52, Mario Six  wrote:
> It's useful to have the reset status of the SoC printed out during reset
> (e.g. to learn whether the reset was caused by software or a watchdog).
>
> As a first step to implement this, add a get_status method to the
> sysreset class, which enables the caller to get printable information
> about the reset status (akin to get_desc in the CPU uclass).
>
> Signed-off-by: Mario Six 
>
> ---
>
> v1 -> v2:
> New in v2
>
> ---
>  drivers/sysreset/sysreset-uclass.c | 10 ++
>  include/sysreset.h | 17 +
>  2 files changed, 27 insertions(+)

Reviewed-by: Simon Glass 

Can you add a test for sandbox?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 03/10] board_f: Add reset status printing

2018-05-03 Thread Simon Glass
Hi Mario,

On 27 April 2018 at 06:52, Mario Six  wrote:
> To print the reset status during boot, add a method print_resetinfo to
> board_f, which is called in init_sequence_f[], that gets the reset
> information from the sysreset driver (assuming there is only one seems
> reasonable), and prints it.
>
> Signed-off-by: Mario Six 
>
> ---
>
> v1 -> v2:
> New in v2
>
> ---
>  common/board_f.c | 19 +++
>  1 file changed, 19 insertions(+)

Reviewed-by: Simon Glass 

nit below

>
> diff --git a/common/board_f.c b/common/board_f.c
> index ae8bdb7c5c..2df30cd250 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -141,6 +142,21 @@ static int display_text_info(void)
> return 0;
>  }
>
> +#ifdef CONFIG_SYSRESET
> +static int print_resetinfo(void)
> +{
> +   struct udevice *dev;
> +   char status[256];
> +
> +   uclass_first_device_err(UCLASS_SYSRESET, );

Should check the result and only call the function below if it is 0.

> +
> +   if (!sysreset_get_status(dev, status, sizeof(status)))
> +   printf("%s", status);
> +
> +   return 0;
> +}
> +#endif
> +

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


Re: [U-Boot] [PATCH v2 04/10] mpc83xx: Add sysreset driver

2018-05-03 Thread Simon Glass
On 27 April 2018 at 06:52, Mario Six  wrote:
> Add a sysreset driver for the MPC83xx platform.
>
> Signed-off-by: Mario Six 
>
> ---
>
> v1 -> v2:
> New in v2
>
> ---
>  arch/powerpc/cpu/mpc83xx/cpu.c  |   3 +-
>  drivers/sysreset/Kconfig|   5 ++
>  drivers/sysreset/Makefile   |   9 +-
>  drivers/sysreset/sysreset_mpc83xx.c | 160 
> 
>  4 files changed, 172 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/sysreset/sysreset_mpc83xx.c

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


Re: [U-Boot] [PATCH v2 07/10] common: board_f: Sort includes

2018-05-03 Thread Simon Glass
On 27 April 2018 at 06:52, Mario Six  wrote:
> Includes should be sorted.
>
> Signed-off-by: Mario Six 
>
> ---
>
> v1 -> v2:
> New in v2
>
> ---
>  common/board_f.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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


Re: [U-Boot] [PATCH] treewide: Move CONFIG_PHY_MARVELL to Kconfig

2018-05-03 Thread Joe Hershberger
On Fri, Apr 27, 2018 at 7:52 AM, Mario Six  wrote:
> The CONFIG_PHY_MARVELL has already been migrated to Kconfig (some boards
> already had it in their Kconfig), but had not been moved for older
> boards.
>
> Move it to the defconfigs for all boards.
>
> Signed-off-by: Mario Six 

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


Re: [U-Boot] [PATCH 2/2] net: add Kconfig for MVGBE

2018-05-03 Thread Stefan Roese

On 03.05.2018 13:00, Chris Packham wrote:

Add Kconfig for MVGBE and update boards to select this.

Signed-off-by: Chris Packham 


Reviewed-by: Stefan Roese 

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


Re: [U-Boot] [PATCH v2 01/10] ram: Add driver for MPC83xx

2018-05-03 Thread Simon Glass
Hi Mario,

On 27 April 2018 at 06:52, Mario Six  wrote:
> Add a RAM driver for the MPC83xx architecture.
>
> Signed-off-by: Mario Six 
>
> ---
>
> v1 -> v2:
> No changes
>
> ---
>  arch/powerpc/cpu/mpc83xx/spd_sdram.c   |   4 +
>  drivers/ram/Kconfig|   8 +
>  drivers/ram/Makefile   |   1 +
>  drivers/ram/mpc83xx_sdram.c| 948 
> +
>  include/dt-bindings/memory/mpc83xx-sdram.h | 143 +
>  include/mpc83xx.h  |   6 +
>  6 files changed, 1110 insertions(+)
>  create mode 100644 drivers/ram/mpc83xx_sdram.c
>  create mode 100644 include/dt-bindings/memory/mpc83xx-sdram.h
>

Reviewed-by: Simon Glass 

Question below

[..]

> new file mode 100644
> index 00..1a73f7b3da
> --- /dev/null
> +++ b/drivers/ram/mpc83xx_sdram.c
> @@ -0,0 +1,948 @@
> +#define DEBUG
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define CSCONFIG_ENABLE0x8000
> +
> +#define BANK_BITS_20x
> +#define BANK_BITS_30x4000
> +
> +#define ROW_BITS_120x
> +#define ROW_BITS_130x0100
> +#define ROW_BITS_140x0200
> +
> +#define COL_BITS_8 0x
> +#define COL_BITS_9 0x0001
> +#define COL_BITS_100x0002
> +#define COL_BITS_110x0003
> +
> +#define TIMING_CFG3_EXT_REFREC_SHIFT   16
> +
> +#define TIMING_CFG0_RWT_SHIFT  30
> +#define TIMING_CFG0_WRT_SHIFT  28
> +#define TIMING_CFG0_RRT_SHIFT  26
> +#define TIMING_CFG0_WWT_SHIFT  24
> +#define TIMING_CFG0_ACT_PD_EXIT_SHIFT  20
> +#define TIMING_CFG0_PRE_PD_EXIT_SHIFT  16
> +#define TIMING_CFG0_ODT_PD_EXIT_SHIFT  8
> +#define TIMING_CFG0_MRS_CYC_SHIFT  0
> +
> +#define TIMING_CFG1_PRETOACT_SHIFT 28
> +#define TIMING_CFG1_ACTTOPRE_SHIFT 24
> +#define TIMING_CFG1_ACTTORW_SHIFT  20
> +#define TIMING_CFG1_CASLAT_SHIFT   16
> +#define TIMING_CFG1_REFREC_SHIFT   12
> +#define TIMING_CFG1_WRREC_SHIFT8
> +#define TIMING_CFG1_ACTTOACT_SHIFT 4
> +#define TIMING_CFG1_WRTORD_SHIFT   0
> +
> +#define TIMING_CFG2_CPO_SHIFT  23
> +#define TIMING_CFG2_WR_DATA_DELAY_SHIFT10
> +#define TIMING_CFG2_ADD_LAT_SHIFT  28
> +#define TIMING_CFG2_WR_LAT_DELAY_SHIFT 19
> +#define TIMING_CFG2_RD_TO_PRE_SHIFT13
> +#define TIMING_CFG2_CKE_PLS_SHIFT  6
> +#define TIMING_CFG2_FOUR_ACT_SHIFT 0
> +
> +#define SDRAM_CFG_SREN_SHIFT   (31 - 1)
> +#define SDRAM_CFG_ECC_EN_SHIFT (31 - 2)
> +#define SDRAM_CFG_RD_EN_SHIFT  (31 - 3)
> +#define SDRAM_CFG_SDRAM_TYPE_SHIFT (31 - 7)
> +#define SDRAM_CFG_DYN_PWR_SHIFT(31 - 10)
> +#define SDRAM_CFG_DBW_SHIFT(31 - 12)
> +#define SDRAM_CFG_NCAP_SHIFT   (31 - 14)
> +#define SDRAM_CFG_2T_EN_SHIFT  (31 - 16)
> +#define SDRAM_CFG_BA_INTLV_CTL_SHIFT   (31 - 23)
> +#define SDRAM_CFG_PCHB8_SHIFT  (31 - 27)
> +#define SDRAM_CFG_HSE_SHIFT(31 - 28)
> +#define SDRAM_CFG_BI_SHIFT (31 - 31)
> +
> +#define SDRAM_CFG2_FRC_SR_SHIFT(31 - 0)
> +#define SDRAM_CFG2_DLL_RST_DIS (31 - 2)
> +#define SDRAM_CFG2_DQS_CFG (31 - 5)
> +#define SDRAM_CFG2_ODT_CFG (31 - 10)
> +#define SDRAM_CFG2_NUM_PR  (31 - 19)
> +
> +#define SDRAM_MODE_ESD_SHIFT   16
> +#define SDRAM_MODE_SD_SHIFT0
> +
> +#define SDRAM_MODE2_ESD2_SHIFT (31 - 15)
> +#define SDRAM_MODE2_ESD3_SHIFT (31 - 31)
> +
> +#define SDRAM_INTERVAL_REFINT_SHIFT16
> +#define SDRAM_INTERVAL_BSTOPRE_SHIFT   0
> +
> +#define SDRAM_CFG_MEM_EN  0x8000
> +
> +int dram_init(void)
> +{
> +   struct udevice *ram_ctrl;
> +   int ret;
> +
> +   /* Current assumption: There is only one RAM controller */
> +   ret = uclass_first_device_err(UCLASS_RAM, _ctrl);
> +
> +   if (ret) {
> +   debug("uclass_first_device_err failed: %d\n", ret);
> +   return ret;
> +   }
> +
> +   /* Set gd->ram_size? */
> +
> +   return 0;
> +}
> +
> +phys_size_t get_effective_memsize(void)
> +{
> +#ifndef CONFIG_VERY_BIG_RAM

Can this (and the #ifdefs below in this file) be converted to

if (IS_ENABLED(CONFIG_...))

instead, to increase build coverage?

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


[U-Boot] u-boot problem - Unknown commands

2018-05-03 Thread Dennis Jacobs
Dear u-boot mailing list,

Recently I am working on a graduation project at Prodrive Technologies 
including the development of firmware for a Marvell Ethernet switch chip: 
98DX3235. For parallel hardware/software development, I got access to another 
Marvell Ethernet switch chip 98DX3336 placed in a Marvell RD-XC3-24G4XG-B 
switching unit. To prepare a u-boot bootloader I am using the following 
components

U-boot version:   2013.01
Marvell u-boot configurations: 2013.01-2016_T1.0.eng_drop_v6
Cross compiler:
armv7-marvell-linux-gnueabi-softfp-4.6.4_64K_i686_20160226

I also have got a working u-boot binary files from Marvell. Because I need to 
make changes to the u-boot configuration I need to compile my own u-boot binary 
files. I was able to compile a UART binary file and load it through UART using 
TeraTerm. At the u-boot commandline I got stuck. No commands are recognized by 
u-boot. See my terminal feedback below:

--- START TERMINAL WINDOW---

BootROM 1.41

__   __  _ _
|  \/  | __ _ _    _| | |
| |\/| |/ _` | '__\ \ / / _ \ | |
| |  | | (_| | |   \ V /  __/ | |
|_|  |_|\__,_|_|\_/ \___|_|_|
 _   _   _
| | | |   | __ )  ___   ___ | |_
| | | |___|  _ \ / _ \ / _ \| __|
| |_| |___| |_) | (_) | (_) | |_
 \___/|/ \___/ \___/ \__|
** LOADER **


U-Boot 2013.01 (May 03 2018 - 11:22:30) Marvell version: 2016_T1.0.eng_drop_v6

Board: RD-XC3-24G-4SFP
SoC:   Alleycat3 Rev A1
   running 2 CPUs
CPU:   Marvell PJ4B (584) v7 (Rev 2) LE
   CPU 0
   CPU@ 800 [MHz]
   L2 @ 200 [MHz]
   TClock @ 200 [MHz]
   DDR@ 400 [MHz]
   DDR 16Bit Width, FastPath Memory Access, DLB Enabled
   DDR ECC Disabled
DRAM:  512 MiB
NAND:  1024 MiB
SF: Detected MX25L25735E with page size 64 KiB, total 32 MiB
PCI-e 0: Detected No Link.
FPU initialized to Run Fast Mode.
USB2.0 0: Host Mode

Map:   Code:0x1fede000:0x1ff95a4c
   BSS: 0x1ffefbe8
   Stack:   0x1f9cdef0
   Heap:0x1f9ce000:0x1fede000
   U-Boot Environment:  0x0010:0x0011 (SPI)

Net:
|  port  | Interface | PHY address  |
||---|--|
| egiga0 |   SGMII   |   In-Band|
| egiga1 |   SGMII   |   In-Band|
egiga0 [PRIME], egiga1
Hit any key to stop autoboot:  0
Marvell>> >
Unknown command '>' - try 'help'
Marvell>> ?
Unknown command '?' - try 'help'
Marvell>> help
Unknown command 'help' - try 'help'
Marvell>> fli
Unknown command 'fli' - try 'help'
Marvell>> conin
Unknown command 'conin' - try 'help'
Marvell>>

---END TERMINAL WINDOW---

As you can see U-boot is loaded, hardware configurations are done, the serial 
interface works fine and unfortunately no commands are recognized by the 
u-boot. This got me thinking. My first thought was that the terminal in some 
way adds invisible characters to the commands. I tested this by printing all 
command characters separately before the Unknown command print function in 
u-boot. I saw that there were no other segments added to the command. I also 
tried using putty without any results. The binary file obtained by Marvell 
works fine but mine does not.

I also tried to compile and execute using 7 other cross compilers without any 
results.

The original Marvell UART binary file differs 24 bytes from my own compiled 
UART binary file. Apart from the Unknown command lines in the previously shown 
terminal window, both UART binary files print exactly the same information.

The only thing I can think of now is that my configuration in 
include/configs/. is not well configured. A Part of the 
configuration file is shown below. Does someone know what is going wrong here? 
Do I have to change/add configurations or do I have to search somewhere else.

--/include/configs/configfile-

160 /*/
161 /* High Level Configuration Options  */
162 /* (easy to change)  */
163 /*/
164 #define CONFIG_MARVELL
165 #define CONFIG_SYS_64BIT_VSPRINTF
166 #define CONFIG_SYS_64BIT_STRTOUL
167 #define CONFIG_API
168
169 /* commands */
170 #define CONFIG_BOOTP_DEFAULT(CONFIG_BOOTP_MASK | 
CONFIG_BOOTP_BOOTFILESIZE)
171 #define CONFIG_CMD_DHCP
172 #define CONFIG_CMD_ELF
173 #define CONFIG_CMD_I2C
174 #define CONFIG_CMD_EEPROM
175 #define CONFIG_CMD_NET
176 #define CONFIG_CMD_PING
177 //#define CONFIG_CMD_DATE
178 #define CONFIG_CMD_LOADS
179 #define CONFIG_CMD_BSP
180 #define CONFIG_CMD_MEMORY
181 #define CONFIG_CMD_BOOTD
182 #define CONFIG_CMD_BOOTZ
183 #define CONFIG_CMD_CONSOLE
184 #define CONFIG_CMD_RUN
185 #define CONFIG_CMD_MISC
186 #define CONFIG_CMD_IDE
187 #define CONFIG_CMD_SCSI
188 #define CONFIG_CMD_SAR
189 #define CONFIG_CMD_STAGE_BOOT
190 

[U-Boot] [PATCH 2/2] net: add Kconfig for MVGBE

2018-05-03 Thread Chris Packham
Add Kconfig for MVGBE and update boards to select this.

Signed-off-by: Chris Packham 
---

 arch/arm/mach-kirkwood/include/mach/config.h | 1 -
 configs/d2net_v2_defconfig   | 2 ++
 configs/dns325_defconfig | 2 ++
 configs/dockstar_defconfig   | 2 ++
 configs/dreamplug_defconfig  | 2 ++
 configs/ds109_defconfig  | 2 ++
 configs/goflexhome_defconfig | 2 ++
 configs/guruplug_defconfig   | 2 ++
 configs/ib62x0_defconfig | 2 ++
 configs/iconnect_defconfig   | 2 ++
 configs/inetspace_v2_defconfig   | 2 ++
 configs/km_kirkwood_128m16_defconfig | 2 ++
 configs/km_kirkwood_defconfig| 2 ++
 configs/km_kirkwood_pci_defconfig| 2 ++
 configs/kmcoge5un_defconfig  | 2 ++
 configs/kmnusa_defconfig | 2 ++
 configs/kmsugp1_defconfig| 2 ++
 configs/kmsuv31_defconfig| 2 ++
 configs/lschlv2_defconfig| 2 ++
 configs/lsxhl_defconfig  | 2 ++
 configs/mgcoge3un_defconfig  | 2 ++
 configs/nas220_defconfig | 2 ++
 configs/net2big_v2_defconfig | 2 ++
 configs/netspace_lite_v2_defconfig   | 2 ++
 configs/netspace_max_v2_defconfig| 2 ++
 configs/netspace_mini_v2_defconfig   | 2 ++
 configs/netspace_v2_defconfig| 2 ++
 configs/nsa310s_defconfig| 2 ++
 configs/openrd_base_defconfig| 2 ++
 configs/openrd_client_defconfig  | 2 ++
 configs/openrd_ultimate_defconfig| 2 ++
 configs/pogo_e02_defconfig   | 2 ++
 configs/portl2_defconfig | 2 ++
 configs/sheevaplug_defconfig | 2 ++
 drivers/net/Kconfig  | 8 
 include/configs/edminiv2.h   | 1 -
 include/configs/km/km_arm.h  | 1 -
 37 files changed, 74 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-kirkwood/include/mach/config.h 
b/arch/arm/mach-kirkwood/include/mach/config.h
index 9d6ad5387c7c..5772182babf2 100644
--- a/arch/arm/mach-kirkwood/include/mach/config.h
+++ b/arch/arm/mach-kirkwood/include/mach/config.h
@@ -78,7 +78,6 @@
 #ifdef CONFIG_CMD_NET
 #define CONFIG_NETCONSOLE  /* include NetConsole support   */
 #define CONFIG_MII /* expose smi ove miiphy interface */
-#define CONFIG_MVGBE   /* Enable Marvell Gbe Controller Driver */
 #define CONFIG_SYS_FAULT_ECHO_LINK_DOWN/* detect link using phy */
 #define CONFIG_ENV_OVERWRITE   /* ethaddr can be reprogrammed */
 #define CONFIG_RESET_PHY_R /* use reset_phy() to init mv8831116 PHY */
diff --git a/configs/d2net_v2_defconfig b/configs/d2net_v2_defconfig
index b346fa221aab..d4cfe70bc82a 100644
--- a/configs/d2net_v2_defconfig
+++ b/configs/d2net_v2_defconfig
@@ -31,6 +31,8 @@ CONFIG_MVSATA_IDE=y
 # CONFIG_MMC is not set
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_NETDEVICES=y
+CONFIG_MVGBE=y
 CONFIG_SYS_NS16550=y
 CONFIG_KIRKWOOD_SPI=y
 CONFIG_USB=y
diff --git a/configs/dns325_defconfig b/configs/dns325_defconfig
index c46e2b447463..f64038dfe0c2 100644
--- a/configs/dns325_defconfig
+++ b/configs/dns325_defconfig
@@ -26,6 +26,8 @@ CONFIG_ISO_PARTITION=y
 CONFIG_ENV_IS_IN_NAND=y
 CONFIG_MVSATA_IDE=y
 # CONFIG_MMC is not set
+CONFIG_NETDEVICES=y
+CONFIG_MVGBE=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/dockstar_defconfig b/configs/dockstar_defconfig
index 88d6f596b27a..b7a65db37cfa 100644
--- a/configs/dockstar_defconfig
+++ b/configs/dockstar_defconfig
@@ -21,6 +21,8 @@ CONFIG_CMD_UBI=y
 CONFIG_ISO_PARTITION=y
 CONFIG_ENV_IS_IN_NAND=y
 # CONFIG_MMC is not set
+CONFIG_NETDEVICES=y
+CONFIG_MVGBE=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
diff --git a/configs/dreamplug_defconfig b/configs/dreamplug_defconfig
index e633173f633c..a1fcbf2a802f 100644
--- a/configs/dreamplug_defconfig
+++ b/configs/dreamplug_defconfig
@@ -24,6 +24,8 @@ CONFIG_MVSATA_IDE=y
 # CONFIG_MMC is not set
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_NETDEVICES=y
+CONFIG_MVGBE=y
 CONFIG_SYS_NS16550=y
 CONFIG_KIRKWOOD_SPI=y
 CONFIG_USB=y
diff --git a/configs/ds109_defconfig b/configs/ds109_defconfig
index ec41ab7b4700..d6b4d530857e 100644
--- a/configs/ds109_defconfig
+++ b/configs/ds109_defconfig
@@ -20,6 +20,8 @@ CONFIG_MVSATA_IDE=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_NETDEVICES=y
+CONFIG_MVGBE=y
 CONFIG_SYS_NS16550=y
 CONFIG_KIRKWOOD_SPI=y
 CONFIG_USB=y
diff --git a/configs/goflexhome_defconfig b/configs/goflexhome_defconfig
index d87d308ac097..3b3abd52c7f5 100644
--- a/configs/goflexhome_defconfig
+++ b/configs/goflexhome_defconfig
@@ -27,6 +27,8 @@ CONFIG_ISO_PARTITION=y
 CONFIG_ENV_IS_IN_NAND=y
 

Re: [U-Boot] Booting Jerry chromebook from eMMC

2018-05-03 Thread Simon Glass
Hi Carlo,

On 16 April 2018 at 14:26, Carlo Caione  wrote:
> Hi,
> I'm trying to boot a Veyron Jerry chromebook using U-Boot placed in
> the eMMC. Booting from SPI using 'chromebook_jerry_defconfig' works
> perfectly fine, but I'm hitting a wall when moving from SPI to eMMC
> (mostly related to the limited space for the SPL).
>
> Has anyone managed to boot this platform directly from eMMC? Reading
> sources and documentation there is explicitly nothing related to boot
> this platform from eMMC so I was wondering if this is feasible at all.
>
> Thank you,
>
> --
> Carlo Caione  |  +44.7384.69.16.04  |  Endless

You can try using CONFIG_SPL_OF_PLATDATA which will reduce the size of
U-Boot, if size is you problem?

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


Re: [U-Boot] BUG: cannot boot with CONFIG_LOG

2018-05-03 Thread Simon Glass
Hi Heinrich,

On 3 May 2018 at 12:54, Heinrich Schuchardt  wrote:
> Hello Simon,
>
> I am running vexpress_ca15_tc2_defconfig with qemu:
>
> QEMU_AUDIO_DRV=none qemu-system-arm \
> -M vexpress-a15 -cpu cortex-a15 \
> -kernel u-boot \
> -net user -net nic,model=lan9118 \
> -m 1024M --nographic \
> -drive if=sd,file=../img.vexpress,media=disk,format=raw
>
> If I enable CONFIG_LOG=y starting U-Boot fails.
>
> This is due to log_init() returning -ENOMEM.
> If I change
> return -ENOMEM;
> to
> return 0;
> the board boots.
>
> log_init() is called twice:
> common/board_r.c:680:   log_init,
> common/board_f.c:760:   log_init,
>
> If I remove the call from common/board_f.c the board boots.
>
> What do you expect
> debug("%s: Cannot allocate memory\n", __func__);
> to do if logging is not yet initialized and the board is out of memory?
>
> Even if I #define DEBUG 1
> I get no output created by this line.

There is a check for GD_FLG_LOG_READY in _log(). Perhaps we need to
have a fallback call?

>
> Best regards
>
> Heinrich
>
>

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


Re: [U-Boot] [RFC] Exporting defaul environment

2018-05-03 Thread Simon Glass
Hi Kristian,

On 3 May 2018 at 06:57, Kristian Amlie  wrote:
> On 02/05/18 21:32, Simon Glass wrote:
>> Hi Stefano,
>>
>> On 2 May 2018 at 02:48, Stefano Babic  wrote:
>>>
>>> Hi,
>>>
>>> I am thinking about how it is possible to export in a clean way the
>>> default environment from u-boot. The general use case happens when the
>>> environment must be changed from user space (via fw_setenv or whatever)
>>> and no environment was still stored - board boots with default environment.

Is a magic number not enough to find it?

Alternatively could we put the default environment in /chosen in the
device tree before jumping to Linux?

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


Re: [U-Boot] [PATCH v2 2/3] mpc83xx/pci: Register IMMR region

2018-05-03 Thread Simon Glass
Hi Mario,

On 27 April 2018 at 06:53, Mario Six  wrote:
> Register the IMMR region as a PCI region when PCI is used on MPC83xx.
>
> Signed-off-by: Mario Six 
> ---
>
> v1 -> v2:
> No changes
>
> ---
>  drivers/pci/pci-uclass.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> index a2e829608a..37ca09d76b 100644
> --- a/drivers/pci/pci-uclass.c
> +++ b/drivers/pci/pci-uclass.c
> @@ -902,6 +902,11 @@ static int decode_regions(struct pci_controller *hose, 
> ofnode parent_node,
> base, size, PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
>  #endif
>
> +#if defined(MPC83xx) && defined(CONFIG_SYS_IMMR)
> +   pci_set_region(hose->regions + hose->region_count++,
> +  CONFIG_SYS_IMMR, CONFIG_SYS_IMMR, 0x10,
> +  PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
> +#endif

Please don't add device-specific code in this file. This could go in
the device tree, perhaps. If not, we perhaps need to do it in your PCI
driver?

> return 0;
>  }
>
> --
> 2.16.1
>

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


Re: [U-Boot] [PATCH v2 1/2] misc: uclass: Add enable/disable function

2018-05-03 Thread Simon Glass
Hi Mario,

On 27 April 2018 at 06:52, Mario Six  wrote:
> Add generic enable/disable function to the misc uclass.
>
> Signed-off-by: Mario Six 
> ---
>
> v1 -> v2:
> * Merged the two functions into one function
> * Explained the semantics of enabling/disabling more throughly
>
> ---
>  drivers/misc/misc-uclass.c | 10 ++
>  include/misc.h | 25 +
>  2 files changed, 35 insertions(+)
>
> diff --git a/drivers/misc/misc-uclass.c b/drivers/misc/misc-uclass.c
> index d9eea3dac5..0e3e0e8bf7 100644
> --- a/drivers/misc/misc-uclass.c
> +++ b/drivers/misc/misc-uclass.c
> @@ -56,6 +56,16 @@ int misc_call(struct udevice *dev, int msgid, void 
> *tx_msg, int tx_size,
> return ops->call(dev, msgid, tx_msg, tx_size, rx_msg, rx_size);
>  }
>
> +int misc_set_enabled(struct udevice *dev, bool val)
> +{
> +   const struct misc_ops *ops = device_get_ops(dev);
> +
> +   if (!ops->set_enabled)
> +   return -ENOSYS;
> +
> +   return ops->set_enabled(dev, val);
> +}
> +
>  UCLASS_DRIVER(misc) = {
> .id = UCLASS_MISC,
> .name   = "misc",
> diff --git a/include/misc.h b/include/misc.h
> index 03ef55cdc8..04a4b65155 100644
> --- a/include/misc.h
> +++ b/include/misc.h
> @@ -58,6 +58,22 @@ int misc_ioctl(struct udevice *dev, unsigned long request, 
> void *buf);
>  int misc_call(struct udevice *dev, int msgid, void *tx_msg, int tx_size,
>   void *rx_msg, int rx_size);
>
> +/*
> + * Enable or disable a device.
> + *
> + * The semantics of "disable" and "enable" should be understood here as
> + * activating or deactivating the device's primary function, hence a 
> "disabled"
> + * device should be dormant, but still answer to commands and queries.
> + *
> + * A probed device may start in a disabled or enabled state, depending on the
> + * driver and hardware.

This makes be wonder whether we should have this as a concept
understood by the DM core. But perhaps not until we have more use
cases. So far I know of only display that needs this.

> + *
> + * @dev: the device to enable or disable.
> + * @val: the flag that tells the driver to either enable or disable the 
> device.
> + * @return: 0 if OK, -ve on error
> + */
> +int misc_set_enabled(struct udevice *dev, bool val);
> +
>  /*
>   * struct misc_ops - Driver model Misc operations
>   *
> @@ -109,6 +125,15 @@ struct misc_ops {
>  */
> int (*call)(struct udevice *dev, int msgid, void *tx_msg, int tx_size,
> void *rx_msg, int rx_size);
> +   /*
> +* Enable or disable a device, optional.
> +*
> +* @dev: the device to enable.
> +* @val: the flag that tells the driver to either enable or disable 
> the
> +*   device.
> +* @return: 0 if OK, -ve on error

How about returning the old state (0 or 1)?

> +*/
> +   int (*set_enabled)(struct udevice *dev, bool val);
>  };
>
>  #endif /* _MISC_H_ */
> --
> 2.16.1
>

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


Re: [U-Boot] [PATCH v2 11/19] tpm: add TPM2_Clear command support

2018-05-03 Thread Simon Glass
Hi Miquel,

On 27 April 2018 at 07:39, Miquel Raynal  wrote:
> Hi Simon,
>
> On Thu, 26 Apr 2018 08:40:27 -0600, Simon Glass 
> wrote:
>
>> Hi Miquel,
>>
>> On 24 April 2018 at 07:17, Miquel Raynal  wrote:
>> > Hi Simon,
>> >
>> > On Fri, 30 Mar 2018 06:42:32 +0800, Simon Glass 
>> > wrote:
>> >
>> >> Hi Miquel,
>> >>
>> >> On 29 March 2018 at 15:43, Miquel Raynal  
>> >> wrote:
>> >> > Add support for the TPM2_Clear command.
>> >> >
>> >> > Change the command file and the help accordingly.
>> >> >
>> >> > Signed-off-by: Miquel Raynal 
>> >> > ---
>> >> >  cmd/tpm.c  | 29 ++---
>> >> >  cmd/tpm_test.c |  6 +++---
>> >> >  include/tpm.h  | 21 +
>> >> >  lib/tpm.c  | 42 ++
>> >> >  4 files changed, 84 insertions(+), 14 deletions(-)
>> >> >
>> >> > diff --git a/cmd/tpm.c b/cmd/tpm.c
>> >> > index fc9ef9d4a3..32921e1a70 100644
>> >> > --- a/cmd/tpm.c
>> >> > +++ b/cmd/tpm.c
>> >> > @@ -454,6 +454,29 @@ static int do_tpm_init(cmd_tbl_t *cmdtp, int flag,
>> >> > return report_return_code(tpm_init());
>> >> >  }
>> >> >
>> >> > +static int do_tpm_force_clear(cmd_tbl_t *cmdtp, int flag,
>> >> > + int argc, char * const argv[])
>> >> > +{
>> >> > +   u32 handle = 0;
>> >> > +   const char *pw = (argc < 3) ? NULL : argv[2];
>> >> > +   const ssize_t pw_sz = pw ? strlen(pw) : 0;
>> >> > +
>> >> > +   if (argc < 2 || argc > 3)
>> >> > +   return CMD_RET_USAGE;
>> >> > +
>> >> > +   if (pw_sz > TPM2_DIGEST_LENGTH)
>> >> > +   return -EINVAL;
>> >> > +
>> >> > +   if (!strcasecmp("TPM2_RH_LOCKOUT", argv[1]))
>> >> > +   handle = TPM2_RH_LOCKOUT;
>> >> > +   else if (!strcasecmp("TPM2_RH_PLATFORM", argv[1]))
>> >> > +   handle = TPM2_RH_PLATFORM;
>> >> > +   else
>> >> > +   return CMD_RET_USAGE;
>> >> > +
>> >> > +   return report_return_code(tpm_force_clear(handle, pw, pw_sz));
>> >> > +}
>> >> > +
>> >> >  #define TPM_COMMAND_NO_ARG(cmd)\
>> >> >  static int do_##cmd(cmd_tbl_t *cmdtp, int flag,\
>> >> > int argc, char * const argv[])  \
>> >> > @@ -465,7 +488,6 @@ static int do_##cmd(cmd_tbl_t *cmdtp, int flag, 
>> >> > \
>> >> >
>> >> >  TPM_COMMAND_NO_ARG(tpm_self_test_full)
>> >> >  TPM_COMMAND_NO_ARG(tpm_continue_self_test)
>> >> > -TPM_COMMAND_NO_ARG(tpm_force_clear)
>> >> >  TPM_COMMAND_NO_ARG(tpm_physical_enable)
>> >> >  TPM_COMMAND_NO_ARG(tpm_physical_disable)
>> >> >
>> >> > @@ -951,8 +973,9 @@ U_BOOT_CMD(tpm, CONFIG_SYS_MAXARGS, 1, do_tpm,
>> >> >  "  physical_set_deactivated 0|1\n"
>> >> >  "- Set deactivated flag.\n"
>> >> >  "Admin Ownership Commands:\n"
>> >> > -"  force_clear\n"
>> >> > -"- Issue TPM_ForceClear command.\n"
>> >> > +"  force_clear []\n"
>> >> > +"- Issue TPM_[Force]Clear command, with  one of (TPMv2 
>> >> > only):\n"
>> >> > +"  * TPM2_RH_LOCKOUT, TPM2_RH_PLATFORM.\n"
>> >> >  "  tsc_physical_presence flags\n"
>> >> >  "- Set TPM device's Physical Presence flags to .\n"
>> >> >  "The Capability Commands:\n"
>> >> > diff --git a/cmd/tpm_test.c b/cmd/tpm_test.c
>> >> > index 37ad2ff33d..da40dbc423 100644
>> >> > --- a/cmd/tpm_test.c
>> >> > +++ b/cmd/tpm_test.c
>> >> > @@ -176,7 +176,7 @@ static int test_fast_enable(void)
>> >> > TPM_CHECK(tpm_get_flags(, , NULL));
>> >> > printf("\tdisable is %d, deactivated is %d\n", disable, 
>> >> > deactivated);
>> >> > for (i = 0; i < 2; i++) {
>> >> > -   TPM_CHECK(tpm_force_clear());
>> >> > +   TPM_CHECK(tpm_force_clear(0, NULL, 0));
>> >> > TPM_CHECK(tpm_get_flags(, , NULL));
>> >> > printf("\tdisable is %d, deactivated is %d\n", disable,
>> >> >deactivated);
>> >> > @@ -458,7 +458,7 @@ static int test_write_limit(void)
>> >> > TPM_CHECK(TlclStartupIfNeeded());
>> >> > TPM_CHECK(tpm_self_test_full());
>> >> > TPM_CHECK(tpm_tsc_physical_presence(PRESENCE));
>> >> > -   TPM_CHECK(tpm_force_clear());
>> >> > +   TPM_CHECK(tpm_force_clear(0, NULL, 0));
>> >> > TPM_CHECK(tpm_physical_enable());
>> >> > TPM_CHECK(tpm_physical_set_deactivated(0));
>> >> >
>> >> > @@ -477,7 +477,7 @@ static int test_write_limit(void)
>> >> > }
>> >> >
>> >> > /* Reset write count */
>> >> > -   TPM_CHECK(tpm_force_clear());
>> >> > +   TPM_CHECK(tpm_force_clear(0, NULL, 0));
>> >> > TPM_CHECK(tpm_physical_enable());
>> >> > TPM_CHECK(tpm_physical_set_deactivated(0));
>> >> >
>> >> > diff --git a/include/tpm.h b/include/tpm.h
>> >> > index 38d7cb899d..2f1712 100644
>> >> > --- a/include/tpm.h
>> >> > +++ 

Re: [U-Boot] [PATCH v2] reset: Add generic GPIO reset driver

2018-05-03 Thread Simon Glass
Hi Neil,

On 27 April 2018 at 07:01, Neil Armstrong  wrote:
> Hi,
>
> On 27/04/2018 14:53, Mario Six wrote:
>> Some reset lines are implemented by toggling the line via a GPIO.
>>
>> Add a driver to properly drive such reset lines.
>
> You are defining a "gpio-reset" binding which has always been rejected
> under Linux, so I'm not sure it's a good idea to add it in U-Boot only...

What is the alternative?

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


Re: [U-Boot] [PATCH v2 1/3] drivers: Add board uclass

2018-05-03 Thread Simon Glass
Hi Philipp,

[somehow the quoting is messed up here - so it's hard to distinguish
my response from yours.

On 1 May 2018 at 07:14, Dr. Philipp Tomsich
 wrote:
> Simon,
>
> On 1 May 2018, at 01:12, Simon Glass  wrote:
>
> Hi,
>
> On 27 April 2018 at 07:02, Dr. Philipp Tomsich
>  wrote:
>
>
> On 27 Apr 2018, at 14:51, Mario Six  wrote:
>
> Since there is no canonical "board device" that can be used in board
> files, it is difficult to use DM function for board initialization in
> these cases.
>
> Hence, add a uclass that implements a simple "board device", which can
> hold devices not suitable anywhere else in the device tree, and is also
> able to read encoded information, e.g. hard-wired GPIOs on a GPIO
> expander, read-only memory ICs, etc. that carry information about the
> hardware.
>
>
> With comments below:
>
> Reviewed-by: Simon Glass 
>
>
> A board-uclass should model a board (i.e. provide implementations for
> the same key abstractions that we have in place today: e.g., board_init).
>
> This seems more like a specialised form of a misc-device.
>
> The devices of this uclass expose methods to read generic data types
> (integers, strings, booleans) to encode the information provided by the
> hardware.
>
>
> Again, this is what a misc-device is intended for… and extending the
> misc-device APIs (or having a convenience layer on top of its ioctl
> interface?) might be more appropriate.

We could certainly use a misc device, but I feel that a board device
is a better abstraction for lots of reasons. It is the board that
collects together all the different devices that U-Boot has access to.

To me a misc device is useful as a parent device to collect a few
things together, perhaps a GPIO expander which has a clock output. But
using a misc device to model a board seems like a short-term strategy.

Addressing your idea about implementing the board init in this uclass,
yes I think that would be a good idea. In fact I did a series for that
some time ago:

https://lists.denx.de/pipermail/u-boot/2017-March/284086.html

But, baby steps.

>
> After reviewing the below, the similarities to the misc-device are even
> more apparent: if you need typed access to a key-value pair, this can
> be easily implemented through a common ioctl with semantic sugar
> at the misc-uclass level.
>
>
> A misc device might be similar in action but it is not the same in
> terms of concept. For example it would be very strange to have a misc
> device which points to lots of other devices that are on the board.
> For example, consider this hypothetical case:
>
> board {
>   identity-eeprom = <>;
>   id-gpios = < 2>, < 4>;
>   ec = <_ec>;
> };
>
>
> Maybe I am getting hung up on the ‘board’ name, as in my mind the board
> selection should be based on the top-level .compatible:
> e.g. compatible = "tsd,rk3399-q7", "tsd,puma", "rockchip,rk3399";
> and the selected board-classes could then encapsulate the various init
> hooks and inquire into devices defined via /aliases, /config and /chosen.
>
> A board-class should restructure existing board.c-files into the .ops that
> are used there (i.e. init, late-init, usb-init, debug-uart-init, etc.) ...
> this is
> different from what’s being proposed here.

See above. I agree the compatible string should be used.

>
> The hypothetical case you give is already covered wholly by today’s device
> model. Let me explain with a counter example:
> aliases {
> identity-eeprom = <>;
> id-gpios = <>;
> ec = <_ec>;
> }
>
> board-id {
> /* a good use for a hypothetical misc-device that exports the
>values of a variable-length list of GPIOs */
> .compatible = “identity-gpios”;
> id-gpios = < 2>, < 4>;
> }

Yes, agreed, that will work. But I want to push this a bit further and
I think a board uclass makes sense overall.

>
> Here we point to a few devices which may otherwise require specific
> device-tree references to locate. Already we are seeing this sort of
> code in U-Boot:
>
> /* find the grf node */
> node = fdt_node_offset_by_compatible(blob, -1,
> "rockchip,rk3288-grf”);
>
>
> This is usually caused by badly-modelled device-trees or missing device
> tree support in drivers.
> In this specific case it’s a wart caused by dwc2_udc_probe(…) and that
> this is not called from the device-tree.
>
> I would hope that this will eventually be included converted to the device
> model and that the info will be processed from the dwc2_udc driver.
>
> ret = regulator_get_by_platname("vdd_arm", );
> if (ret) {
> debug("Cannot set regulator name\n");
> return ret;
> }
>
>
> I know this specific example, and it’s from a use case, where a voltage
> needs to be slowly raised.  The reason for this being there is that we
> don’t have the same DTS as in Linux and the modelling (and driver)
> for the PMU subsystem are not there.
>
> So I don’t seem to follow on how this would resolve 

[U-Boot] BUG: cannot boot with CONFIG_LOG

2018-05-03 Thread Heinrich Schuchardt
Hello Simon,

I am running vexpress_ca15_tc2_defconfig with qemu:

QEMU_AUDIO_DRV=none qemu-system-arm \
-M vexpress-a15 -cpu cortex-a15 \
-kernel u-boot \
-net user -net nic,model=lan9118 \
-m 1024M --nographic \
-drive if=sd,file=../img.vexpress,media=disk,format=raw

If I enable CONFIG_LOG=y starting U-Boot fails.

This is due to log_init() returning -ENOMEM.
If I change
return -ENOMEM;
to
return 0;
the board boots.

log_init() is called twice:
common/board_r.c:680:   log_init,
common/board_f.c:760:   log_init,

If I remove the call from common/board_f.c the board boots.

What do you expect
debug("%s: Cannot allocate memory\n", __func__);
to do if logging is not yet initialized and the board is out of memory?

Even if I #define DEBUG 1
I get no output created by this line.

Best regards

Heinrich


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


Re: [U-Boot] [RFC PATCH v2 06/20] fastboot: Correct dependencies in FASTBOOT_FLASH

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Ensure that when selecting FASTBOOT_FLASH you end up with a buildable
> configuration. Prior to this you could select NAND without MTDPARTS
> and end up with an image which (surprisingly) excluded NAND.
>
> Signed-off-by: Alex Kiernan 

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


Re: [U-Boot] [RFC PATCH v2 05/20] fastboot: Introduce fastboot_response and refactor fastboot_okay/fail

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Introduce fastboot_response which takes varargs parameters so we can
> use it to generate formatted response strings. Refactor fastboot_okay/fail
> to use it.
>
> Signed-off-by: Alex Kiernan 

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


Re: [U-Boot] [RFC PATCH v2 04/20] fastboot: Extract fastboot_okay/fail to fb_common.c

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Add drivers/fastboot/fb_common.c, where fastboot_okay/fail are implemented
> so we can call them from a non-USB implementation.
>
> Signed-off-by: Alex Kiernan 

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


Re: [U-Boot] [RFC PATCH v2 03/20] fastboot: Refactor fastboot_okay/fail to take response

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Add the response string as a parameter to fastboot_okay/fail, instead
> of modifying a global, to match the contract expected by the AOSP
> U-Boot code.
>
> Signed-off-by: Alex Kiernan 

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


Re: [U-Boot] [RFC PATCH v2 02/20] fastboot: Switch dependencies on FASTBOOT to USB_FUNCTION_FASTBOOT

2018-05-03 Thread Joe Hershberger
On Mon, Apr 30, 2018 at 3:32 AM, Alex Kiernan  wrote:
> Anyone who wants FASTBOOT before this series wants USB_FUNCTION_FASTBOOT.
> Split USB_FUNCTION_FASTBOOT from FASTBOOT so they retain their existing
> behaviour.
>
> Signed-off-by: Alex Kiernan 

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


Re: [U-Boot] [PATCH] Fix Ymodem build when DEBUG and CONFIG_USE_TINY_PRINTF are selected

2018-05-03 Thread Joe Hershberger
On Thu, May 3, 2018 at 6:45 AM, Alex Kiernan  wrote:
> Attempting to build with both DEBUG and CONFIG_USE_TINY_PRINTF along
> with CONFIG_SPL_YMODEM_SUPPORT fails at link time:
>
>   common/built-in.o: In function `zm_dprintf':
>   common/xyzModem.c:190: undefined reference to `vsprintf'
>
> Disable Ymodem debug if we don't have full vsprintf support.
>
> Signed-off-by: Alex Kiernan 

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


Re: [U-Boot] FitImage add pubkey signature in DTS

2018-05-03 Thread Larry.Gass
On Thu, May 3, 2018 at 1:33 AM, Clément Péron  wrote:
> Subject: [U-Boot] FitImage add pubkey signature in DTS
> 
> Hi,
> 
> I'm looking to add the public key for the FitImage signature in my dts.
> 
> Do you know if there is a script to add the pubkey in the .dts and not in the
> .dtb ?
> 
> Actually I "decompile" the .dtb to get those values, but maybe there is an
> easier way.

Did the same thing. Started with a file pubkey.dts that was "empty":

/dtc-v1/;
/ {
};

Compiled it:
$ dtc -O dtb pubkey.dts > pubkey.dtb

Created the FIT image:
$ output/build/uboot-2018.03/tools/mkimage -f linux.its -k keys -r -K 
pubkey.dtb

De-Compiled it:
$ dtc -I dtb pubkey.dtb > pubkey.dts

Manually merged pubkey.dts with my "real" device tree (in arch/arm/dts/) . This 
step is important because it is WAY too easy to lose the signature from the 
.dtb if you "make clean" or touch your device tree source in any way.

I also would like to see this made easier in some way if it does not already 
exist.

> 
> Looking to generate something like this from the RSA keys :
>  signature {
>  key-product-dev {
>  required = "conf";
>  algo = "sha1,rsa2048";
>  rsa,r-squared = <0x68b44337 0x916dcfda 0x.>
>  rsa,modulus = <0xb7929d33 0x34df0e32 0x..>
>  rsa,exponent = <0x0 0x10001>;
>  rsa,n0-inverse = <0x29.>;
>  rsa,num-bits = <0x800>;
>  key-name-hint = "product-dev";
>  };
>  };
> 
> Thanks,
> Clement
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot

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


Re: [U-Boot] [RFC] Exporting defaul environment

2018-05-03 Thread Stefano Babic
Hi Kristian,

On 03/05/2018 14:57, Kristian Amlie wrote:
> On 02/05/18 21:32, Simon Glass wrote:
>> Hi Stefano,
>>
>> On 2 May 2018 at 02:48, Stefano Babic  wrote:
>>>
>>> Hi,
>>>
>>> I am thinking about how it is possible to export in a clean way the
>>> default environment from u-boot. The general use case happens when the
>>> environment must be changed from user space (via fw_setenv or whatever)
>>> and no environment was still stored - board boots with default environment.
>>>
>>> Up now, the trick is to compile the environment tools (u-boot-fw-utils
>>> in Yocto) with exactly the same U-Boot sources. This works, but it is
>>> error prone when a new Yocto version is delivered (and maybe with a
>>> different u-boot-fw-utils) or even if the bootloader is updated. I am
>>> searching for an alterntive method.
>>>
>>> The code in tools/env is really generic, but it becomes board specific
>>> just for the default environment. If the default environment can read in
>>> a reliable way from u-boot itslef (its binary), the tool can search for
>>> the default environment instead of linking again, and tools/env becomes
>>> "distro capable" - one binary that works on all boards.
>>>
>>> I have some thoughts and I would like to share, maybe some of you has
>>> better ideas. So what I would like to get directly from the binary is
>>> the offset of "default_environment" (default_environment)
>>> CONFIG_SYS_TEXT_BASE:
>>>
>>> - put this offset in the .img header. Yes, it works just for SPL /
>>> u-boot.img (drawback).
>>
>> How about putting the default environment in a FIT? That is typically
>> easy to find using the magic word.
>>
>>>
>>> - surround default environment with some easy to recognize magic number.
>>> Offset is not known, but user space can find it, like
>>>
>>> magic (long string)
>>> ...
>>> default_environment
>>> end default environment (long string)
>>>
>>
>> Seems like FIT would take care of this for you.
>>
>>> - adding a section in the linker. I think we tried something in the
>>> past, see __UBOOT_ENV_SECTION__ (it replaced __PPCENV__ from the old
>>> good mpc8xx times..) that is currently unused. I do not like this
>>> approach, it can increase (due to alignment) footprint in SPL, where I
>>> am starting to have issues for smaller i.MX.
>>
>> Also I wonder if compression might be useful? FIT supports that fairly 
>> easily.
> 
> I like the FIT idea, but in all proposals so far, you still have the
> problem of locating either the U-Boot binary or the FIT image. It's not
> always clear where they can be found.

Right. Things get even worse when a board can boot from several
storages, like from SD, from NOR and so on. It is then difficult to find
at runtime which is the correct image to check.

> 
> I've been having another idea in the back of my head for while, using a
> very different approach: Instead of requiring that the tool be able to
> fall back to a default environment, require that U-Boot write the
> environment to storage if the CRC check fails when it boots, and remove
> the ability to write to an uninitialized environment from the tools.

From my experience, this is often not desired by customers that do not
like that flash is touched at first start. It does not work in case of
CONFIG_ENV_IS_EMBEDDED, where we should skip the save. Anyway, I agree
that this helps in User Space because it is guaranteed that a suitable
environment is always present.

> This would guarantee that the environment is available in its expected
> storage location when entering userspace, and would also have the
> benefit of exposing dangerous situations where a newly flashed root
> filesystem has a /etc/fw_env.config which is wrong.

Well, if /etc/fw_env.config is broken, we cannot do a lot. But this is
like a bug and should be solved during the test phase.

> 
> The downside is that if the environment somehow gets messed up from
> userspace, you have to reboot to fix the problem. This could be
> somewhat, but not completely remedied by requiring a redundant environment. 

If userspace does not know how to handle the environment and the
environemnt gets messed up, the board could not boot anymore. We do not
know. The redundant environment guarantees us that changing the
environment is power-off safe, but there is no transactions mechanism
where the bootloader can easy step back to the previous one.

Łukasz told me yesterday that he has already sent some patches to
OE-Core to extract the default environment, even if this is not suitable
for an "updater" (our use case).

http://lists.openembedded.org/pipermail/openembedded-core/2018-April/150194.html

The patch is useful to generate a ready-to-flash image, but the exported
default environment could be used as input by the env tools in user
space when no environment is found.

Regards,
Stefano

-- 
=
DENX Software Engineering GmbH,  Managing 

Re: [U-Boot] [PATCH 1/2] board: move ppa firmware address in board specific kconfig

2018-05-03 Thread Prabhakar Kushwaha
Dear  Bhaskar,

> -Original Message-
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Bhaskar
> Upadhaya
> Sent: Thursday, May 3, 2018 3:58 PM
> To: u-boot@lists.denx.de
> Cc: Bhaskar Upadhaya 
> Subject: [U-Boot] [PATCH 1/2] board: move ppa firmware address in board
> specific kconfig
> 
> ppa firmware address may vary depending upon different boards, configure ppa
> firmware address in board specific kconfig
> 
> Signed-off-by: Bhaskar Upadhaya 
> ---
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig |  5 -
>  board/freescale/ls1012afrdm/Kconfig   |  4 
>  board/freescale/ls1012aqds/Kconfig|  3 +++
>  board/freescale/ls1012ardb/Kconfig|  8 
>  board/freescale/ls1043aqds/Kconfig|  4 
>  board/freescale/ls1043ardb/Kconfig|  4 
>  board/freescale/ls1046aqds/Kconfig|  4 
>  board/freescale/ls1046ardb/Kconfig|  5 +
>  board/freescale/ls1088a/Kconfig   |  8 
>  board/freescale/ls2080a/Kconfig   | 24 
>  board/freescale/ls2080aqds/Kconfig| 12 
>  board/freescale/ls2080ardb/Kconfig| 24 
>  12 files changed, 100 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> index 7edc06d..a4d544b 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> @@ -264,11 +264,6 @@ endchoice
>  config SYS_LS_PPA_FW_ADDR
>   hex "Address of PPA firmware loading from"
>   depends on FSL_LS_PPA
> - default 0x2040 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT &&
> ARCH_LS2080A
> - default 0x4040 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT
> - default 0x58040 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS2080A
> - default 0x2040 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1088A
> - default 0x6040 if SYS_LS_PPA_FW_IN_XIP
>   default 0x40 if SYS_LS_PPA_FW_IN_MMC
>   default 0x40 if SYS_LS_PPA_FW_IN_NAND


SYS_LS_PPA_FW_IN_MMC and SYS_LS_PPA_FW_IN_NAND should also be moved to board 
file. 

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


[U-Boot] [PATCH 2/2] board: ls1012a: FRWY-LS1012A board support

2018-05-03 Thread Bhaskar Upadhaya
FRWY-LS1012A belongs to LS1012A family with features
2 1G SGMII PFE MAC, Micro SD, USB 3.0, DDR, QuadSPI, Audio,
UART.

Signed-off-by: Bhaskar Upadhaya 
---
 arch/arm/Kconfig  |  12 +++
 arch/arm/cpu/armv8/Kconfig|   1 +
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/fsl-ls1012a-frwy.dts |  43 +++
 board/freescale/ls1012afrdm/Kconfig   |  35 +++--
 board/freescale/ls1012afrdm/MAINTAINERS   |   7 ++
 board/freescale/ls1012afrdm/eth.c |   3 +-
 board/freescale/ls1012afrdm/ls1012afrdm.c |  67 -
 configs/ls1012afrwy_qspi_defconfig|  49 
 include/configs/ls1012afrwy.h | 120 ++
 10 files changed, 329 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm/dts/fsl-ls1012a-frwy.dts
 create mode 100644 configs/ls1012afrwy_qspi_defconfig
 create mode 100644 include/configs/ls1012afrwy.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9bd70f4..d5d2dc7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -973,6 +973,18 @@ config TARGET_LS1012A2G5RDB
  development platform that supports the QorIQ LS1012A
  Layerscape Architecture processor.
 
+config TARGET_LS1012AFRWY
+   bool "Support ls1012afrwy"
+   select ARCH_LS1012A
+   select ARM64
+   imply SCSI
+   imply SCSI_AHCI
+   help
+Support for Freescale LS1012AFRWY platform.
+The LS1012A FRWY board (FRWY) is a high-performance
+development platform that supports the QorIQ LS1012A
+Layerscape Architecture processor.
+
 config TARGET_LS1012AFRDM
bool "Support ls1012afrdm"
select ARCH_LS1012A
diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig
index 3a0e129..22d2f29 100644
--- a/arch/arm/cpu/armv8/Kconfig
+++ b/arch/arm/cpu/armv8/Kconfig
@@ -91,6 +91,7 @@ config PSCI_RESET
   !TARGET_LS1088ARDB && !TARGET_LS1088AQDS && \
   !TARGET_LS1012ARDB && !TARGET_LS1012AFRDM && \
   !TARGET_LS1012A2G5RDB && !TARGET_LS1012AQDS && \
+  !TARGET_LS1012AFRWY && \
   !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \
   !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \
   !TARGET_LS2081ARDB && \
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ac7667b..8455587 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -225,7 +225,8 @@ dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1012a-qds.dtb \
fsl-ls1012a-rdb.dtb \
fsl-ls1012a-2g5rdb.dtb \
-   fsl-ls1012a-frdm.dtb
+   fsl-ls1012a-frdm.dtb \
+   fsl-ls1012a-frwy.dtb
 
 dtb-$(CONFIG_TARGET_DRAGONBOARD410C) += dragonboard410c.dtb
 dtb-$(CONFIG_TARGET_DRAGONBOARD820C) += dragonboard820c.dtb
diff --git a/arch/arm/dts/fsl-ls1012a-frwy.dts 
b/arch/arm/dts/fsl-ls1012a-frwy.dts
new file mode 100644
index 000..3158246
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1012a-frwy.dts
@@ -0,0 +1,43 @@
+/*
+ * NXP ls1012a FRWY board device tree source
+ *
+ * Copyright 2018 NXP
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+/dts-v1/;
+#include "fsl-ls1012a.dtsi"
+
+/ {
+   model = "FRWY-LS1012A Board";
+
+   aliases {
+   spi0 = 
+   };
+
+   chosen {
+   stdout-path = 
+   };
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   qflash0: w25q16dw@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <2000>;
+   reg = <0>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/board/freescale/ls1012afrdm/Kconfig 
b/board/freescale/ls1012afrdm/Kconfig
index fd33807..73ad2fe 100644
--- a/board/freescale/ls1012afrdm/Kconfig
+++ b/board/freescale/ls1012afrdm/Kconfig
@@ -12,20 +12,23 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "ls1012afrdm"
 
+config SYS_LS_PFE_FW_ADDR
+   hex "Flash address of PFE firmware"
+   default 0x40a0
+
 config SYS_LS_PPA_FW_ADDR
hex "PPA Firmware Addr"
default 0x4040
 
+endif
+
 if FSL_PFE
 
 config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
select PHYLIB
imply PHY_REALTEK
-
-config SYS_LS_PFE_FW_ADDR
-   hex "Flash address of PFE firmware"
-   default 0x40a0
+   imply PHY_ATHEROS
 
 config DDR_PFE_PHYS_BASEADDR
hex "PFE DDR physical base address"
@@ -45,6 +48,28 @@ config PFE_EMAC2_PHY_ADDR
 
 endif
 
-source "board/freescale/common/Kconfig"
+if TARGET_LS1012AFRWY
+
+config SYS_BOARD
+   default "ls1012afrdm"
+
+config SYS_VENDOR
+   default "freescale"
+
+config SYS_SOC
+   default "fsl-layerscape"
+
+config SYS_CONFIG_NAME
+   default "ls1012afrwy"
+
+config SYS_LS_PFE_FW_ADDR
+   hex "Flash address of PFE firmware"

[U-Boot] [PATCH 1/2] board: move ppa firmware address in board specific kconfig

2018-05-03 Thread Bhaskar Upadhaya
ppa firmware address may vary depending upon different boards,
configure ppa firmware address in board specific kconfig

Signed-off-by: Bhaskar Upadhaya 
---
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig |  5 -
 board/freescale/ls1012afrdm/Kconfig   |  4 
 board/freescale/ls1012aqds/Kconfig|  3 +++
 board/freescale/ls1012ardb/Kconfig|  8 
 board/freescale/ls1043aqds/Kconfig|  4 
 board/freescale/ls1043ardb/Kconfig|  4 
 board/freescale/ls1046aqds/Kconfig|  4 
 board/freescale/ls1046ardb/Kconfig|  5 +
 board/freescale/ls1088a/Kconfig   |  8 
 board/freescale/ls2080a/Kconfig   | 24 
 board/freescale/ls2080aqds/Kconfig| 12 
 board/freescale/ls2080ardb/Kconfig| 24 
 12 files changed, 100 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 7edc06d..a4d544b 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -264,11 +264,6 @@ endchoice
 config SYS_LS_PPA_FW_ADDR
hex "Address of PPA firmware loading from"
depends on FSL_LS_PPA
-   default 0x2040 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT && ARCH_LS2080A
-   default 0x4040 if SYS_LS_PPA_FW_IN_XIP && QSPI_BOOT
-   default 0x58040 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS2080A
-   default 0x2040 if SYS_LS_PPA_FW_IN_XIP && ARCH_LS1088A
-   default 0x6040 if SYS_LS_PPA_FW_IN_XIP
default 0x40 if SYS_LS_PPA_FW_IN_MMC
default 0x40 if SYS_LS_PPA_FW_IN_NAND
 
diff --git a/board/freescale/ls1012afrdm/Kconfig 
b/board/freescale/ls1012afrdm/Kconfig
index 22d521b..fd33807 100644
--- a/board/freescale/ls1012afrdm/Kconfig
+++ b/board/freescale/ls1012afrdm/Kconfig
@@ -12,6 +12,10 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "ls1012afrdm"
 
+config SYS_LS_PPA_FW_ADDR
+   hex "PPA Firmware Addr"
+   default 0x4040
+
 if FSL_PFE
 
 config BOARD_SPECIFIC_OPTIONS # dummy
diff --git a/board/freescale/ls1012aqds/Kconfig 
b/board/freescale/ls1012aqds/Kconfig
index c0b12ed..b702fb2 100644
--- a/board/freescale/ls1012aqds/Kconfig
+++ b/board/freescale/ls1012aqds/Kconfig
@@ -12,6 +12,9 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "ls1012aqds"
 
+config SYS_LS_PPA_FW_ADDR
+hex "PPA Firmware Addr"
+default 0x4040
 
 if FSL_PFE
 
diff --git a/board/freescale/ls1012ardb/Kconfig 
b/board/freescale/ls1012ardb/Kconfig
index 493d477..0b873dd 100644
--- a/board/freescale/ls1012ardb/Kconfig
+++ b/board/freescale/ls1012ardb/Kconfig
@@ -12,6 +12,10 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "ls1012ardb"
 
+config SYS_LS_PPA_FW_ADDR
+hex "PPA Firmware Addr"
+default 0x4040
+
 if FSL_PFE
 
 config BOARD_SPECIFIC_OPTIONS # dummy
@@ -59,6 +63,10 @@ config SYS_SOC
 config SYS_CONFIG_NAME
 default "ls1012a2g5rdb"
 
+config SYS_LS_PPA_FW_ADDR
+hex "PPA Firmware Addr"
+default 0x4040
+
 if FSL_PFE
 
 config BOARD_SPECIFIC_OPTIONS # dummy
diff --git a/board/freescale/ls1043aqds/Kconfig 
b/board/freescale/ls1043aqds/Kconfig
index 95d2888..d44b20e 100644
--- a/board/freescale/ls1043aqds/Kconfig
+++ b/board/freescale/ls1043aqds/Kconfig
@@ -12,6 +12,10 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "ls1043aqds"
 
+config SYS_LS_PPA_FW_ADDR
+hex "PPA Firmware Addr"
+default 0x4040
+
 source "board/freescale/common/Kconfig"
 
 endif
diff --git a/board/freescale/ls1043ardb/Kconfig 
b/board/freescale/ls1043ardb/Kconfig
index 1bab7ca..2b21222 100644
--- a/board/freescale/ls1043ardb/Kconfig
+++ b/board/freescale/ls1043ardb/Kconfig
@@ -22,6 +22,10 @@ config SYS_HAS_ARMV8_SECURE_BASE
  If enabled, please also define the value for ARMV8_SECURE_BASE,
  for LS1043ARDB, it could be some address in OCRAM.
 
+config SYS_LS_PPA_FW_ADDR
+hex "PPA Firmware Addr"
+default 0x4040
+
 source "board/freescale/common/Kconfig"
 
 endif
diff --git a/board/freescale/ls1046aqds/Kconfig 
b/board/freescale/ls1046aqds/Kconfig
index 070827d..4f604b1 100644
--- a/board/freescale/ls1046aqds/Kconfig
+++ b/board/freescale/ls1046aqds/Kconfig
@@ -12,6 +12,10 @@ config SYS_SOC
 config SYS_CONFIG_NAME
default "ls1046aqds"
 
+config SYS_LS_PPA_FW_ADDR
+hex "PPA Firmware Addr"
+default 0x4040
+
 source "board/freescale/common/Kconfig"
 
 endif
diff --git a/board/freescale/ls1046ardb/Kconfig 
b/board/freescale/ls1046ardb/Kconfig
index b9f2ed7..96f34da 100644
--- a/board/freescale/ls1046ardb/Kconfig
+++ b/board/freescale/ls1046ardb/Kconfig
@@ -12,5 +12,10 @@ config SYS_SOC
 
 config SYS_CONFIG_NAME
default "ls1046ardb"
+
+config SYS_LS_PPA_FW_ADDR
+hex "PPA Firmware Addr"
+default 0x4040
+
 source 

Re: [U-Boot] [PATCH v2 1/2] net: Add Kconfig option for BOOTP_NTPSERVER

2018-05-03 Thread Joe Hershberger
On Thu, May 3, 2018 at 3:19 AM, Chris Packham  wrote:
> Add a Kconfig option for BOOTP_NTPSERVER to enable the DHCP/BOOTP option
> to configure the sntp server address.
>
> Signed-off-by: Chris Packham 

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


Re: [U-Boot] mainline u-boot on radxarock (rockchip rk3188) from SDcard

2018-05-03 Thread Trevor Woerner
Hi Jaehoon and Kever,

On Wed, May 2, 2018 at 4:11 AM, Jaehoon Chung 
wrote:

> Hi,
>
> On 05/02/2018 04:10 PM, Kever Yang wrote:
> > Hi Trevor,
> >
> > It looks like the mmc driver does not work correctly, and no
> > emmc/sdcard found.
> >
> > Maybe you can enable 'DEBUG' and get more detail about what happen.
>

Is enabling DEBUG just a matter of increasing the logging levels
(CONFIG_LOGLEVEL and CONFIG_LOG_MAX_LEVEL) to 7, or is something else
required?


> >
> >
> > Thanks,
> > - Kever
> > On 04/29/2018 01:35 PM, Trevor Woerner wrote:
> >> Hello,
> >>
> >> I am able to generate a bootable image (bootloader, parameter, kernel,
> >> filesystem) for my radxarock (pro) on an SDcard if I use the bootloader
> from
> >> https://github.com/radxa/u-boot-rockchip. When I try to use mainline
> >> u-boot_2008.01 it doesn't seem to be able to find or boot from the
> SDcard:
>
> Do you use the dwmmc driver? or which driver are you using?
> And Could you share which defconfig is used?
>
> Plz, CC'd me.
>
>
I'm using rock_defconfig, currently without any changes, as such
MMC_DW_ROCKCHIP is enabled.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] net: mvgbe: remove CONFIG_DOVE

2018-05-03 Thread Joe Hershberger
On Thu, May 3, 2018 at 6:00 AM, Chris Packham  wrote:
> Nothing defines CONFIG_DOVE so remove the code that uses it.
>
> Signed-off-by: Chris Packham 

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


Re: [U-Boot] [PATCH 2/2] net: bootp: Fix compile error processing ntpserver option

2018-05-03 Thread Joe Hershberger
On Thu, May 3, 2018 at 3:17 AM, Chris Packham  wrote:
> On Thu, May 3, 2018 at 12:23 PM Joe Hershberger 
> wrote:
>
>> On Fri, Apr 27, 2018 at 4:55 AM, Chris Packham 
> wrote:
>> > When the following configuration is set
>> >
>> >   # CONFIG_CMD_DHCP is not set
>> >   CONFIG_CMD_BOOTP=y
>> >   CONFIG_BOOTP_NTPSERVER=y
>> >
>> > The following compile error is observed
>> >
>> >   error: used struct type value where scalar is required
>> > if (net_ntp_server)
>> > ^~
>
>> We should probably enable CMD_SNTP in devkit8000 so that this code
>> path is compiled on travis. Can you add a patch for that to the
>> series?
>
> It's not quite that simple. CONFIG_CMD_DHCP is selected by
> CONFIG_DISTRO_DEFAULTS. So just turning on CMD_SNTP doesn't catch this.
> It'd be a fairly invasive change to disable CONFIG_DISTRO_DEFAULTS. For now
> I'll send a v2 series with just the changes for 1/2.

Sounds good. Maybe it would be easier to enable the combo needed to
instigate this on a board that does not use DISTRO_DEFAULTS.

>
>> >
>> > Resolve this by checking net_ntp_server.s_addr instead.
>> >
>> > Signed-off-by: Chris Packham 
>
>> Acked-by: Joe Hershberger 
>
>> > ---
>> >
>> >  net/bootp.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/net/bootp.c b/net/bootp.c
>> > index efa959971c27..9d7cb5d30c14 100644
>> > --- a/net/bootp.c
>> > +++ b/net/bootp.c
>> > @@ -333,7 +333,7 @@ static void bootp_process_vendor(u8 *ext, int size)
>> > debug("net_nis_domain : %s\n", net_nis_domain);
>> >
>> >  #if defined(CONFIG_CMD_SNTP) && defined(CONFIG_BOOTP_NTPSERVER)
>> > -   if (net_ntp_server)
>> > +   if (net_ntp_server.s_addr)
>> > debug("net_ntp_server : %pI4\n", _ntp_server);
>> >  #endif
>> >  }
>> > --
>> > 2.17.0
>> >
>> > ___
>> > U-Boot mailing list
>> > U-Boot@lists.denx.de
>> > https://lists.denx.de/listinfo/u-boot
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] arm: mach-omap2: cache: Explicitly enable I cache

2018-05-03 Thread Jean-Jacques Hiblot



On 03/05/2018 17:04, Lokesh Vutla wrote:

omap-common cache enabling sequence relies on cpu_init_cp15()
(inside start.S) for enabling I-caches. But cpu_init_cp15()
can be skipped if CONFIG_SKIP_LOWLEVEL_INIT is defined. So
enable I-caches if not enabled already.

Debugged-by: Jean-Jacques Hiblot 
Tested-by: Steve Kipisz 
Signed-off-by: Lokesh Vutla 
---
  arch/arm/mach-omap2/omap-cache.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap-cache.c b/arch/arm/mach-omap2/omap-cache.c
index b37163a4f3..975ee1b020 100644
--- a/arch/arm/mach-omap2/omap-cache.c
+++ b/arch/arm/mach-omap2/omap-cache.c
@@ -44,7 +44,11 @@ DECLARE_GLOBAL_DATA_PTR;
  
  void enable_caches(void)

  {
-   /* Enable D-cache. I-cache is already enabled in start.S */
+
+   /* Enable I cache if not enabled */
+   if (!icache_status())
+   icache_enable();
+
dcache_enable();
  }
  


Tested-by: Jean-Jacques Hiblot 

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


[U-Boot] [PATCH] arm: mach-omap2: cache: Explicitly enable I cache

2018-05-03 Thread Lokesh Vutla
omap-common cache enabling sequence relies on cpu_init_cp15()
(inside start.S) for enabling I-caches. But cpu_init_cp15()
can be skipped if CONFIG_SKIP_LOWLEVEL_INIT is defined. So
enable I-caches if not enabled already.

Debugged-by: Jean-Jacques Hiblot 
Tested-by: Steve Kipisz 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-omap2/omap-cache.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap-cache.c b/arch/arm/mach-omap2/omap-cache.c
index b37163a4f3..975ee1b020 100644
--- a/arch/arm/mach-omap2/omap-cache.c
+++ b/arch/arm/mach-omap2/omap-cache.c
@@ -44,7 +44,11 @@ DECLARE_GLOBAL_DATA_PTR;
 
 void enable_caches(void)
 {
-   /* Enable D-cache. I-cache is already enabled in start.S */
+
+   /* Enable I cache if not enabled */
+   if (!icache_status())
+   icache_enable();
+
dcache_enable();
 }
 
-- 
2.17.0

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


Re: [U-Boot] [PATCHv2 2/2] stdio_names: Ensure MAX_NAMES is defined before use, don't use 3 directly

2018-05-03 Thread Peter Robinson
On Thu, May 3, 2018 at 2:12 PM, Tom Rini  wrote:
> With tighter build flags the fact that  doesn't have a
> reference back to MAX_NAMES causes an error.  Include  here and
> then in common/console.c use MAX_NAMES rather than 3 when working with
> stdio_names.
>
> Reported-by: Peter Robinson 
> Signed-off-by: Tom Rini 
> ---
> Changes in v2:
> - New patch
> ---
>  common/console.c| 4 ++--
>  include/stdio_dev.h | 1 +
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/common/console.c b/common/console.c
> index 0e0295514b21..f1a5e95c8f39 100644
> --- a/common/console.c
> +++ b/common/console.c
> @@ -847,7 +847,7 @@ done:
>
>  #ifdef CONFIG_SYS_CONSOLE_ENV_OVERWRITE
> /* set the environment variables (will overwrite previous env 
> settings) */
> -   for (i = 0; i < 3; i++) {
> +   for (i = 0; i < MAX_NAMES; i++) {

I think you mean MAX_FILES? With MAX_NAMES it fails, with MAX_FILES it builds.

With the that change, if it's correct:
Tested-by: Peter Robinson 

> env_set(stdio_names[i], stdio_devices[i]->name);
> }
>  #endif /* CONFIG_SYS_CONSOLE_ENV_OVERWRITE */
> @@ -926,7 +926,7 @@ int console_init_r(void)
>  #endif /* CONFIG_SYS_CONSOLE_INFO_QUIET */
>
> /* Setting environment variables */
> -   for (i = 0; i < 3; i++) {
> +   for (i = 0; i < MAX_NAMES; i++) {
> env_set(stdio_names[i], stdio_devices[i]->name);
> }
>
> diff --git a/include/stdio_dev.h b/include/stdio_dev.h
> index 1ea8bff47bab..c2a88b4fc416 100644
> --- a/include/stdio_dev.h
> +++ b/include/stdio_dev.h
> @@ -8,6 +8,7 @@
>  #ifndef _STDIO_DEV_H_
>  #define _STDIO_DEV_H_
>
> +#include 
>  #include 
>
>  /*
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCHv2 2/2] stdio_names: Ensure MAX_NAMES is defined before use, don't use 3 directly

2018-05-03 Thread Tom Rini
With tighter build flags the fact that  doesn't have a
reference back to MAX_NAMES causes an error.  Include  here and
then in common/console.c use MAX_NAMES rather than 3 when working with
stdio_names.

Reported-by: Peter Robinson 
Signed-off-by: Tom Rini 
---
Changes in v2:
- New patch
---
 common/console.c| 4 ++--
 include/stdio_dev.h | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/common/console.c b/common/console.c
index 0e0295514b21..f1a5e95c8f39 100644
--- a/common/console.c
+++ b/common/console.c
@@ -847,7 +847,7 @@ done:
 
 #ifdef CONFIG_SYS_CONSOLE_ENV_OVERWRITE
/* set the environment variables (will overwrite previous env settings) 
*/
-   for (i = 0; i < 3; i++) {
+   for (i = 0; i < MAX_NAMES; i++) {
env_set(stdio_names[i], stdio_devices[i]->name);
}
 #endif /* CONFIG_SYS_CONSOLE_ENV_OVERWRITE */
@@ -926,7 +926,7 @@ int console_init_r(void)
 #endif /* CONFIG_SYS_CONSOLE_INFO_QUIET */
 
/* Setting environment variables */
-   for (i = 0; i < 3; i++) {
+   for (i = 0; i < MAX_NAMES; i++) {
env_set(stdio_names[i], stdio_devices[i]->name);
}
 
diff --git a/include/stdio_dev.h b/include/stdio_dev.h
index 1ea8bff47bab..c2a88b4fc416 100644
--- a/include/stdio_dev.h
+++ b/include/stdio_dev.h
@@ -8,6 +8,7 @@
 #ifndef _STDIO_DEV_H_
 #define _STDIO_DEV_H_
 
+#include 
 #include 
 
 /*
-- 
2.7.4

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


[U-Boot] [PATCHv2 1/2] stdio_dev.h: Drop the video section as it is unused

2018-05-03 Thread Tom Rini
With tighter build flags the fact that this header referenced
uchar/ushort without including what typedefs it causes an error.  Rather
than add another include here, drop the section in question as it is
unused.

Reported-by: Peter Robinson 
Tested-by: Peter Robinson 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Reword slightly, add Tested-by
---
 include/stdio_dev.h | 18 --
 1 file changed, 18 deletions(-)

diff --git a/include/stdio_dev.h b/include/stdio_dev.h
index 3164fa2a5579..1ea8bff47bab 100644
--- a/include/stdio_dev.h
+++ b/include/stdio_dev.h
@@ -49,24 +49,6 @@ struct stdio_dev {
 };
 
 /*
- * VIDEO EXTENSIONS
- */
-#define VIDEO_FORMAT_RGB_INDEXED   0x
-#define VIDEO_FORMAT_RGB_DIRECTCOLOR   0x0001
-#define VIDEO_FORMAT_YUYV_4_4_40x0010
-#define VIDEO_FORMAT_YUYV_4_2_20x0011
-
-typedef struct {
-   void *address;  /* Address of framebuffer   
*/
-   ushort  width;  /* Horizontal resolution
*/
-   ushort  height; /* Vertical resolution  
*/
-   uchar   format; /* Format   
*/
-   uchar   colors; /* Colors number or color depth 
*/
-   void (*setcolreg) (int, int, int, int);
-   void (*getcolreg) (int, void *);
-} video_ext_t;
-
-/*
  * VARIABLES
  */
 extern struct stdio_dev *stdio_devices[];
-- 
2.7.4

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


Re: [U-Boot] [RFC] Exporting defaul environment

2018-05-03 Thread Kristian Amlie
On 02/05/18 21:32, Simon Glass wrote:
> Hi Stefano,
> 
> On 2 May 2018 at 02:48, Stefano Babic  wrote:
>>
>> Hi,
>>
>> I am thinking about how it is possible to export in a clean way the
>> default environment from u-boot. The general use case happens when the
>> environment must be changed from user space (via fw_setenv or whatever)
>> and no environment was still stored - board boots with default environment.
>>
>> Up now, the trick is to compile the environment tools (u-boot-fw-utils
>> in Yocto) with exactly the same U-Boot sources. This works, but it is
>> error prone when a new Yocto version is delivered (and maybe with a
>> different u-boot-fw-utils) or even if the bootloader is updated. I am
>> searching for an alterntive method.
>>
>> The code in tools/env is really generic, but it becomes board specific
>> just for the default environment. If the default environment can read in
>> a reliable way from u-boot itslef (its binary), the tool can search for
>> the default environment instead of linking again, and tools/env becomes
>> "distro capable" - one binary that works on all boards.
>>
>> I have some thoughts and I would like to share, maybe some of you has
>> better ideas. So what I would like to get directly from the binary is
>> the offset of "default_environment" (default_environment)
>> CONFIG_SYS_TEXT_BASE:
>>
>> - put this offset in the .img header. Yes, it works just for SPL /
>> u-boot.img (drawback).
> 
> How about putting the default environment in a FIT? That is typically
> easy to find using the magic word.
> 
>>
>> - surround default environment with some easy to recognize magic number.
>> Offset is not known, but user space can find it, like
>>
>> magic (long string)
>> ...
>> default_environment
>> end default environment (long string)
>>
> 
> Seems like FIT would take care of this for you.
> 
>> - adding a section in the linker. I think we tried something in the
>> past, see __UBOOT_ENV_SECTION__ (it replaced __PPCENV__ from the old
>> good mpc8xx times..) that is currently unused. I do not like this
>> approach, it can increase (due to alignment) footprint in SPL, where I
>> am starting to have issues for smaller i.MX.
> 
> Also I wonder if compression might be useful? FIT supports that fairly easily.

I like the FIT idea, but in all proposals so far, you still have the
problem of locating either the U-Boot binary or the FIT image. It's not
always clear where they can be found.

I've been having another idea in the back of my head for while, using a
very different approach: Instead of requiring that the tool be able to
fall back to a default environment, require that U-Boot write the
environment to storage if the CRC check fails when it boots, and remove
the ability to write to an uninitialized environment from the tools.
This would guarantee that the environment is available in its expected
storage location when entering userspace, and would also have the
benefit of exposing dangerous situations where a newly flashed root
filesystem has a /etc/fw_env.config which is wrong.

The downside is that if the environment somehow gets messed up from
userspace, you have to reboot to fix the problem. This could be
somewhat, but not completely remedied by requiring a redundant environment.

-- 
Kristian



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


Re: [U-Boot] [PATCH v3 25/25] tpm: allow Sandbox to run TPMv2.x commands

2018-05-03 Thread Miquel Raynal
Hi Simon,

On Wed, 2 May 2018 20:32:55 -0600, Simon Glass  wrote:

> Hi Miquel,
> 
> On 2 May 2018 at 02:59, Miquel Raynal  wrote:
> > Sandbx is run in userspace. What is done in baremetal applications like
> > U-Boot is using an address in memory which is supposedly free to load
> > and store data to it. The user interaction in U-Boot's shell works like
> > that and it is hard to find another way to transfer a 'buffer' from one
> > side to the other. It is always possible to fill an environment
> > variable, but not that easy to use.
> >
> > Of course our Linux distributions do not allow such salvage accesses and
> > Sandbox will simply be killed. To avoid such scenario, it is possible,
> > when compiling the Sandbox driver, to allocate some memory so the
> > pointer that is given does not point to an unauthorized area anymore.
> > This just give the possibility to run all the TPM commands without
> > killing Sandbox.
> >  
> 
> map_sysmem() and map_to_sysmem() are supposed to handle this, assuming
> I understand the problem correctly.

Thank you very much for this, I searched a better solution to handle
it, even asked on #u-boot but ended using these horrible hacks.

I will drop this patch and integrate the map_*sysmem() functions as and
when appropriate.

Thanks,
Miquèl

-- 
Miquel Raynal, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 22/25] doc: device-tree-bindings: add Sandbox TPMv2.0 module info

2018-05-03 Thread Miquel Raynal
Hi Simon,

On Wed, 2 May 2018 20:32:46 -0600, Simon Glass  wrote:

> On 2 May 2018 at 02:59, Miquel Raynal  wrote:
> > Add Sandbox TPMv2.0 module bindings.
> >
> > Signed-off-by: Miquel Raynal 
> > ---
> >  doc/device-tree-bindings/tpm2/sandbox.txt | 11 +++
> >  1 file changed, 11 insertions(+)
> >  create mode 100644 doc/device-tree-bindings/tpm2/sandbox.txt  
> 
> Add to test.dts too? That is what is used for running tests.

Absolutely, this is done a bit later in the series.

Thanks,
Miquèl

> 
> Reviewed-by: Simon Glass 



-- 
Miquel Raynal, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v3 04/25] tpm: prepare support for TPMv2.x commands

2018-05-03 Thread Miquel Raynal
Hi Simon,

Thanks for reviewing all of this.

On Wed, 2 May 2018 20:31:50 -0600, Simon Glass  wrote:

> Hi Miquel,
> 
> On 2 May 2018 at 02:59, Miquel Raynal  wrote:
> > Choice between v1 and v2 compliant functions is done with the
> > configuration.
> >
> > Create the various files that will receive TPMv2-only code on the same
> > scheme as for the TPMv1 code.
> >
> > Signed-off-by: Miquel Raynal 
> > ---
> >  cmd/Makefile |   1 +
> >  cmd/tpm-v2.c |  33 
> >  drivers/tpm/tpm-uclass.c |   2 +
> >  include/tpm-v2.h | 128 
> > +++
> >  lib/Makefile |   1 +
> >  lib/tpm-v2.c |  11 
> >  6 files changed, 176 insertions(+)
> >  create mode 100644 cmd/tpm-v2.c
> >  create mode 100644 include/tpm-v2.h
> >  create mode 100644 lib/tpm-v2.c
> >
> > diff --git a/cmd/Makefile b/cmd/Makefile
> > index 66732085e8..bdb5475e07 100644
> > --- a/cmd/Makefile
> > +++ b/cmd/Makefile
> > @@ -120,6 +120,7 @@ obj-$(CONFIG_HUSH_PARSER) += test.o
> >  obj-$(CONFIG_CMD_TPM) += tpm-common.o
> >  obj-$(CONFIG_CMD_TPM_V1) += tpm-v1.o
> >  obj-$(CONFIG_CMD_TPM_TEST) += tpm_test.o
> > +obj-$(CONFIG_CMD_TPM_V2) += tpm-v2.o
> >  obj-$(CONFIG_CMD_CROS_EC) += cros_ec.o
> >  obj-$(CONFIG_CMD_TSI148) += tsi148.o
> >  obj-$(CONFIG_CMD_UBI) += ubi.o
> > diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
> > new file mode 100644
> > index 00..606aa92409
> > --- /dev/null
> > +++ b/cmd/tpm-v2.c
> > @@ -0,0 +1,33 @@
> > +// SPDX-License-Identifier:GPL-2.0+
> > +/*
> > + * Copyright (c) 2018 Bootlin
> > + * Authoredr: Miquel Raynal 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "tpm-user-utils.h"
> > +
> > +static cmd_tbl_t tpm2_commands[] = {
> > +   U_BOOT_CMD_MKENT(info, 0, 1, do_tpm_info, "", ""),
> > +   U_BOOT_CMD_MKENT(init, 0, 1, do_tpm_init, "", ""),
> > +};
> > +
> > +cmd_tbl_t *get_tpm_commands(unsigned int *size)  
> 
> Why is this exported? Is it used somewhere else?

Indeed, this function is exported in both tpm-v1.c and tpm-v2.c (only
one is compiled at a time) and shared code (tpm-common.c) call this
function to retrieve the commands array.

> 
> > +{
> > +   *size = ARRAY_SIZE(tpm2_commands);
> > +
> > +   return tpm2_commands;
> > +}
> > +  
> 
> Reviewed-by: Simon Glass 

Thanks,
Miquèl

-- 
Miquel Raynal, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/2] ARC: enable debug uart for HSDK and AXS10x boards

2018-05-03 Thread Eugeniy Paltsev
Signed-off-by: Eugeniy Paltsev 
---
 configs/axs101_defconfig | 5 +
 configs/axs103_defconfig | 5 +
 configs/hsdk_defconfig   | 5 +
 3 files changed, 15 insertions(+)

diff --git a/configs/axs101_defconfig b/configs/axs101_defconfig
index 25b10888ced..559ed4734c1 100644
--- a/configs/axs101_defconfig
+++ b/configs/axs101_defconfig
@@ -3,6 +3,7 @@ CONFIG_TARGET_AXS101=y
 CONFIG_SYS_TEXT_BASE=0x8100
 CONFIG_SYS_CLK_FREQ=75000
 CONFIG_DEFAULT_DEVICE_TREE="axs101"
+CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="console=ttyS3,115200n8"
@@ -33,6 +34,10 @@ CONFIG_DM_ETH=y
 CONFIG_PHY_GIGE=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_DM_SERIAL=y
+CONFIG_DEBUG_UART_BASE=0xe0022000
+CONFIG_DEBUG_UART_CLOCK=
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
diff --git a/configs/axs103_defconfig b/configs/axs103_defconfig
index b9d387b88a8..8b66451307d 100644
--- a/configs/axs103_defconfig
+++ b/configs/axs103_defconfig
@@ -3,6 +3,7 @@ CONFIG_ISA_ARCV2=y
 CONFIG_SYS_TEXT_BASE=0x8100
 CONFIG_SYS_CLK_FREQ=1
 CONFIG_DEFAULT_DEVICE_TREE="axs103"
+CONFIG_DEBUG_UART=y
 CONFIG_BOOTDELAY=3
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="console=ttyS3,115200n8"
@@ -33,6 +34,10 @@ CONFIG_DM_ETH=y
 CONFIG_PHY_GIGE=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_DM_SERIAL=y
+CONFIG_DEBUG_UART_BASE=0xe0022000
+CONFIG_DEBUG_UART_CLOCK=
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_SYS_NS16550=y
 CONFIG_USB=y
 CONFIG_DM_USB=y
diff --git a/configs/hsdk_defconfig b/configs/hsdk_defconfig
index d23acfeb878..28cd1dd70c4 100644
--- a/configs/hsdk_defconfig
+++ b/configs/hsdk_defconfig
@@ -4,6 +4,7 @@ CONFIG_TARGET_HSDK=y
 CONFIG_SYS_TEXT_BASE=0x8100
 CONFIG_SYS_CLK_FREQ=5
 CONFIG_DEFAULT_DEVICE_TREE="hsdk"
+CONFIG_DEBUG_UART=y
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="console=ttyS0,115200n8"
 CONFIG_BOARD_EARLY_INIT_F=y
@@ -42,6 +43,10 @@ CONFIG_SPI_FLASH_SST=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_DM_SERIAL=y
+CONFIG_DEBUG_UART_BASE=0xf0005000
+CONFIG_DEBUG_UART_CLOCK=
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_DEBUG_UART_ANNOUNCE=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
-- 
2.14.3

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


[U-Boot] [PATCH 0/2] ARC: enable debug uart for HSDK and AXS10x boards

2018-05-03 Thread Eugeniy Paltsev
Eugeniy Paltsev (2):
  ARC: init debug uart in early common arc code
  ARC: enable debug uart for HSDK and AXS10x boards

 arch/arc/lib/start.S | 5 +
 configs/axs101_defconfig | 5 +
 configs/axs103_defconfig | 5 +
 configs/hsdk_defconfig   | 5 +
 4 files changed, 20 insertions(+)

-- 
2.14.3

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


[U-Boot] [PATCH 1/2] ARC: init debug uart in early common arc code

2018-05-03 Thread Eugeniy Paltsev
The debug UART is intended for use very early in U-Boot to debug
problems before serial drivers are up.

Call debug_uart_init right before board_init_f.

Signed-off-by: Eugeniy Paltsev 
---
 arch/arc/lib/start.S | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arc/lib/start.S b/arch/arc/lib/start.S
index c78dd001d81..cb8ea0fd363 100644
--- a/arch/arc/lib/start.S
+++ b/arch/arc/lib/start.S
@@ -76,6 +76,11 @@ ENTRY(_start)
/* Initialize reserved area - note: r0 already contains address */
bl  board_init_f_init_reserve
 
+#ifdef CONFIG_DEBUG_UART
+   /* Earliest point to set up early debug uart */
+   bl  debug_uart_init
+#endif
+
/* Zero the one and only argument of "board_init_f" */
mov_s   %r0, 0
bl  board_init_f
-- 
2.14.3

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


[U-Boot] [PATCH] Fix Ymodem build when DEBUG and CONFIG_USE_TINY_PRINTF are selected

2018-05-03 Thread Alex Kiernan
Attempting to build with both DEBUG and CONFIG_USE_TINY_PRINTF along
with CONFIG_SPL_YMODEM_SUPPORT fails at link time:

  common/built-in.o: In function `zm_dprintf':
  common/xyzModem.c:190: undefined reference to `vsprintf'

Disable Ymodem debug if we don't have full vsprintf support.

Signed-off-by: Alex Kiernan 
---

 common/xyzModem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/xyzModem.c b/common/xyzModem.c
index a0c5dfe..8f830bb 100644
--- a/common/xyzModem.c
+++ b/common/xyzModem.c
@@ -172,7 +172,7 @@ parse_num (char *s, unsigned long *val, char **es, char 
*delim)
 }
 
 
-#ifdef DEBUG
+#if defined(DEBUG) && !defined(CONFIG_USE_TINY_PRINTF)
 /*
  * Note: this debug setup works by storing the strings in a fixed buffer
  */
-- 
2.7.4

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


Re: [U-Boot] [PATCH 1/2] net: mvgbe: remove CONFIG_DOVE

2018-05-03 Thread Stefan Roese

On 03.05.2018 13:00, Chris Packham wrote:

Nothing defines CONFIG_DOVE so remove the code that uses it.

Signed-off-by: Chris Packham 


Reviewed-by: Stefan Roese 

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


Re: [U-Boot] [PATCH 2/2] spi: kirkwood: Full dm conversion

2018-05-03 Thread Stefan Roese

Hi Chris,

On 02.05.2018 23:56, Chris Packham wrote:

Hi All,
On Wed, May 2, 2018 at 10:53 PM Stefan Roese  wrote:


Hi Simon,



On 01.05.2018 12:54, Simon Guinot wrote:

On Mon, Apr 30, 2018 at 11:28:28AM +0530, Jagan Teki wrote:

On Fri, Apr 27, 2018 at 2:21 PM, Simon Guinot <

simon.gui...@sequanux.org> wrote:

On Thu, Apr 26, 2018 at 11:30:00AM +0530, Jagan Teki wrote:

On Thu, Mar 15, 2018 at 5:03 PM, Jagan Teki <

ja...@amarulasolutions.com> wrote:

kirkwood now support dt along with platform data,
respective boards need to switch into dm for the same.


Added all board mainatiner, using this driver on their relevant
boards. So try to switch to DM_SPI(SPI_FLASH) before migration
deadline expires.


Hi Jagan,

And what is the deadline exactly ?


See DM_SPI/SPI_FLASH migration details from,

doc/driver-model/MIGRATION.txt


Thanks for letting me know Jagan...



Just to be clear here. The older Marvell platforms Orion and Kirkwood
completely lack DM (Driver-Model) and DT (Device-Tree) support in
U-Boot. This needs to be added (similar to what I've done to the
newer parts beginning with Armada XP / 38x) so that the SPI driver
(and others) can be used as DM-enabled driver.



Please see arch/arm/mach-mvebu/ for more details here.



Any work on this is greatly appreciated as I fear that the support
for these older SoC's might get dropped completely otherwise soon.


I had a quick try on one of the kirkwood based boards I have. It was pretty
easy to bring in the dts files from Linux and get some basic stuff working.
I started with i2c since I can still boot without it, I haven't been brave
enough to try spi yet.

Hopefully I can spend a bit more time on it over the weekend.


This sound just great. Thanks.


In terms of a long-term plan. I could upstream support for our board, we
still include it in the source we distribute as part of our GPL compliance.
Since it's a older board that has been fairly stable we're not doing a lot
of development on it. My motivation for retaining support for kirkwood is
just in case we have some other EOL part that requires us to release a new
bootloader. I could do a blind conversion of other in-tree kirkwood boards
but my ability to test them would be quite limited.


This "blind conversion" is definitely much better, than the removal.
Others might be able to test some of the boards. I don't have any of
those - so I can't help out here.

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


[U-Boot] [PATCH 1/2] net: mvgbe: remove CONFIG_DOVE

2018-05-03 Thread Chris Packham
Nothing defines CONFIG_DOVE so remove the code that uses it.

Signed-off-by: Chris Packham 
---

 drivers/net/mvgbe.c | 2 --
 drivers/net/mvgbe.h | 7 ---
 2 files changed, 9 deletions(-)

diff --git a/drivers/net/mvgbe.c b/drivers/net/mvgbe.c
index f833efbe6779..47148e526008 100644
--- a/drivers/net/mvgbe.c
+++ b/drivers/net/mvgbe.c
@@ -27,8 +27,6 @@
 #include 
 #elif defined(CONFIG_ORION5X)
 #include 
-#elif defined(CONFIG_DOVE)
-#include 
 #endif
 
 #include "mvgbe.h"
diff --git a/drivers/net/mvgbe.h b/drivers/net/mvgbe.h
index 27a3f41e80cd..7a42d70831ed 100644
--- a/drivers/net/mvgbe.h
+++ b/drivers/net/mvgbe.h
@@ -292,17 +292,10 @@
 #define EBAR_TARGET_GUNIT  0x0007
 
 /* Window attrib */
-#if defined(CONFIG_DOVE)
-#define EBAR_DRAM_CS0  0x
-#define EBAR_DRAM_CS1  0x
-#define EBAR_DRAM_CS2  0x
-#define EBAR_DRAM_CS3  0x
-#else
 #define EBAR_DRAM_CS0  0x0E00
 #define EBAR_DRAM_CS1  0x0D00
 #define EBAR_DRAM_CS2  0x0B00
 #define EBAR_DRAM_CS3  0x0700
-#endif
 
 /* DRAM Target interface */
 #define EBAR_DRAM_NO_CACHE_COHERENCY   0x
-- 
2.17.0

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


Re: [U-Boot] [PATCH v2 1/7] i.MX6: board: Add BTicino i.MX6DL Mamoj initial support

2018-05-03 Thread Stefano Babic
On 02/05/2018 14:41, Jagan Teki wrote:
> Hi Stefano,
> 
> On Thu, Apr 26, 2018 at 1:16 PM, Stefano Babic  wrote:
>> On 26/04/2018 09:33, Jagan Teki wrote:
>>>  On Thu, Apr 26, 2018 at 12:47 PM, Stefano Babic  wrote:
 Hi Jagan,

> 
> [snip]
> 
> +
> +static int mx6dl_dcd_table[] = {
> + 0x020e0774, 0x000C, /* MX6_IOM_GRP_DDR_TYPE */
> + 0x020e0754, 0x, /* MX6_IOM_GRP_DDRPKE */
> +
> + 0x020e04ac, 0x0028, /* MX6_IOM_DRAM_SDCLK_0 */
> + 0x020e04b0, 0x0028, /* MX6_IOM_DRAM_SDCLK_1 */
> +
> + 0x020e0464, 0x0028, /* MX6_IOM_DRAM_CAS */
> + 0x020e0490, 0x0028, /* MX6_IOM_DRAM_RAS */
> + 0x020e074c, 0x0028, /* MX6_IOM_GRP_ADDDS */
> +
> + 0x020e0494, 0x0028, /* MX6_IOM_DRAM_RESET */
> + 0x020e04a0, 0x, /* MX6_IOM_DRAM_SDBA2 */
> + 0x020e04b4, 0x0028, /* MX6_IOM_DRAM_SDODT0 */
> + 0x020e04b8, 0x0028, /* MX6_IOM_DRAM_SDODT1 */
> + 0x020e076c, 0x0028, /* MX6_IOM_GRP_CTLDS */
> +
> + 0x020e0750, 0x0002, /* MX6_IOM_GRP_DDRMODE_CTL */
> + 0x020e04bc, 0x0028, /* MX6_IOM_DRAM_SDQS0 */
> + 0x020e04c0, 0x0028, /* MX6_IOM_DRAM_SDQS1 */
> + 0x020e04c4, 0x0028, /* MX6_IOM_DRAM_SDQS2 */
> + 0x020e04c8, 0x0028, /* MX6_IOM_DRAM_SDQS3 */
> +
> + 0x020e0760, 0x0002, /* MX6_IOM_GRP_DDRMODE */
> + 0x020e0764, 0x0028, /* MX6_IOM_GRP_B0DS */
> + 0x020e0770, 0x0028, /* MX6_IOM_GRP_B1DS */
> + 0x020e0778, 0x0028, /* MX6_IOM_GRP_B2DS */
> + 0x020e077c, 0x0028, /* MX6_IOM_GRP_B3DS */
> +
> + 0x020e0470, 0x0028, /* MX6_IOM_DRAM_DQM0 */
> + 0x020e0474, 0x0028, /* MX6_IOM_DRAM_DQM1 */
> + 0x020e0478, 0x0028, /* MX6_IOM_DRAM_DQM2 */
> + 0x020e047c, 0x0028, /* MX6_IOM_DRAM_DQM3 */
> +
> + 0x021b001c, 0x8000, /* MMDC0_MDSCR */
> +
> + 0x021b0800, 0xA1390003, /* DDR_PHY_P0_MPZQHWCTRL */
> +
> + 0x021b080c, 0x0042004b, /* MMDC1_MPWLDECTRL0 */
> + 0x021b0810, 0x0038003c, /* MMDC1_MPWLDECTRL1 */
> +
> + 0x021b083c, 0x42340230, /* MPDGCTRL0 PHY0 */
> + 0x021b0840, 0x0228022c, /* MPDGCTRL1 PHY0 */
> +
> + 0x021b0848, 0x42444646, /* MPRDDLCTL PHY0 */
> +
> + 0x021b0850, 0x38382e2e, /* MPWRDLCTL PHY0 */
> +
> + 0x021b081c, 0x, /* DDR_PHY_P0_MPREDQBY0DL3 */
> + 0x021b0820, 0x, /* DDR_PHY_P0_MPREDQBY1DL3 */
> + 0x021b0824, 0x, /* DDR_PHY_P0_MPREDQBY2DL3 */
> + 0x021b0828, 0x, /* DDR_PHY_P0_MPREDQBY3DL3 */
> +
> + 0x021b08b8, 0x0800, /* DDR_PHY_P0_MPMUR0 */
> +
> + 0x021b0004, 0x0002002D, /* MMDC0_MDPDC */
> + 0x021b0008, 0x00333040, /* MMDC0_MDOTC */
> + 0x021b000c, 0x3F4352F3, /* MMDC0_MDCFG0 */
> + 0x021b0010, 0xB66D8B63, /* MMDC0_MDCFG1 */
> + 0x021b0014, 0x01FF00DB, /* MMDC0_MDCFG2 */
> +
> + 0x021b0018, 0x00011740, /* MMDC0_MDMISC */
> + 0x021b001c, 0x8000, /* MMDC0_MDSCR */
> + 0x021b002c, 0x26D2, /* MMDC0_MDRWD */
> + 0x021b0030, 0x00431023, /* MMDC0_MDOR */
> + 0x021b0040, 0x0017, /* Chan0 CS0_END */
> + 0x021b, 0x8319, /* MMDC0_MDCTL */
> +
> + 0x021b001c, 0x02008032, /* MMDC0_MDSCR  MR2 write, CS0 */
> + 0x021b001c, 0x8033, /* MMDC0_MDSCR, MR3 write, CS0 */
> + 0x021b001c, 0x00048031, /* MMDC0_MDSCR, MR1 write, CS0 */
> + 0x021b001c, 0x15208030, /* MMDC0_MDSCR, MR0write, CS0 */
> + 0x021b001c, 0x04008040, /* MMDC0_MDSCR */
> +
> + 0x021b0020, 0x7800, /* MMDC0_MDREF */
> +
> + 0x021b0818, 0x0007, /* DDR_PHY_P0_MPODTCTRL */
> +
> + 0x021b0004, 0x0002556D, /* MMDC0_MDPDC */
> + 0x021b0404, 0x00011006, /* MMDC0_MAPSR ADOPT */
> + 0x021b001c, 0x, /* MMDC0_MDSCR */
> +};
> +

 Sorry to have not raised this before. I saw this the first time, but I
 did not understand. I tried to find a reason for it, but still I had no
 answer.

 This is a DL, and DDR support is full integrated in U-Boot, including
 dynamic calibration if desired. What is the reason to dump the DCD table
 into code and push it with ddr_init, instead of setting structures for
 chip, gpr and calibration as most of boards are doing ? If you dump the
 table, you could this in the .cfg file where the DCD table belongs to,
 of course adding entries for DDR initialisation. I do not see after long
 thoughts any reason to go in this way.
>>>
>>> Like initializing ddr config and calibration using mx6sdl_dram_iocfg
>>> and mx6_dram_cfg? yes I usually does the same instead of hot codding
>>> hex values.
>>
>> Yes, this is what I mean.
> 
> ddr calibration 

[U-Boot] FitImage add pubkey signature in DTS

2018-05-03 Thread Clément Péron
Hi,

I'm looking to add the public key for the FitImage signature in my dts.

Do you know if there is a script to add the pubkey in the .dts and not in
the .dtb ?

Actually I "decompile" the .dtb to get those values, but maybe there is an
easier way.

Looking to generate something like this from the RSA keys :
 signature {
 key-product-dev {
 required = "conf";
 algo = "sha1,rsa2048";
 rsa,r-squared = <0x68b44337 0x916dcfda 0x.>
 rsa,modulus = <0xb7929d33 0x34df0e32 0x..>
 rsa,exponent = <0x0 0x10001>;
 rsa,n0-inverse = <0x29.>;
 rsa,num-bits = <0x800>;
 key-name-hint = "product-dev";
 };
 };

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


[U-Boot] [PATCH v2 2/2] net: bootp: Fix compile error processing ntpserver option

2018-05-03 Thread Chris Packham
When the following configuration is set

  # CONFIG_CMD_DHCP is not set
  CONFIG_CMD_BOOTP=y
  CONFIG_BOOTP_NTPSERVER=y

The following compile error is observed

  error: used struct type value where scalar is required
if (net_ntp_server)
^~

Resolve this by checking net_ntp_server.s_addr instead.

Signed-off-by: Chris Packham 
Acked-by: Joe Hershberger 
---
Changes in v2:
- collect Ack from Joe

 net/bootp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bootp.c b/net/bootp.c
index efa959971c27..9d7cb5d30c14 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -333,7 +333,7 @@ static void bootp_process_vendor(u8 *ext, int size)
debug("net_nis_domain : %s\n", net_nis_domain);
 
 #if defined(CONFIG_CMD_SNTP) && defined(CONFIG_BOOTP_NTPSERVER)
-   if (net_ntp_server)
+   if (net_ntp_server.s_addr)
debug("net_ntp_server : %pI4\n", _ntp_server);
 #endif
 }
-- 
2.17.0

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


[U-Boot] [PATCH v2 1/2] net: Add Kconfig option for BOOTP_NTPSERVER

2018-05-03 Thread Chris Packham
Add a Kconfig option for BOOTP_NTPSERVER to enable the DHCP/BOOTP option
to configure the sntp server address.

Signed-off-by: Chris Packham 
---
Changes in v2:
- update devkit8000 config
- remove from config_whitelist.txt

 cmd/Kconfig  | 4 
 configs/devkit8000_defconfig | 1 +
 include/configs/devkit8000.h | 1 -
 scripts/config_whitelist.txt | 1 -
 4 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index bc1d2f31c010..dfb0fddb7671 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1086,6 +1086,10 @@ config BOOTP_SUBNETMASK
default y
depends on CMD_BOOTP
 
+config BOOTP_NTPSERVER
+   bool "Request & store 'ntpserverip' from BOOTP/DHCP server"
+   depends on CMD_BOOTP
+
 config BOOTP_PXE
bool "Send PXE client arch to BOOTP/DHCP server"
default y
diff --git a/configs/devkit8000_defconfig b/configs/devkit8000_defconfig
index defed2d65a70..4a096b926597 100644
--- a/configs/devkit8000_defconfig
+++ b/configs/devkit8000_defconfig
@@ -18,6 +18,7 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_NAND=y
 CONFIG_CMD_NAND_LOCK_UNLOCK=y
 # CONFIG_CMD_SETEXPR is not set
+CONFIG_BOOTP_NTPSERVER=y
 CONFIG_CMD_JFFS2=y
 CONFIG_CMD_MTDPARTS=y
 CONFIG_MTDIDS_DEFAULT="nand0=nand"
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index dfbbb21a04c7..3b787be9000c 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -82,7 +82,6 @@
 #define CONFIG_BOOTP_BOOTFILESIZE
 #define CONFIG_BOOTP_DNS2
 #define CONFIG_BOOTP_SEND_HOSTNAME
-#define CONFIG_BOOTP_NTPSERVER
 #define CONFIG_BOOTP_TIMEOFFSET
 #undef CONFIG_BOOTP_VENDOREX
 
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index 9eba487ec4c5..0c0862d48db9 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -157,7 +157,6 @@ CONFIG_BOOTP_DHCP_REQUEST_DELAY
 CONFIG_BOOTP_ID_CACHE_SIZE
 CONFIG_BOOTP_MAY_FAIL
 CONFIG_BOOTP_NISDOMAIN
-CONFIG_BOOTP_NTPSERVER
 CONFIG_BOOTP_RANDOM_DELAY
 CONFIG_BOOTP_SEND_HOSTNAME
 CONFIG_BOOTP_SERVERIP
-- 
2.17.0

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


Re: [U-Boot] [PATCH 2/2] net: bootp: Fix compile error processing ntpserver option

2018-05-03 Thread Chris Packham
On Thu, May 3, 2018 at 12:23 PM Joe Hershberger 
wrote:

> On Fri, Apr 27, 2018 at 4:55 AM, Chris Packham 
wrote:
> > When the following configuration is set
> >
> >   # CONFIG_CMD_DHCP is not set
> >   CONFIG_CMD_BOOTP=y
> >   CONFIG_BOOTP_NTPSERVER=y
> >
> > The following compile error is observed
> >
> >   error: used struct type value where scalar is required
> > if (net_ntp_server)
> > ^~

> We should probably enable CMD_SNTP in devkit8000 so that this code
> path is compiled on travis. Can you add a patch for that to the
> series?

It's not quite that simple. CONFIG_CMD_DHCP is selected by
CONFIG_DISTRO_DEFAULTS. So just turning on CMD_SNTP doesn't catch this.
It'd be a fairly invasive change to disable CONFIG_DISTRO_DEFAULTS. For now
I'll send a v2 series with just the changes for 1/2.

> >
> > Resolve this by checking net_ntp_server.s_addr instead.
> >
> > Signed-off-by: Chris Packham 

> Acked-by: Joe Hershberger 

> > ---
> >
> >  net/bootp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/bootp.c b/net/bootp.c
> > index efa959971c27..9d7cb5d30c14 100644
> > --- a/net/bootp.c
> > +++ b/net/bootp.c
> > @@ -333,7 +333,7 @@ static void bootp_process_vendor(u8 *ext, int size)
> > debug("net_nis_domain : %s\n", net_nis_domain);
> >
> >  #if defined(CONFIG_CMD_SNTP) && defined(CONFIG_BOOTP_NTPSERVER)
> > -   if (net_ntp_server)
> > +   if (net_ntp_server.s_addr)
> > debug("net_ntp_server : %pI4\n", _ntp_server);
> >  #endif
> >  }
> > --
> > 2.17.0
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] efi_loader: correctly apply relocations from the .reloc section

2018-05-03 Thread Alexander Graf
> Instead of difference between preferred and actual image base, the
> actual base is added to the fields specified in the .reloc section.
> 
> Use ImageBase from PE optional header to compute the delta,
> exit early if the image is loaded at the preferred address.
> 
> Signed-off-by: Ivan Gorinov 
> Reviewed-by: Heinrich Schuchardt 

Thanks, applied to efi-next

Alex

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


Re: [U-Boot] [PATCH] efi_loader: correctly apply relocations from the .reloc section

2018-05-03 Thread Heinrich Schuchardt

On 05/03/2018 01:36 AM, Ivan Gorinov wrote:

Instead of difference between preferred and actual image base, the
actual base is added to the fields specified in the .reloc section.

Use ImageBase from PE optional header to compute the delta,
exit early if the image is loaded at the preferred address.

Signed-off-by: Ivan Gorinov 


The PE spec has this sentence:
"To apply a base relocation, the difference is calculated between the 
preferred base address and the base where the image is actually loaded."


The spec further defines ImageBase as "The preferred address of the 
first byte of image when loaded into memory."


EDK2 also calculates the relocations offset as:
BaseAddress - OptionalHeader.ImageBase
in MdePkg/Library/BasePeCoffLib/BasePeCoff.c and
in DuetPkg/EfiLdr/PeLoader.c

Reviewed-by: Heinrich Schuchardt 

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


[U-Boot] [PATCH] mmc: Changed the datatype of the variable to handle 64-bit arch

2018-05-03 Thread Michal Simek
From: Vipul Kumar 

This patch changed the datatype of variable "start" from uint to ulong
to work properly on 64-bit machines as well. Also the return type of
get_timer() function is ulong.

Signed-off-by: Vipul Kumar 
Signed-off-by: Michal Simek 
---

 drivers/mmc/mmc.c   | 4 ++--
 drivers/mmc/sdhci.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index fe7c0b39ac17..cbadba4f7b5a 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -680,7 +680,7 @@ static int mmc_complete_op_cond(struct mmc *mmc)
 {
struct mmc_cmd cmd;
int timeout = 1000;
-   uint start;
+   ulong start;
int err;
 
mmc->op_cond_pending = 0;
@@ -2608,7 +2608,7 @@ static int mmc_complete_init(struct mmc *mmc)
 int mmc_init(struct mmc *mmc)
 {
int err = 0;
-   __maybe_unused unsigned start;
+   __maybe_unused ulong start;
 #if CONFIG_IS_ENABLED(DM_MMC)
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(mmc->dev);
 
diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 1e5e8a615917..19ac32b66296 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -152,7 +152,7 @@ static int sdhci_send_command(struct mmc *mmc, struct 
mmc_cmd *cmd,
u32 mask, flags, mode;
unsigned int time = 0, start_addr = 0;
int mmc_dev = mmc_get_blk_desc(mmc)->devnum;
-   unsigned start = get_timer(0);
+   ulong start = get_timer(0);
 
/* Timeout unit - ms */
static unsigned int cmd_timeout = SDHCI_CMD_DEFAULT_TIMEOUT;
-- 
2.17.0

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


Re: [U-Boot] [PATCH v2 1/1] arm: Add support for Trenz TE0820 on Sundance EMC2-DP-V2

2018-05-03 Thread Michal Simek
On 2.5.2018 17:51, Vladimir Svoboda wrote:
> Add support for Trenz TE0820 revision 2 MPSoC module.
> The TE0820 is a System-On-Module (SOM).
> This has been tested with a Sundance EMC2-DP-V2 Revision 1 carrier
> board.
> 
> The tested variant of the TE0820 is TE0820-02-03EG-1EA.
> 
> Signed-off-by: Vladimir Svoboda 
> ---
> 
> Changes in v2:
> - Renamed a lot from Xilinx ZynqMP to Trenz
> - The device tree for the TE0820 is now a DTSI file included by a
>   carrier board+SOM DTS file
> 
>  arch/arm/dts/Makefile |   1 +
>  .../sundance-emc2-dp-v2-rev1-te0820-rev2.dts  |  19 +
>  arch/arm/dts/trenz-te0820-rev2.dtsi   | 213 ++
>  .../zynqmp/trenz-te0820-rev2/psu_init_gpl.c   | 623 ++
>  ...ance_emc2-dp-v2_rev1_te0820_rev2_defconfig | 105 +++
>  include/configs/trenz_te0820.h|  49 ++
>  6 files changed, 1010 insertions(+)
>  create mode 100644 arch/arm/dts/sundance-emc2-dp-v2-rev1-te0820-rev2.dts
>  create mode 100644 arch/arm/dts/trenz-te0820-rev2.dtsi
>  create mode 100644 board/xilinx/zynqmp/trenz-te0820-rev2/psu_init_gpl.c
>  create mode 100644 configs/sundance_emc2-dp-v2_rev1_te0820_rev2_defconfig
>  create mode 100644 include/configs/trenz_te0820.h
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index ac7667b1e8..eb1e070556 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -146,6 +146,7 @@ dtb-$(CONFIG_ARCH_ZYNQ) += \
>   zynq-zturn.dtb \
>   zynq-zybo.dtb
>  dtb-$(CONFIG_ARCH_ZYNQMP) += \
> + sundance-emc2-dp-v2-rev1-te0820-rev2.dtb\
>   zynqmp-mini-emmc.dtb\
>   zynqmp-mini-nand.dtb\
>   zynqmp-zcu100-revC.dtb  \
> diff --git a/arch/arm/dts/sundance-emc2-dp-v2-rev1-te0820-rev2.dts 
> b/arch/arm/dts/sundance-emc2-dp-v2-rev1-te0820-rev2.dts
> new file mode 100644
> index 00..bea8050ab6
> --- /dev/null
> +++ b/arch/arm/dts/sundance-emc2-dp-v2-rev1-te0820-rev2.dts
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dts file for Sundance EMC2-DP-V2 Rev1 carrier board with Trenz TE0820 Rev2

NIT: remove file and you will fit to 80 chars.

> + * SOM
> + *
> + * (C) Copyright 2018, HIPPEROS.
> + *
> + * Vladimir Svoboda 
> + */
> +
> +/dts-v1/;
> +
> +#include "trenz-te0820-rev2.dtsi"
> +
> +/ {
> + model = "Sundance EMC2-DP-V2 Rev1 Trenz TE0820 Rev2";
> + compatible = "trenz,zynqmp-te0820-rev2", "trenz,zynqmp-te0820",
> + "trenz,zynqmp";

This is definitely not enough. This is carrier board which should
contain all components which are only on this board. It means a lot of
things from SOM below should be moved here.

Also compatible string should contains sundance and record it in
vendor-prefix in the linux kernel.
These prefixes needs to be at least in linux-next to be able to apply
these patches.
I would even like to hear Rob's opinion on these SoM division.

> +};
> diff --git a/arch/arm/dts/trenz-te0820-rev2.dtsi 
> b/arch/arm/dts/trenz-te0820-rev2.dtsi
> new file mode 100644
> index 00..8eb603550d
> --- /dev/null
> +++ b/arch/arm/dts/trenz-te0820-rev2.dtsi
> @@ -0,0 +1,213 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * dts file for Trenz TE0820 Rev2
> + *
> + * (C) Copyright 2018, HIPPEROS.
> + *
> + * Vladimir Svoboda 
> + */
> +
> +/dts-v1/;
> +
> +/include/ "zynqmp.dtsi"
> +/include/ "zynqmp-clk-ccf.dtsi"
> +
> +/ {
> + model = "Trenz TE0820 Rev2";
> + compatible = "trenz,zynqmp-te0820-rev2", "trenz,zynqmp-te0820",
> + "trenz,zynqmp";

you can keep xlnx,zynqmp here too.

> +
> + aliases {
> + ethernet0 = 
> + i2c0 = 
> + i2c1 = 
> + rtc0 = 
> + serial0 = 
> + serial1 = 

Don't know this module but if there is no hardwired MIOs for these IPs
then they should be in sundance dts not here.

> + serial2 = 

If jtag is on trenz board you can keep this here.

> + };
> +
> + chosen {
> + bootargs = "earlycon";
> + stdout-path = "serial0:115200n8";
> + };

sundance.

> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x4000>;
> + };

This memory is on this module that's why it needs to be here.


> +};
> +
> + {
> + status = "okay";
> +};

I would put this to sundance if there is physical hw for can.

> +
> + {
> + status = "okay";
> +};
> +
> +_dma_chan1 {
> + status = "okay";
> +};
> +
> +_dma_chan2 {
> + status = "okay";
> +};
> +
> +_dma_chan3 {
> + status = "okay";
> +};
> +
> +_dma_chan4 {
> + status = "okay";
> +};
> +
> +_dma_chan5 {
> + status = "okay";
> +};
> +
> +_dma_chan6 {
> + status = "okay";
> +};
> +
> +_dma_chan7 {
> + status = "okay";
> +};
> +
> +_dma_chan8 {
> + status = "okay";
> +};

you can keep these here.

> +
> +