[U-Boot] [PATCH v2] kconfig: add CONFIG_CC_COVERAGE

2018-04-09 Thread Christian Gmeiner
Make it possible to use gcc code coverage analysis.

v1 -> v2:
 - Kconfig: remove not needed 'default n'
 - Makefile: use consistent spacing

Signed-off-by: Christian Gmeiner 
---
 .gitignore | 4 
 Kconfig| 7 +++
 Makefile   | 6 ++
 3 files changed, 17 insertions(+)

diff --git a/.gitignore b/.gitignore
index 29757aa51e..f1b801579c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -85,3 +85,7 @@ GTAGS
 *.orig
 *~
 \#*#
+
+# gcc code coverage files
+*.gcda
+*.gcno
diff --git a/Kconfig b/Kconfig
index 6670913799..67b8c50cbd 100644
--- a/Kconfig
+++ b/Kconfig
@@ -59,6 +59,13 @@ config CC_OPTIMIZE_FOR_SIZE
 
  This option is enabled by default for U-Boot.
 
+config CC_COVERAGE
+   bool "Enable code coverage analysis"
+   depends on SANDBOX
+   help
+ Enabling this option will pass "--coverage" to gcc to compile
+ and link code instrumented for coverage analysis.
+
 config DISTRO_DEFAULTS
bool "Select defaults suitable for booting general purpose Linux 
distributions"
default y if ARCH_SUNXI || TEGRA
diff --git a/Makefile b/Makefile
index 5fa14789d9..5ca695650d 100644
--- a/Makefile
+++ b/Makefile
@@ -720,6 +720,12 @@ else
 PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) 
-print-libgcc-file-name`) -lgcc
 endif
 PLATFORM_LIBS += $(PLATFORM_LIBGCC)
+
+ifdef CONFIG_CC_COVERAGE
+KBUILD_CFLAGS += --coverage
+PLATFORM_LIBGCC += -lgcov
+endif
+
 export PLATFORM_LIBS
 export PLATFORM_LIBGCC
 
-- 
2.14.3

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


[U-Boot] [PATCH 08/15] mmc: matsushita-common: Handle Renesas div-by-1

2018-04-09 Thread Marek Vasut
On the Renesas version of the IP, the /1 divider is realized by
setting the clock register [7:0] to 0xff instead of setting bit
10 of the register. Check the quirk and handle accordingly.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 3 ++-
 drivers/mmc/matsushita-common.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index 449f533d1b..7e05b1f3d1 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -542,7 +542,8 @@ static void matsu_sd_set_clk_rate(struct matsu_sd_priv 
*priv,
divisor = DIV_ROUND_UP(priv->mclk, mmc->clock);
 
if (divisor <= 1)
-   val = MATSU_SD_CLKCTL_DIV1;
+   val = (priv->caps & MATSU_SD_CAP_RCAR) ?
+ MATSU_SD_CLKCTL_RCAR_DIV1 : MATSU_SD_CLKCTL_DIV1;
else if (divisor <= 2)
val = MATSU_SD_CLKCTL_DIV2;
else if (divisor <= 4)
diff --git a/drivers/mmc/matsushita-common.h b/drivers/mmc/matsushita-common.h
index c23dc1a79a..a10ad202c8 100644
--- a/drivers/mmc/matsushita-common.h
+++ b/drivers/mmc/matsushita-common.h
@@ -63,6 +63,7 @@
 #define   MATSU_SD_CLKCTL_DIV4 BIT(0)  /* SDCLK = CLK / 4 */
 #define   MATSU_SD_CLKCTL_DIV2 0   /* SDCLK = CLK / 2 */
 #define   MATSU_SD_CLKCTL_DIV1 BIT(10) /* SDCLK = CLK */
+#define   MATSU_SD_CLKCTL_RCAR_DIV10xff/* SDCLK = CLK (RCar ver.) */
 #define   MATSU_SD_CLKCTL_OFFENBIT(9)  /* stop SDCLK when 
unused */
 #define   MATSU_SD_CLKCTL_SCLKEN   BIT(8)  /* SDCLK output enable */
 #define MATSU_SD_SIZE  0x04c   /* block size */
-- 
2.16.2

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


[U-Boot] [PATCH 10/15] mmc: matsushita-common: Handle bus width 0

2018-04-09 Thread Marek Vasut
Handle bus width 0 as 1-bit bus to assure valid content of
MATSU_SD_OPTION register WIDTH field.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index 11e4553d87..377f349b41 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -504,6 +504,7 @@ static int matsu_sd_set_bus_width(struct matsu_sd_priv 
*priv,
u32 val, tmp;
 
switch (mmc->bus_width) {
+   case 0:
case 1:
val = MATSU_SD_OPTION_WIDTH_1;
break;
-- 
2.16.2

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


Re: [U-Boot] FIT Image with same kernel but different load/entry point

2018-04-09 Thread Clément Péron
> I think what you want is to use kernel_noload and then load/entry values
> are ignored and we use the kernel in-place.
Yes, I will try that
Thanks,
Clement
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Jean-Jacques Hiblot



On 09/04/2018 16:46, Guillaume Gardet wrote:



Le 09/04/2018 à 16:21, Jean-Jacques Hiblot a écrit :



On 09/04/2018 16:03, Guillaume Gardet wrote:



Le 09/04/2018 à 15:58, Jean-Jacques Hiblot a écrit :



On 09/04/2018 14:02, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook 
(snow) with latest master (and also 2018.05-rc1 and 2018.03).


eMMC is ok, but SD card access leads to 'unable to select a mode' 
problem. If I disable HS mode, I can access the SD card without 
problem:
 


diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, 
struct dwmci_host *host,

     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
 }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable 
to select a mode' error */

+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

 cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }
 



Once we try to select HS mode, all access to SD card result in 
failure, even when trying to setup a lower frequency mode, 
including SD legacy at 25 MHz.


Any idea what is going? Maybe you have fixes pending?


Can try with MMC_MODE_HS | MMC_MODE_HS_52MHz but with a lower 
max-frequency (<25MHz) ? It would be interesting to know if it 
could come from a frequency limitation.


I already tried to change SD_HS freq (in mmc_mode2freq) from 
5000 to 2500 with no difference.



Is there some pad configuration to do when using higher frequency?


I do not think so.

Can you enable the debug output and post a log ?


Here is the log from u-boot built from u-boot-mmc (latest commit: 
21c2ac32b845)
Yes, I have no serial, so I retyped the messages, so I hope there is 
no typo:

**
selecting mode MMC legacy (freq : 0 MHz)
selecting mode MMC legacy (freq : 25 MHz)
sd card: widths [4, 1] modes [SD Legacy, SD High SPeed (50MHz)]
host: widths [4, 1] modes [MMC legacy, SD Legacy, MMC High Speed 
(26MHz), SD High Speed (50MHz), MMC High Speed (52MHz), MMC DDR52 
(52MHz)]

trying mode SD High Speed (50MHz) width 4 (at 50 MHz)
selecting mode SD High Speed (50 MHz) (freq : 50 MHz)
unable to read ssr
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD High Speed (50MHz) width 1 (at 50 MHz)

So it fails either in sd_select_bus_width() or sd_set_card_speed()
Can you try to limit the bus width to 1 ? Does it fail also at 50 MHz ?


selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 4 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 1 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
unable to select a mode
mmc_init: -524, time 127
** Bad device mmc 1 **
**

Note that eMMC (on mmc 0) is working fine with MMC DDR52 (52MHz).

Guillaume



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


[U-Boot] [PATCH 03/15] mmc: uniphier: Add support for 16bit variant

2018-04-09 Thread Marek Vasut
Add support for 16bit mutation of the Matsushita SD IP. Since some
registers are internally 32bit, the matsu_sd_{read,write}l() has
to special-case this 16bit variant a bit.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 42 +
 drivers/mmc/matsushita-common.h |  1 +
 2 files changed, 39 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index ec5469850b..9f7f47c86b 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -32,11 +32,31 @@ static void matsu_sd_writeq(struct matsu_sd_priv *priv,
writeq(val, priv->regbase + (reg << 1));
 }
 
+static u16 matsu_sd_readw(struct matsu_sd_priv *priv, unsigned int reg)
+{
+   return readw(priv->regbase + (reg >> 1));
+}
+
+static void matsu_sd_writew(struct matsu_sd_priv *priv,
+  u16 val, unsigned int reg)
+{
+   writew(val, priv->regbase + (reg >> 1));
+}
+
 static u32 matsu_sd_readl(struct matsu_sd_priv *priv, unsigned int reg)
 {
+   u32 val;
+
if (priv->caps & MATSU_SD_CAP_64BIT)
return readl(priv->regbase + (reg << 1));
-   else
+   else if (priv->caps & MATSU_SD_CAP_16BIT) {
+   val = readw(priv->regbase + (reg >> 1)) & 0x;
+   if ((reg == MATSU_SD_RSP10) || (reg == MATSU_SD_RSP32) ||
+   (reg == MATSU_SD_RSP54) || (reg == MATSU_SD_RSP76)) {
+   val |= readw(priv->regbase + (reg >> 1) + 2) << 16;
+   }
+   return val;
+   } else
return readl(priv->regbase + reg);
 }
 
@@ -45,7 +65,11 @@ static void matsu_sd_writel(struct matsu_sd_priv *priv,
 {
if (priv->caps & MATSU_SD_CAP_64BIT)
writel(val, priv->regbase + (reg << 1));
-   else
+   if (priv->caps & MATSU_SD_CAP_16BIT) {
+   writew(val & 0x, priv->regbase + (reg >> 1));
+   if (val >> 16)
+   writew(val >> 16, priv->regbase + (reg >> 1) + 2);
+   } else
writel(val, priv->regbase + reg);
 }
 
@@ -150,6 +174,7 @@ static void matsu_pio_read_fifo_##__width(struct 
matsu_sd_priv *priv,   \
 
 matsu_pio_read_fifo(64, q)
 matsu_pio_read_fifo(32, l)
+matsu_pio_read_fifo(16, w)
 
 static int matsu_sd_pio_read_one_block(struct udevice *dev, char *pbuf,
  uint blocksize)
@@ -171,6 +196,8 @@ static int matsu_sd_pio_read_one_block(struct udevice *dev, 
char *pbuf,
 
if (priv->caps & MATSU_SD_CAP_64BIT)
matsu_pio_read_fifo_64(priv, pbuf, blocksize);
+   else if (priv->caps & MATSU_SD_CAP_16BIT)
+   matsu_pio_read_fifo_16(priv, pbuf, blocksize);
else
matsu_pio_read_fifo_32(priv, pbuf, blocksize);
 
@@ -200,6 +227,7 @@ static void matsu_pio_write_fifo_##__width(struct 
matsu_sd_priv *priv,  \
 
 matsu_pio_write_fifo(64, q)
 matsu_pio_write_fifo(32, l)
+matsu_pio_write_fifo(16, w)
 
 static int matsu_sd_pio_write_one_block(struct udevice *dev,
   const char *pbuf, uint blocksize)
@@ -217,6 +245,8 @@ static int matsu_sd_pio_write_one_block(struct udevice *dev,
 
if (priv->caps & MATSU_SD_CAP_64BIT)
matsu_pio_write_fifo_64(priv, pbuf, blocksize);
+   else if (priv->caps & MATSU_SD_CAP_16BIT)
+   matsu_pio_write_fifo_16(priv, pbuf, blocksize);
else
matsu_pio_write_fifo_32(priv, pbuf, blocksize);
 
@@ -602,8 +632,12 @@ static void matsu_sd_host_init(struct matsu_sd_priv *priv)
 * This register dropped backward compatibility at version 0x10.
 * Write an appropriate value depending on the IP version.
 */
-   matsu_sd_writel(priv, priv->version >= 0x10 ? 0x0101 : 0x,
-  MATSU_SD_HOST_MODE);
+   if (priv->version >= 0x10)
+   matsu_sd_writel(priv, 0x101, MATSU_SD_HOST_MODE);
+   else if (priv->caps & MATSU_SD_CAP_16BIT)
+   matsu_sd_writel(priv, 0x1, MATSU_SD_HOST_MODE);
+   else
+   matsu_sd_writel(priv, 0x0, MATSU_SD_HOST_MODE);
 
if (priv->caps & MATSU_SD_CAP_DMA_INTERNAL) {
tmp = matsu_sd_readl(priv, MATSU_SD_DMA_MODE);
diff --git a/drivers/mmc/matsushita-common.h b/drivers/mmc/matsushita-common.h
index e517a2d56b..c1b28a0128 100644
--- a/drivers/mmc/matsushita-common.h
+++ b/drivers/mmc/matsushita-common.h
@@ -123,6 +123,7 @@ struct matsu_sd_priv {
 #define MATSU_SD_CAP_DMA_INTERNAL  BIT(1)  /* have internal DMA engine */
 #define MATSU_SD_CAP_DIV1024   BIT(2)  /* divisor 1024 is available */
 #define MATSU_SD_CAP_64BIT BIT(3)  /* Controller is 64bit */
+#define MATSU_SD_CAP_16BIT BIT(4)  /* 

[U-Boot] [PATCH 06/15] mmc: matsushita-common: Use mmc_of_parse()

2018-04-09 Thread Marek Vasut
Drop the ad-hoc DT caps parsing in favor of common framework function.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index 0b0cbaf9e1..449f533d1b 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -703,24 +703,15 @@ int matsu_sd_probe(struct udevice *dev, u32 quirks)
return ret;
}
 
-   plat->cfg.name = dev->name;
-   plat->cfg.host_caps = MMC_MODE_HS_52MHz | MMC_MODE_HS;
-
-   switch (fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev), "bus-width",
-  1)) {
-   case 8:
-   plat->cfg.host_caps |= MMC_MODE_8BIT;
-   break;
-   case 4:
-   plat->cfg.host_caps |= MMC_MODE_4BIT;
-   break;
-   case 1:
-   break;
-   default:
-   dev_err(dev, "Invalid \"bus-width\" value\n");
-   return -EINVAL;
+   ret = mmc_of_parse(dev, >cfg);
+   if (ret < 0) {
+   dev_err(dev, "failed to parse host caps\n");
+   return ret;
}
 
+   plat->cfg.name = dev->name;
+   plat->cfg.host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
+
if (quirks) {
priv->caps = quirks;
} else {
-- 
2.16.2

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


[U-Boot] [PATCH 04/15] mmc: uniphier: Allow passing quirks to the probe function

2018-04-09 Thread Marek Vasut
Certain instances of the SD IP require more elaborate digging
in the DT to figure out which variant of the SD IP is in use.
Allow explicit passing of the quirks into the probe function.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 3 +--
 drivers/mmc/matsushita-common.h | 2 +-
 drivers/mmc/renesas-sdhi.c  | 9 -
 drivers/mmc/uniphier-sd.c   | 7 ++-
 4 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index 9f7f47c86b..0b0cbaf9e1 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -653,12 +653,11 @@ int matsu_sd_bind(struct udevice *dev)
return mmc_bind(dev, >mmc, >cfg);
 }
 
-int matsu_sd_probe(struct udevice *dev)
+int matsu_sd_probe(struct udevice *dev, u32 quirks)
 {
struct matsu_sd_plat *plat = dev_get_platdata(dev);
struct matsu_sd_priv *priv = dev_get_priv(dev);
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
-   const u32 quirks = dev_get_driver_data(dev);
fdt_addr_t base;
struct clk clk;
int ret;
diff --git a/drivers/mmc/matsushita-common.h b/drivers/mmc/matsushita-common.h
index c1b28a0128..a03d8f97e5 100644
--- a/drivers/mmc/matsushita-common.h
+++ b/drivers/mmc/matsushita-common.h
@@ -132,6 +132,6 @@ int matsu_sd_set_ios(struct udevice *dev);
 int matsu_sd_get_cd(struct udevice *dev);
 
 int matsu_sd_bind(struct udevice *dev);
-int matsu_sd_probe(struct udevice *dev);
+int matsu_sd_probe(struct udevice *dev, u32 quirks);
 
 #endif /* __MATSUSHITA_COMMON_H__ */
diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index 9b388b3ab0..d6b3bfbadc 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -38,12 +38,19 @@ static const struct udevice_id renesas_sdhi_match[] = {
{ /* sentinel */ }
 };
 
+static int renesas_sdhi_probe(struct udevice *dev)
+{
+   u32 quirks = dev_get_driver_data(dev);
+
+   return matsu_sd_probe(dev, quirks);
+}
+
 U_BOOT_DRIVER(renesas_sdhi) = {
.name = "renesas-sdhi",
.id = UCLASS_MMC,
.of_match = renesas_sdhi_match,
.bind = matsu_sd_bind,
-   .probe = matsu_sd_probe,
+   .probe = renesas_sdhi_probe,
.priv_auto_alloc_size = sizeof(struct matsu_sd_priv),
.platdata_auto_alloc_size = sizeof(struct matsu_sd_plat),
.ops = _sdhi_ops,
diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
index 72f0d46758..42eb9c2c84 100644
--- a/drivers/mmc/uniphier-sd.c
+++ b/drivers/mmc/uniphier-sd.c
@@ -30,12 +30,17 @@ static const struct udevice_id uniphier_sd_match[] = {
{ /* sentinel */ }
 };
 
+static int uniphier_sd_probe(struct udevice *dev)
+{
+   return matsu_sd_probe(dev, 0);
+}
+
 U_BOOT_DRIVER(uniphier_mmc) = {
.name = "uniphier-mmc",
.id = UCLASS_MMC,
.of_match = uniphier_sd_match,
.bind = matsu_sd_bind,
-   .probe = matsu_sd_probe,
+   .probe = uniphier_sd_probe,
.priv_auto_alloc_size = sizeof(struct matsu_sd_priv),
.platdata_auto_alloc_size = sizeof(struct matsu_sd_plat),
.ops = _sd_ops,
-- 
2.16.2

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


[U-Boot] [PATCH 07/15] mmc: matsushita-common: Add Renesas RCar quirks

2018-04-09 Thread Marek Vasut
Add a quirk to identify that the controller is Renesas RCar variant
of the Matsushita SD IP and another quirk indicating it can support
Renesas RCar HS200/HS400/SDR104 modes.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.h |  5 +
 drivers/mmc/renesas-sdhi.c  | 43 -
 2 files changed, 30 insertions(+), 18 deletions(-)

diff --git a/drivers/mmc/matsushita-common.h b/drivers/mmc/matsushita-common.h
index a03d8f97e5..c23dc1a79a 100644
--- a/drivers/mmc/matsushita-common.h
+++ b/drivers/mmc/matsushita-common.h
@@ -124,6 +124,11 @@ struct matsu_sd_priv {
 #define MATSU_SD_CAP_DIV1024   BIT(2)  /* divisor 1024 is available */
 #define MATSU_SD_CAP_64BIT BIT(3)  /* Controller is 64bit */
 #define MATSU_SD_CAP_16BIT BIT(4)  /* Controller is 16bit */
+#define MATSU_SD_CAP_RCAR_GEN2 BIT(5)  /* Renesas RCar version of IP */
+#define MATSU_SD_CAP_RCAR_GEN3 BIT(6)  /* Renesas RCar version of IP */
+#define MATSU_SD_CAP_RCAR_UHS  BIT(7)  /* Renesas RCar UHS/SDR modes */
+#define MATSU_SD_CAP_RCAR  \
+   (MATSU_SD_CAP_RCAR_GEN2 | MATSU_SD_CAP_RCAR_GEN3)
 };
 
 int matsu_sd_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index 521574387b..73f68c8c3a 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -24,17 +24,21 @@ static const struct dm_mmc_ops renesas_sdhi_ops = {
.get_cd = matsu_sd_get_cd,
 };
 
+#define RENESAS_GEN2_QUIRKSMATSU_SD_CAP_RCAR_GEN2
+#define RENESAS_GEN3_QUIRKS\
+   MATSU_SD_CAP_64BIT | MATSU_SD_CAP_RCAR_GEN3 | MATSU_SD_CAP_RCAR_UHS
+
 static const struct udevice_id renesas_sdhi_match[] = {
-   { .compatible = "renesas,sdhi-r8a7790", .data = 0 },
-   { .compatible = "renesas,sdhi-r8a7791", .data = 0 },
-   { .compatible = "renesas,sdhi-r8a7792", .data = 0 },
-   { .compatible = "renesas,sdhi-r8a7793", .data = 0 },
-   { .compatible = "renesas,sdhi-r8a7794", .data = 0 },
-   { .compatible = "renesas,sdhi-r8a7795", .data = MATSU_SD_CAP_64BIT },
-   { .compatible = "renesas,sdhi-r8a7796", .data = MATSU_SD_CAP_64BIT },
-   { .compatible = "renesas,sdhi-r8a77965", .data = MATSU_SD_CAP_64BIT },
-   { .compatible = "renesas,sdhi-r8a77970", .data = MATSU_SD_CAP_64BIT },
-   { .compatible = "renesas,sdhi-r8a77995", .data = MATSU_SD_CAP_64BIT },
+   { .compatible = "renesas,sdhi-r8a7790", .data = RENESAS_GEN2_QUIRKS },
+   { .compatible = "renesas,sdhi-r8a7791", .data = RENESAS_GEN2_QUIRKS },
+   { .compatible = "renesas,sdhi-r8a7792", .data = RENESAS_GEN2_QUIRKS },
+   { .compatible = "renesas,sdhi-r8a7793", .data = RENESAS_GEN2_QUIRKS },
+   { .compatible = "renesas,sdhi-r8a7794", .data = RENESAS_GEN2_QUIRKS },
+   { .compatible = "renesas,sdhi-r8a7795", .data = RENESAS_GEN3_QUIRKS },
+   { .compatible = "renesas,sdhi-r8a7796", .data = RENESAS_GEN3_QUIRKS },
+   { .compatible = "renesas,sdhi-r8a77965", .data = RENESAS_GEN3_QUIRKS },
+   { .compatible = "renesas,sdhi-r8a77970", .data = RENESAS_GEN3_QUIRKS },
+   { .compatible = "renesas,sdhi-r8a77995", .data = RENESAS_GEN3_QUIRKS },
{ /* sentinel */ }
 };
 
@@ -45,15 +49,18 @@ static int renesas_sdhi_probe(struct udevice *dev)
DECLARE_GLOBAL_DATA_PTR;
int ret;
 
-   ret = fdt_get_resource(gd->fdt_blob, dev_of_offset(dev), "reg",
-  0, _res);
-   if (ret < 0) {
-   dev_err(dev, "\"reg\" resource not found, ret=%i\n", ret);
-   return ret;
-   }
+   if (quirks == RENESAS_GEN2_QUIRKS) {
+   ret = fdt_get_resource(gd->fdt_blob, dev_of_offset(dev),
+  "reg", 0, _res);
+   if (ret < 0) {
+   dev_err(dev, "\"reg\" resource not found, ret=%i\n",
+   ret);
+   return ret;
+   }
 
-   if (quirks == 0 && fdt_resource_size(_res) == 0x100)
-   quirks = MATSU_SD_CAP_16BIT;
+   if (fdt_resource_size(_res) == 0x100)
+   quirks |= MATSU_SD_CAP_16BIT;
+   }
 
return matsu_sd_probe(dev, quirks);
 }
-- 
2.16.2

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


[U-Boot] [PATCH 02/15] mmc: uniphier: Drop useless check

2018-04-09 Thread Marek Vasut
Drop useless check in matsu_sd_{read,write}q(), this is only ever
called to read the data from FIFO and only when 64bit variant of
the block is used anyway.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index 4553b168f5..ec5469850b 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -23,19 +23,13 @@ DECLARE_GLOBAL_DATA_PTR;
 
 static u64 matsu_sd_readq(struct matsu_sd_priv *priv, unsigned int reg)
 {
-   if (priv->caps & MATSU_SD_CAP_64BIT)
-   return readq(priv->regbase + (reg << 1));
-   else
-   return readq(priv->regbase + reg);
+   return readq(priv->regbase + (reg << 1));
 }
 
 static void matsu_sd_writeq(struct matsu_sd_priv *priv,
   u64 val, unsigned int reg)
 {
-   if (priv->caps & MATSU_SD_CAP_64BIT)
-   writeq(val, priv->regbase + (reg << 1));
-   else
-   writeq(val, priv->regbase + reg);
+   writeq(val, priv->regbase + (reg << 1));
 }
 
 static u32 matsu_sd_readl(struct matsu_sd_priv *priv, unsigned int reg)
-- 
2.16.2

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


Re: [U-Boot] [PATCH] imx: nitrogen6x: Convert Sabrelite to distro boot support

2018-04-09 Thread Fabio Estevam
Hi Gary,

On Mon, Apr 9, 2018 at 11:40 AM, Gary Bisson
 wrote:

>>  #define CONFIG_EXTRA_ENV_SETTINGS \
>> - "script=boot.scr\0" \
>> - "uimage=uImage\0" \
>>   "console=ttymxc1\0" \
>>   "fdt_high=0x\0" \
>>   "initrd_high=0x\0" \
>> - "fdt_file=imx6q-sabrelite.dtb\0" \
>> + "fdtfile=imx6q-sabrelite.dtb\0" \
>
> I wish the default efi_fdtfile would work, Fabio is there any plan to
> populate the ${soc} variable like it is done for i.MX7? [2]

It seems we didn't need to do this yet, but if you see a need for it,
please post a patch.

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


Re: [U-Boot] [U-Boot, v2, 3/5] usb: gadget: USB_ETHER requires network support

2018-04-09 Thread Tom Rini
On Sun, Apr 01, 2018 at 09:22:36AM +, Alex Kiernan wrote:

> In order to compile the USB Ethernet gadget support we require that NET
> is enabled, add that dependency here.
> 
> Signed-off-by: Alex Kiernan 
> Acked-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


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


[U-Boot] [PATCH 09/15] mmc: matsushita-common: Handle DMA completion flag differences

2018-04-09 Thread Marek Vasut
The DMA READ completion flag position differs on Socionext and Renesas
SoCs. It is bit 20 on Socionext SoCs and using bit 17 is a hardware bug
and forbidden. It is bit 17 on Renesas SoCs and bit 20 does not work on
them.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 10 +-
 drivers/mmc/matsushita-common.h |  4 ++--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index 7e05b1f3d1..11e4553d87 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -339,7 +339,15 @@ static int matsu_sd_dma_xfer(struct udevice *dev, struct 
mmc_data *data)
if (data->flags & MMC_DATA_READ) {
buf = data->dest;
dir = DMA_FROM_DEVICE;
-   poll_flag = MATSU_SD_DMA_INFO1_END_RD2;
+   /*
+* The DMA READ completion flag position differs on Socionext
+* and Renesas SoCs. It is bit 20 on Socionext SoCs and using
+* bit 17 is a hardware bug and forbidden. It is bit 17 on
+* Renesas SoCs and bit 20 does not work on them.
+*/
+   poll_flag = (priv->caps & MATSU_SD_CAP_RCAR) ?
+   MATSU_SD_DMA_INFO1_END_RD :
+   MATSU_SD_DMA_INFO1_END_RD2;
tmp |= MATSU_SD_DMA_MODE_DIR_RD;
} else {
buf = (void *)data->src;
diff --git a/drivers/mmc/matsushita-common.h b/drivers/mmc/matsushita-common.h
index a10ad202c8..8c81bbcc4b 100644
--- a/drivers/mmc/matsushita-common.h
+++ b/drivers/mmc/matsushita-common.h
@@ -96,8 +96,8 @@
 #define   MATSU_SD_DMA_RST_RD  BIT(9)
 #define   MATSU_SD_DMA_RST_WR  BIT(8)
 #define MATSU_SD_DMA_INFO1 0x420
-#define   MATSU_SD_DMA_INFO1_END_RD2   BIT(20) /* DMA from device is complete*/
-#define   MATSU_SD_DMA_INFO1_END_RDBIT(17) /* Don't use!  Hardware bug */
+#define   MATSU_SD_DMA_INFO1_END_RD2   BIT(20) /* DMA from device is complete 
(uniphier) */
+#define   MATSU_SD_DMA_INFO1_END_RDBIT(17) /* DMA from device is complete 
(renesas) */
 #define   MATSU_SD_DMA_INFO1_END_WRBIT(16) /* DMA to device is complete */
 #define MATSU_SD_DMA_INFO1_MASK0x424
 #define MATSU_SD_DMA_INFO2 0x428
-- 
2.16.2

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


[U-Boot] [PATCH 01/15] mmc: uniphier: Factor out FIFO accessors

2018-04-09 Thread Marek Vasut
Add macros to generate the FIFO accessors, since the code is almost
the same with only minor differences. This is done in preparation
for adding 16bit variant of the IP.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 122 
 1 file changed, 60 insertions(+), 62 deletions(-)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index ed67710714..4553b168f5 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -132,11 +132,36 @@ static int matsu_sd_wait_for_irq(struct udevice *dev, 
unsigned int reg,
return 0;
 }
 
+#define matsu_pio_read_fifo(__width, __suffix) \
+static void matsu_pio_read_fifo_##__width(struct matsu_sd_priv *priv,  \
+ char *pbuf, uint blksz)   \
+{  \
+   u##__width *buf = (u##__width *)pbuf;   \
+   int i;  \
+   \
+   if (likely(IS_ALIGNED((uintptr_t)buf, ((__width) / 8 {  \
+   for (i = 0; i < blksz / ((__width) / 8); i++) { \
+   *buf++ = matsu_sd_read##__suffix(priv,  \
+MATSU_SD_BUF); \
+   }   \
+   } else {\
+   for (i = 0; i < blksz / ((__width) / 8); i++) { \
+   u##__width data;\
+   data = matsu_sd_read##__suffix(priv,\
+  MATSU_SD_BUF);   \
+   put_unaligned(data, buf++); \
+   }   \
+   }   \
+}
+
+matsu_pio_read_fifo(64, q)
+matsu_pio_read_fifo(32, l)
+
 static int matsu_sd_pio_read_one_block(struct udevice *dev, char *pbuf,
  uint blocksize)
 {
struct matsu_sd_priv *priv = dev_get_priv(dev);
-   int i, ret;
+   int ret;
 
/* wait until the buffer is filled with data */
ret = matsu_sd_wait_for_irq(dev, MATSU_SD_INFO2,
@@ -150,83 +175,56 @@ static int matsu_sd_pio_read_one_block(struct udevice 
*dev, char *pbuf,
 */
matsu_sd_writel(priv, 0, MATSU_SD_INFO2);
 
-   if (priv->caps & MATSU_SD_CAP_64BIT) {
-   u64 *buf = (u64 *)pbuf;
-   if (likely(IS_ALIGNED((uintptr_t)buf, 8))) {
-   for (i = 0; i < blocksize / 8; i++) {
-   *buf++ = matsu_sd_readq(priv,
-  MATSU_SD_BUF);
-   }
-   } else {
-   for (i = 0; i < blocksize / 8; i++) {
-   u64 data;
-   data = matsu_sd_readq(priv,
-MATSU_SD_BUF);
-   put_unaligned(data, buf++);
-   }
-   }
-   } else {
-   u32 *buf = (u32 *)pbuf;
-   if (likely(IS_ALIGNED((uintptr_t)buf, 4))) {
-   for (i = 0; i < blocksize / 4; i++) {
-   *buf++ = matsu_sd_readl(priv,
-  MATSU_SD_BUF);
-   }
-   } else {
-   for (i = 0; i < blocksize / 4; i++) {
-   u32 data;
-   data = matsu_sd_readl(priv, MATSU_SD_BUF);
-   put_unaligned(data, buf++);
-   }
-   }
-   }
+   if (priv->caps & MATSU_SD_CAP_64BIT)
+   matsu_pio_read_fifo_64(priv, pbuf, blocksize);
+   else
+   matsu_pio_read_fifo_32(priv, pbuf, blocksize);
 
return 0;
 }
 
+#define matsu_pio_write_fifo(__width, __suffix)
\
+static void matsu_pio_write_fifo_##__width(struct matsu_sd_priv *priv, \
+  const char *pbuf, uint blksz)\
+{  \
+   const u##__width *buf = (const u##__width *)pbuf;   \
+   int i;  \
+   \
+   if (likely(IS_ALIGNED((uintptr_t)buf, 

[U-Boot] [PATCH 14/15] mmc: renesas-sdhi: Add Renesas SDR104/HS200 tuning support

2018-04-09 Thread Marek Vasut
Add code for PHY tuning required for SDR104/HS200 support on Renesas RCar.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/renesas-sdhi.c | 292 -
 1 file changed, 290 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index 73f68c8c3a..e9edcf5f17 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -18,10 +18,293 @@
 
 #include "matsushita-common.h"
 
+#if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
+
+/* SCC registers */
+#define RENESAS_SDHI_SCC_DTCNTL0x800
+#define   RENESAS_SDHI_SCC_DTCNTL_TAPENBIT(0)
+#define   RENESAS_SDHI_SCC_DTCNTL_TAPNUM_SHIFT 16
+#define   RENESAS_SDHI_SCC_DTCNTL_TAPNUM_MASK  0xff
+#define RENESAS_SDHI_SCC_TAPSET0x804
+#define RENESAS_SDHI_SCC_DT2FF 0x808
+#define RENESAS_SDHI_SCC_CKSEL 0x80c
+#define   RENESAS_SDHI_SCC_CKSEL_DTSEL BIT(0)
+#define RENESAS_SDHI_SCC_RVSCNTL   0x810
+#define   RENESAS_SDHI_SCC_RVSCNTL_RVSEN   BIT(0)
+#define RENESAS_SDHI_SCC_RVSREQ0x814
+#define   RENESAS_SDHI_SCC_RVSREQ_RVSERR   BIT(2)
+#define RENESAS_SDHI_SCC_SMPCMP0x818
+#define RENESAS_SDHI_SCC_TMPPORT2  0x81c
+
+#define RENESAS_SDHI_MAX_TAP 3
+
+static unsigned int renesas_sdhi_init_tuning(struct matsu_sd_priv *priv)
+{
+   u32 reg;
+
+   /* Initialize SCC */
+   matsu_sd_writel(priv, 0, MATSU_SD_INFO1);
+
+   reg = matsu_sd_readl(priv, MATSU_SD_CLKCTL);
+   reg &= ~MATSU_SD_CLKCTL_SCLKEN;
+   matsu_sd_writel(priv, reg, MATSU_SD_CLKCTL);
+
+   /* Set sampling clock selection range */
+   matsu_sd_writel(priv, 0x8 << RENESAS_SDHI_SCC_DTCNTL_TAPNUM_SHIFT,
+  RENESAS_SDHI_SCC_DTCNTL);
+
+   reg = matsu_sd_readl(priv, RENESAS_SDHI_SCC_DTCNTL);
+   reg |= RENESAS_SDHI_SCC_DTCNTL_TAPEN;
+   matsu_sd_writel(priv, reg, RENESAS_SDHI_SCC_DTCNTL);
+
+   reg = matsu_sd_readl(priv, RENESAS_SDHI_SCC_CKSEL);
+   reg |= RENESAS_SDHI_SCC_CKSEL_DTSEL;
+   matsu_sd_writel(priv, reg, RENESAS_SDHI_SCC_CKSEL);
+
+   reg = matsu_sd_readl(priv, RENESAS_SDHI_SCC_RVSCNTL);
+   reg &= ~RENESAS_SDHI_SCC_RVSCNTL_RVSEN;
+   matsu_sd_writel(priv, reg, RENESAS_SDHI_SCC_RVSCNTL);
+
+   matsu_sd_writel(priv, 0x300 /* scc_tappos */,
+  RENESAS_SDHI_SCC_DT2FF);
+
+   reg = matsu_sd_readl(priv, MATSU_SD_CLKCTL);
+   reg |= MATSU_SD_CLKCTL_SCLKEN;
+   matsu_sd_writel(priv, reg, MATSU_SD_CLKCTL);
+
+   /* Read TAPNUM */
+   return (matsu_sd_readl(priv, RENESAS_SDHI_SCC_DTCNTL) >>
+   RENESAS_SDHI_SCC_DTCNTL_TAPNUM_SHIFT) &
+   RENESAS_SDHI_SCC_DTCNTL_TAPNUM_MASK;
+}
+
+static void renesas_sdhi_reset_tuning(struct matsu_sd_priv *priv)
+{
+   u32 reg;
+
+   /* Reset SCC */
+   reg = matsu_sd_readl(priv, MATSU_SD_CLKCTL);
+   reg &= ~MATSU_SD_CLKCTL_SCLKEN;
+   matsu_sd_writel(priv, reg, MATSU_SD_CLKCTL);
+
+   reg = matsu_sd_readl(priv, RENESAS_SDHI_SCC_CKSEL);
+   reg &= ~RENESAS_SDHI_SCC_CKSEL_DTSEL;
+   matsu_sd_writel(priv, reg, RENESAS_SDHI_SCC_CKSEL);
+
+   reg = matsu_sd_readl(priv, MATSU_SD_CLKCTL);
+   reg |= MATSU_SD_CLKCTL_SCLKEN;
+   matsu_sd_writel(priv, reg, MATSU_SD_CLKCTL);
+
+   reg = matsu_sd_readl(priv, RENESAS_SDHI_SCC_RVSCNTL);
+   reg &= ~RENESAS_SDHI_SCC_RVSCNTL_RVSEN;
+   matsu_sd_writel(priv, reg, RENESAS_SDHI_SCC_RVSCNTL);
+
+   reg = matsu_sd_readl(priv, RENESAS_SDHI_SCC_RVSCNTL);
+   reg &= ~RENESAS_SDHI_SCC_RVSCNTL_RVSEN;
+   matsu_sd_writel(priv, reg, RENESAS_SDHI_SCC_RVSCNTL);
+}
+
+static void renesas_sdhi_prepare_tuning(struct matsu_sd_priv *priv,
+  unsigned long tap)
+{
+   /* Set sampling clock position */
+   matsu_sd_writel(priv, tap, RENESAS_SDHI_SCC_TAPSET);
+}
+
+static unsigned int renesas_sdhi_compare_scc_data(struct matsu_sd_priv *priv)
+{
+   /* Get comparison of sampling data */
+   return matsu_sd_readl(priv, RENESAS_SDHI_SCC_SMPCMP);
+}
+
+static int renesas_sdhi_select_tuning(struct matsu_sd_priv *priv,
+unsigned int tap_num, unsigned int taps,
+unsigned int smpcmp)
+{
+   unsigned long tap_cnt;  /* counter of tuning success */
+   unsigned long tap_set;  /* tap position */
+   unsigned long tap_start;/* start position of tuning success */
+   unsigned long tap_end;  /* end position of tuning success */
+   unsigned long ntap; /* temporary counter of tuning success */
+   unsigned long match_cnt;/* counter of matching data */
+   unsigned long i;
+   

[U-Boot] [PATCH 05/15] mmc: renesas-sdhi: Handle 16bit IP

2018-04-09 Thread Marek Vasut
The Renesas RCar Gen2 chips have a mix of 32bit and 16bit variants
of the IP. There is no DT property which allows discerning those,
so what Linux does is it checks the size of the register area and
if it is 0x100, the IP is 16bit, otherwise the IP is 32bit. Handle
the distinction the same way.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/renesas-sdhi.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index d6b3bfbadc..521574387b 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -41,6 +41,19 @@ static const struct udevice_id renesas_sdhi_match[] = {
 static int renesas_sdhi_probe(struct udevice *dev)
 {
u32 quirks = dev_get_driver_data(dev);
+   struct fdt_resource reg_res;
+   DECLARE_GLOBAL_DATA_PTR;
+   int ret;
+
+   ret = fdt_get_resource(gd->fdt_blob, dev_of_offset(dev), "reg",
+  0, _res);
+   if (ret < 0) {
+   dev_err(dev, "\"reg\" resource not found, ret=%i\n", ret);
+   return ret;
+   }
+
+   if (quirks == 0 && fdt_resource_size(_res) == 0x100)
+   quirks = MATSU_SD_CAP_16BIT;
 
return matsu_sd_probe(dev, quirks);
 }
-- 
2.16.2

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


Re: [U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Guillaume Gardet



Le 09/04/2018 à 16:21, Jean-Jacques Hiblot a écrit :



On 09/04/2018 16:03, Guillaume Gardet wrote:



Le 09/04/2018 à 15:58, Jean-Jacques Hiblot a écrit :



On 09/04/2018 14:02, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) with latest 
master (and also 2018.05-rc1 and 2018.03).

eMMC is ok, but SD card access leads to 'unable to select a mode' problem. If I 
disable HS mode, I can access the SD card without problem:

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
 }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to select a 
mode' error */
+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

 cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }


Once we try to select HS mode, all access to SD card result in failure, even 
when trying to setup a lower frequency mode, including SD legacy at 25 MHz.

Any idea what is going? Maybe you have fixes pending?


Can try with MMC_MODE_HS | MMC_MODE_HS_52MHz but with a lower max-frequency 
(<25MHz) ? It would be interesting to know if it could come from a frequency 
limitation.


I already tried to change SD_HS freq (in mmc_mode2freq) from 5000 to 
2500 with no difference.


Is there some pad configuration to do when using higher frequency?


I do not think so.

Can you enable the debug output and post a log ?


Here is the log from u-boot built from u-boot-mmc (latest commit: 21c2ac32b845)
Yes, I have no serial, so I retyped the messages, so I hope there is no typo:
**
selecting mode MMC legacy (freq : 0 MHz)
selecting mode MMC legacy (freq : 25 MHz)
sd card: widths [4, 1] modes [SD Legacy, SD High SPeed (50MHz)]
host: widths [4, 1] modes [MMC legacy, SD Legacy, MMC High Speed (26MHz), SD 
High Speed (50MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz)]
trying mode SD High Speed (50MHz) width 4 (at 50 MHz)
selecting mode SD High Speed (50 MHz) (freq : 50 MHz)
unable to read ssr
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD High Speed (50MHz) width 1 (at 50 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 4 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 1 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
unable to select a mode
mmc_init: -524, time 127
** Bad device mmc 1 **
**

Note that eMMC (on mmc 0) is working fine with MMC DDR52 (52MHz).

Guillaume

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


Re: [U-Boot] [U-Boot, v2, 1/5] Migrate CONFIG_DRIVER_TI_CPSW to Kconfig

2018-04-09 Thread Tom Rini
On Sun, Apr 01, 2018 at 09:22:34AM +, Alex Kiernan wrote:

> This converts CONFIG_DRIVER_TI_CPSW to Kconfig
> 
> Signed-off-by: Alex Kiernan 
> Acked-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 5/5] net: Move enetaddr env access code to env config instead of net config

2018-04-09 Thread Tom Rini
On Sun, Apr 01, 2018 at 09:22:38AM +, Alex Kiernan wrote:

> In order that we can use eth_env_* even when CONFIG_NET isn't set, move
> these functions to environment code from net code.
> 
> This fixes failures such as:
> 
>   board/ti/am335x/built-in.o: In function `board_late_init':
>   board/ti/am335x/board.c:752: undefined reference to `eth_env_set_enetaddr'
>   u-boot/board/ti/am335x/board.c:766: undefined reference to 
> `eth_env_set_enetaddr'
> 
> which caters for use cases such as:
> 
> commit f411b5cca48f ("board: am335x: Always set eth/eth1addr environment
> variable")
> 
> when Ethernet is required in Linux, but not U-Boot.
> 
> Signed-off-by: Alex Kiernan 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 4/5] ti: am335x: Fix build when networking is disabled

2018-04-09 Thread Tom Rini
On Sun, Apr 01, 2018 at 09:22:37AM +, Alex Kiernan wrote:

> When compiling without CONFIG_CLOCK_SYNTHESIZER (which is implied by
> CONFIG_DRIVER_TI_CPSW for am335x_evm), exclude the network setup for
> AM335x-ICEv2 to avoid link time failures:
> 
>   board/ti/am335x/board.c:683: undefined reference to 
> `setup_clock_synthesizer'
> 
> Signed-off-by: Alex Kiernan 

Applied to u-boot/master, thanks!

-- 
Tom


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


[U-Boot] [PATCH 15/15] ARM: rmobile: Enable HS200 mode on RCar Gen3

2018-04-09 Thread Marek Vasut
Enable the HS200 on RCar Gen3 platforms, since the SDHI core supports it.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 configs/r8a7795_salvator-x_defconfig | 4 
 configs/r8a7795_ulcb_defconfig   | 4 
 configs/r8a7796_salvator-x_defconfig | 4 
 configs/r8a7796_ulcb_defconfig   | 4 
 configs/r8a77970_eagle_defconfig | 4 
 configs/r8a77995_draak_defconfig | 4 
 6 files changed, 24 insertions(+)

diff --git a/configs/r8a7795_salvator-x_defconfig 
b/configs/r8a7795_salvator-x_defconfig
index 0614894333..b48513ca2a 100644
--- a/configs/r8a7795_salvator-x_defconfig
+++ b/configs/r8a7795_salvator-x_defconfig
@@ -37,7 +37,11 @@ CONFIG_RCAR_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_RCAR_IIC=y
 CONFIG_DM_MMC=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_RENESAS_SDHI=y
+CONFIG_MMC_RENESAS_TUNING=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
diff --git a/configs/r8a7795_ulcb_defconfig b/configs/r8a7795_ulcb_defconfig
index cffa7197a1..a45aec3c43 100644
--- a/configs/r8a7795_ulcb_defconfig
+++ b/configs/r8a7795_ulcb_defconfig
@@ -37,7 +37,11 @@ CONFIG_RCAR_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_RCAR_IIC=y
 CONFIG_DM_MMC=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_RENESAS_SDHI=y
+CONFIG_MMC_RENESAS_TUNING=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
diff --git a/configs/r8a7796_salvator-x_defconfig 
b/configs/r8a7796_salvator-x_defconfig
index 535163fc31..680c7d9226 100644
--- a/configs/r8a7796_salvator-x_defconfig
+++ b/configs/r8a7796_salvator-x_defconfig
@@ -38,7 +38,11 @@ CONFIG_RCAR_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_RCAR_IIC=y
 CONFIG_DM_MMC=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_RENESAS_SDHI=y
+CONFIG_MMC_RENESAS_TUNING=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
diff --git a/configs/r8a7796_ulcb_defconfig b/configs/r8a7796_ulcb_defconfig
index 45c0ca219f..2b552cc531 100644
--- a/configs/r8a7796_ulcb_defconfig
+++ b/configs/r8a7796_ulcb_defconfig
@@ -38,7 +38,11 @@ CONFIG_RCAR_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_RCAR_IIC=y
 CONFIG_DM_MMC=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_RENESAS_SDHI=y
+CONFIG_MMC_RENESAS_TUNING=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
diff --git a/configs/r8a77970_eagle_defconfig b/configs/r8a77970_eagle_defconfig
index 2e7f7ac645..56c949f135 100644
--- a/configs/r8a77970_eagle_defconfig
+++ b/configs/r8a77970_eagle_defconfig
@@ -37,7 +37,11 @@ CONFIG_RCAR_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_RCAR_IIC=y
 CONFIG_DM_MMC=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_RENESAS_SDHI=y
+CONFIG_MMC_RENESAS_TUNING=y
 CONFIG_PHY_MICREL=y
 CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
diff --git a/configs/r8a77995_draak_defconfig b/configs/r8a77995_draak_defconfig
index 7a2e33e001..9792f5efe7 100644
--- a/configs/r8a77995_draak_defconfig
+++ b/configs/r8a77995_draak_defconfig
@@ -38,7 +38,11 @@ CONFIG_RCAR_GPIO=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_RCAR_IIC=y
 CONFIG_DM_MMC=y
+CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_MMC_UHS_SUPPORT=y
+CONFIG_MMC_HS200_SUPPORT=y
 CONFIG_RENESAS_SDHI=y
+CONFIG_MMC_RENESAS_TUNING=y
 CONFIG_MTD=y
 CONFIG_MTD_NOR_FLASH=y
 CONFIG_CFI_FLASH=y
-- 
2.16.2

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


Re: [U-Boot] [PATCH] imx: nitrogen6x: Convert Sabrelite to distro boot support

2018-04-09 Thread Guillaume Gardet



Le 09/04/2018 à 16:40, Gary Bisson a écrit :

Hi Guillaume,

Thanks for your patch! Switching the upstream nitrogen6x configuration
to distro bootcmd has been in our todo list for some time since we also
use that in our own git repo.

On Fri, Apr 06, 2018 at 12:05:48PM +0200, Guillaume GARDET wrote:

Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots.

Signed-off-by: Guillaume GARDET 
Cc: Troy Kisky 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
  include/configs/nitrogen6x.h | 86 ++--
  1 file changed, 18 insertions(+), 68 deletions(-)

diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index c73cfb7f7e..2e2c499cb6 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -102,82 +102,32 @@
  #define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
  
  #if defined(CONFIG_SABRELITE)

Please also switch nitrogen6x to it, not only sabrelite.


Should we keep all the 6x scripts stuff or not?




+#define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 0) \
+   func(MMC, mmc, 1) \
+   func(SATA, sata, 0) \
+   func(USB, usb, 0) \
+   func(PXE, pxe, na) \

That currently doesn't build because CMD_PXE isn't selected in the
sabrelite defconfig.
"include/config_distro_bootcmd.h:319:2: error: expected ‘}’ before
‘BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE’"

Which brings a good point, all the above should depend on the storage
command being present, like done here [1].


No, we just need to update the defconfig, see V2 of this patch sent earlier 
today.




+   func(DHCP, dhcp, na)
+
+#include 
+
  #define CONFIG_EXTRA_ENV_SETTINGS \
-   "script=boot.scr\0" \
-   "uimage=uImage\0" \
"console=ttymxc1\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
-   "fdt_file=imx6q-sabrelite.dtb\0" \
+   "fdtfile=imx6q-sabrelite.dtb\0" \

I wish the default efi_fdtfile would work, Fabio is there any plan to
populate the ${soc} variable like it is done for i.MX7? [2]
Then a small patch in the nitrogen6x.c would set the proper board env
variable.

That way there would be no difference in this header between sabrelite
vs. nitrogen6x.


"fdt_addr=0x1800\0" \

Do we need to keep fdt_addr since we define fdt_addr_r below?


It was for backward compatibility, if people had some script using it.




-   "boot_fdt=try\0" \
+   "fdt_addr_r=0x1800\0" \
+   "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0"  \
+   "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+   "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
+   "ramdisk_addr_r=0x1300\0" \
+   "ramdiskaddr=0x1300\0" \
"ip_dyn=yes\0" \
"usb_pgood_delay=2000\0" \
-   "mmcdevs=0 1\0" \
-   "mmcpart=1\0" \
-   "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
-   "mmcargs=setenv bootargs console=${console},${baudrate} " \
-   "root=${mmcroot}\0" \
-   "loadbootscript=" \
-   "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-   "bootscript=echo Running bootscript from mmc ...; " \
-   "source\0" \
-   "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
-   "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
-   "mmcboot=echo Booting from mmc ...; " \
-   "run mmcargs; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if run loadfdt; then " \
-   "bootm ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootm; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi; " \
-   "else " \
-   "bootm; " \
-   "fi;\0" \
-   "netargs=setenv bootargs console=${console},${baudrate} " \
-   "root=/dev/nfs " \
-   "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
-   "netboot=echo Booting from net ...; " \
-   "run netargs; " \
-   "if test ${ip_dyn} = yes; then " \
-   "setenv get_cmd dhcp; " \
-   "else " \
-   "setenv get_cmd tftp; " \
-   "fi; " \
-   "${get_cmd} ${uimage}; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
-   "bootm ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootm; " \
-   "else " \
-   

[U-Boot] [PATCH v3] arm64: Add SMC and HVC commands

2018-04-09 Thread Michalis Pappas
This patch adds smc and hvc commands, that allow issuing Secure Monitor
Calls and Hypervisor Calls conforming to the ARM SMC Calling Convention.

Add Kconfig items to allow each command can be individually enabled.

Signed-off-by: Michalis Pappas 
---

 cmd/Kconfig  | 14 ++
 cmd/Makefile |  2 ++
 cmd/smccc.c  | 72 
 3 files changed, 88 insertions(+)
 create mode 100644 cmd/smccc.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 136836d146..2176b98ccb 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1348,6 +1348,20 @@ config CMD_HASH
  saved to memory or to an environment variable. It is also possible
  to verify a hash against data in memory.

+config CMD_HVC
+   bool "Support the 'hvc' command"
+   depends on ARM_SMCCC
+   help
+ Allows issuing Hypervisor Calls (HVCs). Mostly useful for
+ development and testing.
+
+config CMD_SMC
+   bool "Support the 'smc' command"
+   depends on ARM_SMCCC
+   help
+ Allows issuing Secure Monitor Calls (SMCs). Mostly useful for
+ development and testing.
+
 config HASH_VERIFY
bool "hash -v"
depends on CMD_HASH
diff --git a/cmd/Makefile b/cmd/Makefile
index 9a358e4801..5656a1a40a 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_CMD_FS_GENERIC) += fs.o
 obj-$(CONFIG_CMD_FUSE) += fuse.o
 obj-$(CONFIG_CMD_GETTIME) += gettime.o
 obj-$(CONFIG_CMD_GPIO) += gpio.o
+obj-$(CONFIG_CMD_HVC) += smccc.o
 obj-$(CONFIG_CMD_I2C) += i2c.o
 obj-$(CONFIG_CMD_IOTRACE) += iotrace.o
 obj-$(CONFIG_CMD_HASH) += hash.o
@@ -113,6 +114,7 @@ obj-$(CONFIG_CMD_SHA1SUM) += sha1sum.o
 obj-$(CONFIG_CMD_SETEXPR) += setexpr.o
 obj-$(CONFIG_CMD_SPI) += spi.o
 obj-$(CONFIG_CMD_STRINGS) += strings.o
+obj-$(CONFIG_CMD_SMC) += smccc.o
 obj-$(CONFIG_CMD_TERMINAL) += terminal.o
 obj-$(CONFIG_CMD_TIME) += time.o
 obj-$(CONFIG_CMD_TRACE) += trace.o
diff --git a/cmd/smccc.c b/cmd/smccc.c
new file mode 100644
index 00..2fa7c23999
--- /dev/null
+++ b/cmd/smccc.c
@@ -0,0 +1,72 @@
+/*
+ * Copyright 2018
+ * Michalis Pappas 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int do_call(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   struct arm_smccc_res res;
+
+   unsigned long fid;
+
+   unsigned long a1;
+   unsigned long a2;
+   unsigned long a3;
+   unsigned long a4;
+   unsigned long a5;
+   unsigned long a6;
+   unsigned long a7;
+
+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   fid = simple_strtoul(argv[1], NULL, 16);
+
+   a1 = argc > 2 ? simple_strtoul(argv[2], NULL, 16) : 0;
+   a2 = argc > 3 ? simple_strtoul(argv[3], NULL, 16) : 0;
+   a3 = argc > 4 ? simple_strtoul(argv[4], NULL, 16) : 0;
+   a4 = argc > 5 ? simple_strtoul(argv[5], NULL, 16) : 0;
+   a5 = argc > 6 ? simple_strtoul(argv[6], NULL, 16) : 0;
+   a6 = argc > 7 ? simple_strtoul(argv[7], NULL, 16) : 0;
+   a7 = argc > 8 ? simple_strtoul(argv[8], NULL, 16) : 0;
+
+   if (!strcmp(argv[0], "smc"))
+   arm_smccc_smc(fid, a1, a2, a3, a4, a5, a6, a7, );
+   else
+   arm_smccc_hvc(fid, a1, a2, a3, a4, a5, a6, a7, );
+
+   printf("Res:  %ld %ld %ld %ld\n", res.a0, res.a1, res.a2, res.a3);
+
+   return 0;
+}
+
+#ifdef CONFIG_CMD_SMC
+U_BOOT_CMD(
+   smc,8,  2,  do_call,
+   "Issue a Secure Monitor Call",
+   " [arg1 ... arg6] [id]\n"
+   "  - fid Function ID\n"
+   "  - arg SMC arguments, passed to X1-X6 (default to zero)\n"
+   "  - id  Secure OS ID / Session ID, passed to W7 (defaults to zero)\n"
+);
+#endif
+
+#ifdef CONFIG_CMD_HVC
+U_BOOT_CMD(
+   hvc,8,  2,  do_call,
+   "Issue a Hypervisor Call",
+   " [arg1...arg7] [id]\n"
+   "  - fid Function ID\n"
+   "  - arg HVC arguments, passed to X1-X6 (default to zero)\n"
+   "  - id  Session ID, passed to W7 (defaults to zero)\n"
+);
+#endif
+
--
2.17.0

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


Re: [U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Guillaume Gardet



Le 09/04/2018 à 17:18, Jean-Jacques Hiblot a écrit :



On 09/04/2018 16:46, Guillaume Gardet wrote:



Le 09/04/2018 à 16:21, Jean-Jacques Hiblot a écrit :



On 09/04/2018 16:03, Guillaume Gardet wrote:



Le 09/04/2018 à 15:58, Jean-Jacques Hiblot a écrit :



On 09/04/2018 14:02, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) with latest 
master (and also 2018.05-rc1 and 2018.03).

eMMC is ok, but SD card access leads to 'unable to select a mode' problem. If I 
disable HS mode, I can access the SD card without problem:

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
 }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to select a 
mode' error */
+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

 cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }


Once we try to select HS mode, all access to SD card result in failure, even 
when trying to setup a lower frequency mode, including SD legacy at 25 MHz.

Any idea what is going? Maybe you have fixes pending?


Can try with MMC_MODE_HS | MMC_MODE_HS_52MHz but with a lower max-frequency 
(<25MHz) ? It would be interesting to know if it could come from a frequency 
limitation.


I already tried to change SD_HS freq (in mmc_mode2freq) from 5000 to 
2500 with no difference.


Is there some pad configuration to do when using higher frequency?


I do not think so.

Can you enable the debug output and post a log ?


Here is the log from u-boot built from u-boot-mmc (latest commit: 21c2ac32b845)
Yes, I have no serial, so I retyped the messages, so I hope there is no typo:
**
selecting mode MMC legacy (freq : 0 MHz)
selecting mode MMC legacy (freq : 25 MHz)
sd card: widths [4, 1] modes [SD Legacy, SD High SPeed (50MHz)]
host: widths [4, 1] modes [MMC legacy, SD Legacy, MMC High Speed (26MHz), SD 
High Speed (50MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz)]
trying mode SD High Speed (50MHz) width 4 (at 50 MHz)
selecting mode SD High Speed (50 MHz) (freq : 50 MHz)
unable to read ssr
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD High Speed (50MHz) width 1 (at 50 MHz)

So it fails either in sd_select_bus_width() or sd_set_card_speed()
Can you try to limit the bus width to 1 ? Does it fail also at 50 MHz ?


Yes, it fails too.

Guillaume




selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 4 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 1 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
unable to select a mode
mmc_init: -524, time 127
** Bad device mmc 1 **
**

Note that eMMC (on mmc 0) is working fine with MMC DDR52 (52MHz).

Guillaume






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


[U-Boot] [PATCH 11/15] mmc: matsushita-common: Always check controller version

2018-04-09 Thread Marek Vasut
Handle the controller version even if quirks are set. The controller in
Renesas Gen3 SoCs does provide the version register, which indicates a
controller v10 and the controller does support internal DMA and /1024
divider.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index 377f349b41..d5facd972f 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -722,16 +722,15 @@ int matsu_sd_probe(struct udevice *dev, u32 quirks)
plat->cfg.name = dev->name;
plat->cfg.host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
 
-   if (quirks) {
+   if (quirks)
priv->caps = quirks;
-   } else {
-   priv->version = matsu_sd_readl(priv, MATSU_SD_VERSION) &
-   MATSU_SD_VERSION_IP;
-   dev_dbg(dev, "version %x\n", priv->version);
-   if (priv->version >= 0x10) {
-   priv->caps |= MATSU_SD_CAP_DMA_INTERNAL;
-   priv->caps |= MATSU_SD_CAP_DIV1024;
-   }
+
+   priv->version = matsu_sd_readl(priv, MATSU_SD_VERSION) &
+   MATSU_SD_VERSION_IP;
+   dev_dbg(dev, "version %x\n", priv->version);
+   if (priv->version >= 0x10) {
+   priv->caps |= MATSU_SD_CAP_DMA_INTERNAL;
+   priv->caps |= MATSU_SD_CAP_DIV1024;
}
 
if (fdt_get_property(gd->fdt_blob, dev_of_offset(dev), "non-removable",
-- 
2.16.2

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


Re: [U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Guillaume Gardet



Le 09/04/2018 à 18:02, Guillaume Gardet a écrit :



Le 09/04/2018 à 17:18, Jean-Jacques Hiblot a écrit :



On 09/04/2018 16:46, Guillaume Gardet wrote:



Le 09/04/2018 à 16:21, Jean-Jacques Hiblot a écrit :



On 09/04/2018 16:03, Guillaume Gardet wrote:



Le 09/04/2018 à 15:58, Jean-Jacques Hiblot a écrit :



On 09/04/2018 14:02, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) with latest 
master (and also 2018.05-rc1 and 2018.03).

eMMC is ok, but SD card access leads to 'unable to select a mode' problem. If I 
disable HS mode, I can access the SD card without problem:

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
 }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to select a 
mode' error */
+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

 cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }


Once we try to select HS mode, all access to SD card result in failure, even 
when trying to setup a lower frequency mode, including SD legacy at 25 MHz.

Any idea what is going? Maybe you have fixes pending?


Can try with MMC_MODE_HS | MMC_MODE_HS_52MHz but with a lower max-frequency 
(<25MHz) ? It would be interesting to know if it could come from a frequency 
limitation.


I already tried to change SD_HS freq (in mmc_mode2freq) from 5000 to 
2500 with no difference.


Is there some pad configuration to do when using higher frequency?


I do not think so.

Can you enable the debug output and post a log ?


Here is the log from u-boot built from u-boot-mmc (latest commit: 21c2ac32b845)
Yes, I have no serial, so I retyped the messages, so I hope there is no typo:
**
selecting mode MMC legacy (freq : 0 MHz)
selecting mode MMC legacy (freq : 25 MHz)
sd card: widths [4, 1] modes [SD Legacy, SD High SPeed (50MHz)]
host: widths [4, 1] modes [MMC legacy, SD Legacy, MMC High Speed (26MHz), SD 
High Speed (50MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz)]
trying mode SD High Speed (50MHz) width 4 (at 50 MHz)
selecting mode SD High Speed (50 MHz) (freq : 50 MHz)
unable to read ssr
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD High Speed (50MHz) width 1 (at 50 MHz)

So it fails either in sd_select_bus_width() or sd_set_card_speed()
Can you try to limit the bus width to 1 ? Does it fail also at 50 MHz ?


Yes, it fails too.


If I disable sd_set_card_speed, then it is working fine.

Guillaume



Guillaume




selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 4 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
trying mode SD Legacy (25MHz) width 1 (at 25 MHz)
selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
unable to select a mode
mmc_init: -524, time 127
** Bad device mmc 1 **
**

Note that eMMC (on mmc 0) is working fine with MMC DDR52 (52MHz).

Guillaume








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


Re: [U-Boot] [RFC PATCH] net: phy: Don't limit phy addresses by default

2018-04-09 Thread Joe Hershberger
On Mon, Apr 9, 2018 at 3:05 AM, Dr. Philipp Tomsich
 wrote:
>
>> On 9 Apr 2018, at 10:01, Neil Armstrong  wrote:
>>
>> On 30/03/2018 18:52, Joe Hershberger wrote:
>>> Some boards expect to find more than one phy while other boards are old
>>> and need to be limited to a specific phy address. Only limit the phy
>>> address for boards that opt in.
>>>
>>> Signed-off-by: Joe Hershberger 
>
> Reviewed-by: Philipp Tomsich 
>
> See below for recommended change.
>
>>>
>>> ---
>>>
>>> configs/am335x_baltos_defconfig| 1 +
>>> configs/am335x_shc_defconfig   | 1 +
>>> configs/am335x_shc_ict_defconfig   | 1 +
>>> configs/am335x_shc_netboot_defconfig   | 1 +
>>> configs/am335x_shc_prompt_defconfig| 1 +
>>> configs/am335x_shc_sdboot_defconfig| 1 +
>>> configs/am335x_shc_sdboot_prompt_defconfig | 1 +
>>> configs/devkit3250_defconfig   | 1 +
>>> configs/ds414_defconfig| 1 +
>>> configs/khadas-vim_defconfig   | 1 +
>>> configs/libretech-cc_defconfig | 1 +
>>> configs/p212_defconfig | 1 +
>>> configs/pepper_defconfig   | 1 +
>>> configs/work_92105_defconfig   | 1 +
>>> configs/x600_defconfig | 1 +
>>> drivers/net/phy/Kconfig| 8 
>>> 16 files changed, 23 insertions(+)

[...]

>>> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
>>> index 179e041..f5821df 100644
>>> --- a/drivers/net/phy/Kconfig
>>> +++ b/drivers/net/phy/Kconfig
>>> @@ -13,12 +13,20 @@ menuconfig PHYLIB
>>>
>>> if PHYLIB
>>>
>>> +config PHY_ADDR_ENABLE
>>> +bool "Limit phy address"
>>> +default y if ARCH_SUNXI
>
> Not happy about this one being in this specific Kconfig.
> This should be an ‘default’ or 'imply’ over in the sunxi top-level Kconfig 
> (i.e. whereever ARCH_SUNXI is declared).
>

Patches welcome. I'm not sure how Kconfig would react to that.

>>> +help
>>> +  Select this if you want to control which phy address is used
>>> +
>>> +if PHY_ADDR_ENABLE
>>> config PHY_ADDR
>>>  int "PHY address"
>>>  default 1 if ARCH_SUNXI
>>>  default 0
>>>  help
>>>The address of PHY on MII bus. Usually in range of 0 to 31.
>>> +endif
>>>
>>> config B53_SWITCH
>>>  bool "Broadcom BCM53xx (RoboSwitch) Ethernet switch PHY support."
>>>
>> Hi,
>>
>> For p212, libretech-cc and khadas-vim,
>>
>> Acked-by: Neil Armstrong > >
>>
>> Neil
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/5] mmc: matsushita-common: Correctly set mode in 16bit

2018-04-09 Thread Marek Vasut
The HOST_MODE register must be set to 0 when the IP is operated in 16bit
mode, otherwise 16bit access to the data FIFO may fail.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index 739586557a..e552a09ea1 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -688,8 +688,6 @@ static void matsu_sd_host_init(struct matsu_sd_priv *priv)
 */
if (priv->version >= 0x10)
matsu_sd_writel(priv, 0x101, MATSU_SD_HOST_MODE);
-   else if (priv->caps & MATSU_SD_CAP_16BIT)
-   matsu_sd_writel(priv, 0x1, MATSU_SD_HOST_MODE);
else
matsu_sd_writel(priv, 0x0, MATSU_SD_HOST_MODE);
 
-- 
2.16.2

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


[U-Boot] [PATCH 1/5] mmc: matsushita-common: Special case only select registers in 16bit

2018-04-09 Thread Marek Vasut
There are only a few registerse used in the 16bit mode which are
32bit internally. Special-case only those in the IO accessors and
always write both halves. Any other register access is protected
from accidentally overwriting neighboring register.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index 3f538c354e..739586557a 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -68,7 +68,9 @@ void matsu_sd_writel(struct matsu_sd_priv *priv,
writel(val, priv->regbase + (reg << 1));
if (priv->caps & MATSU_SD_CAP_16BIT) {
writew(val & 0x, priv->regbase + (reg >> 1));
-   if (val >> 16)
+   if (reg == MATSU_SD_INFO1 || reg == MATSU_SD_INFO1_MASK ||
+   reg == MATSU_SD_INFO2 || reg == MATSU_SD_INFO2_MASK ||
+   reg == MATSU_SD_ARG)
writew(val >> 16, priv->regbase + (reg >> 1) + 2);
} else
writel(val, priv->regbase + reg);
-- 
2.16.2

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


[U-Boot] [PATCH 3/5] mmc: matsushita-common: Wait for command completion

2018-04-09 Thread Marek Vasut
Make sure to wait for the command to complete altogether, including
the trailing 8 clock cycles. This prevents the driver for accidentally
writing the CMD register too fast before the previous command fully
completed.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 2 ++
 drivers/mmc/matsushita-common.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index e552a09ea1..33224bb51b 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -498,6 +498,8 @@ int matsu_sd_send_cmd(struct udevice *dev, struct mmc_cmd 
*cmd,
return ret;
}
 
+   matsu_sd_wait_for_irq(dev, MATSU_SD_INFO2, MATSU_SD_INFO2_SCLKDIVEN);
+
return ret;
 }
 
diff --git a/drivers/mmc/matsushita-common.h b/drivers/mmc/matsushita-common.h
index 3be91c310e..34631cb43e 100644
--- a/drivers/mmc/matsushita-common.h
+++ b/drivers/mmc/matsushita-common.h
@@ -38,6 +38,7 @@
 #define MATSU_SD_INFO2 0x03c   /* IRQ status 2 */
 #define   MATSU_SD_INFO2_ERR_ILA   BIT(15) /* illegal access err */
 #define   MATSU_SD_INFO2_CBSY  BIT(14) /* command busy */
+#define   MATSU_SD_INFO2_SCLKDIVEN BIT(13) /* command setting reg ena */
 #define   MATSU_SD_INFO2_BWE   BIT(9)  /* write buffer ready */
 #define   MATSU_SD_INFO2_BRE   BIT(8)  /* read buffer ready */
 #define   MATSU_SD_INFO2_DAT0  BIT(7)  /* SDDAT0 */
-- 
2.16.2

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


[U-Boot] [PATCH 5/5] mmc: renesas-sdhi: Wait after reconfiguring pins

2018-04-09 Thread Marek Vasut
The IP requires some time to recuperate after the IO pin
properties were changed. Add a delay to assure this.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/renesas-sdhi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index e9edcf5f17..8564f42e20 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -289,6 +289,9 @@ out:
 static int renesas_sdhi_set_ios(struct udevice *dev)
 {
int ret = matsu_sd_set_ios(dev);
+
+   mdelay(10);
+
 #if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
struct matsu_sd_priv *priv = dev_get_priv(dev);
 
-- 
2.16.2

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


[U-Boot] [PATCH 4/5] mmc: matsushita-common: Add missing else

2018-04-09 Thread Marek Vasut
Fix minor rebase omission, the else was missing which triggered
two accesses to the register on 64bit variant of the IP.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index 33224bb51b..e22a9de5da 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -66,7 +66,7 @@ void matsu_sd_writel(struct matsu_sd_priv *priv,
 {
if (priv->caps & MATSU_SD_CAP_64BIT)
writel(val, priv->regbase + (reg << 1));
-   if (priv->caps & MATSU_SD_CAP_16BIT) {
+   else if (priv->caps & MATSU_SD_CAP_16BIT) {
writew(val & 0x, priv->regbase + (reg >> 1));
if (reg == MATSU_SD_INFO1 || reg == MATSU_SD_INFO1_MASK ||
reg == MATSU_SD_INFO2 || reg == MATSU_SD_INFO2_MASK ||
-- 
2.16.2

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


[U-Boot] [PATCH] mtd: rpc: Add Renesas RPC Hyperflash driver

2018-04-09 Thread Marek Vasut
Add driver for the RPC block in Hyperflash mode. This driver allows
access to a CFI Hyperflash attached to the RPC block and does not
support RPC in SPI mode.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 drivers/mtd/Kconfig  |   7 +
 drivers/mtd/Makefile |   1 +
 drivers/mtd/renesas_rpc_hf.c | 398 +++
 3 files changed, 406 insertions(+)
 create mode 100644 drivers/mtd/renesas_rpc_hf.c

diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 19579801d2..707359dca1 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -40,6 +40,13 @@ config FLASH_PIC32
  This enables access to Microchip PIC32 internal non-CFI flash
  chips through PIC32 Non-Volatile-Memory Controller.
 
+config RENESAS_RPC_HF
+   bool "Renesas RCar Gen3 RPC Hyperflash driver"
+   depends on RCAR_GEN3 && MTD
+   help
+ This enables access to Hyperflash memory through the Renesas
+ RCar Gen3 RPC controller.
+
 endmenu
 
 source "drivers/mtd/nand/Kconfig"
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 20c0d0af44..e46cbd8837 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -20,3 +20,4 @@ obj-$(CONFIG_MW_EEPROM) += mw_eeprom.o
 obj-$(CONFIG_FLASH_PIC32) += pic32_flash.o
 obj-$(CONFIG_ST_SMI) += st_smi.o
 obj-$(CONFIG_STM32_FLASH) += stm32_flash.o
+obj-$(CONFIG_RENESAS_RPC_HF) += renesas_rpc_hf.o
diff --git a/drivers/mtd/renesas_rpc_hf.c b/drivers/mtd/renesas_rpc_hf.c
new file mode 100644
index 00..1ba6e354a0
--- /dev/null
+++ b/drivers/mtd/renesas_rpc_hf.c
@@ -0,0 +1,398 @@
+/*
+ * Renesas RCar Gen3 RPC Hyperflash driver
+ *
+ * Copyright (C) 2016 Renesas Electronics Corporation
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ * Copyright (C) 2017 Marek Vasut 
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RPC_CMNCR  0x  /* R/W */
+#define RPC_CMNCR_MD   BIT(31)
+#define RPC_CMNCR_MOIIO0(val)  (((val) & 0x3) << 16)
+#define RPC_CMNCR_MOIIO1(val)  (((val) & 0x3) << 18)
+#define RPC_CMNCR_MOIIO2(val)  (((val) & 0x3) << 20)
+#define RPC_CMNCR_MOIIO3(val)  (((val) & 0x3) << 22)
+#define RPC_CMNCR_MOIIO_HIZ(RPC_CMNCR_MOIIO0(3) | RPC_CMNCR_MOIIO1(3) | \
+RPC_CMNCR_MOIIO2(3) | RPC_CMNCR_MOIIO3(3))
+#define RPC_CMNCR_IO0FV(val)   (((val) & 0x3) << 8)
+#define RPC_CMNCR_IO2FV(val)   (((val) & 0x3) << 12)
+#define RPC_CMNCR_IO3FV(val)   (((val) & 0x3) << 14)
+#define RPC_CMNCR_IOFV_HIZ (RPC_CMNCR_IO0FV(3) | RPC_CMNCR_IO2FV(3) | \
+RPC_CMNCR_IO3FV(3))
+#define RPC_CMNCR_BSZ(val) (((val) & 0x3) << 0)
+
+#define RPC_SSLDR  0x0004  /* R/W */
+#define RPC_SSLDR_SPNDL(d) (((d) & 0x7) << 16)
+#define RPC_SSLDR_SLNDL(d) (((d) & 0x7) << 8)
+#define RPC_SSLDR_SCKDL(d) (((d) & 0x7) << 0)
+
+#define RPC_DRCR   0x000C  /* R/W */
+#define RPC_DRCR_SSLN  BIT(24)
+#define RPC_DRCR_RBURST(v) (((v) & 0x1F) << 16)
+#define RPC_DRCR_RCF   BIT(9)
+#define RPC_DRCR_RBE   BIT(8)
+#define RPC_DRCR_SSLE  BIT(0)
+
+#define RPC_DRCMR  0x0010  /* R/W */
+#define RPC_DRCMR_CMD(c)   (((c) & 0xFF) << 16)
+#define RPC_DRCMR_OCMD(c)  (((c) & 0xFF) << 0)
+
+#define RPC_DREAR  0x0014  /* R/W */
+#define RPC_DREAR_EAV(v)   (((v) & 0xFF) << 16)
+#define RPC_DREAR_EAC(v)   (((v) & 0x7) << 0)
+
+#define RPC_DROPR  0x0018  /* R/W */
+#define RPC_DROPR_OPD3(o)  (((o) & 0xFF) << 24)
+#define RPC_DROPR_OPD2(o)  (((o) & 0xFF) << 16)
+#define RPC_DROPR_OPD1(o)  (((o) & 0xFF) << 8)
+#define RPC_DROPR_OPD0(o)  (((o) & 0xFF) << 0)
+
+#define RPC_DRENR  0x001C  /* R/W */
+#define RPC_DRENR_CDB(o)   (u32)o) & 0x3) << 30))
+#define RPC_DRENR_OCDB(o)  (((o) & 0x3) << 28)
+#define RPC_DRENR_ADB(o)   (((o) & 0x3) << 24)
+#define RPC_DRENR_OPDB(o)  (((o) & 0x3) << 20)
+#define RPC_DRENR_SPIDB(o) (((o) & 0x3) << 16)
+#define RPC_DRENR_DME  BIT(15)
+#define RPC_DRENR_CDE  BIT(14)
+#define RPC_DRENR_OCDE BIT(12)
+#define RPC_DRENR_ADE(v)   (((v) & 0xF) << 8)
+#define RPC_DRENR_OPDE(v)  (((v) & 0xF) << 4)
+
+#define RPC_SMCR   0x0020  /* R/W */
+#define RPC_SMCR_SSLKP BIT(8)
+#define RPC_SMCR_SPIRE BIT(2)
+#define RPC_SMCR_SPIWE BIT(1)
+#define RPC_SMCR_SPIE  BIT(0)
+
+#define RPC_SMCMR  0x0024  /* R/W */
+#define RPC_SMCMR_CMD(c)   (((c) & 0xFF) << 16)
+#define RPC_SMCMR_OCMD(c)  (((c) & 0xFF) << 0)
+
+#define RPC_SMADR  0x0028  /* R/W */
+#define RPC_SMOPR  0x002C  /* R/W */
+#define RPC_SMOPR_OPD0(o)  (((o) & 0xFF) << 0)
+#define RPC_SMOPR_OPD1(o)  

[U-Boot] [PATCH] mtd: spi: Add Renesas RPC SPI-flash driver

2018-04-09 Thread Marek Vasut
Add driver for the RPC block in SPI-flash mode. This driver allows
access to a SPI NOR flash attached to the RPC block and does not
support RPC in Hyperflash mode. Note that this block is extremely
selective when communicating with the SPI NOR.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 drivers/spi/Kconfig   |   8 +
 drivers/spi/Makefile  |   1 +
 drivers/spi/renesas_rpc_spi.c | 465 ++
 3 files changed, 474 insertions(+)
 create mode 100644 drivers/spi/renesas_rpc_spi.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index d3e407ec11..ec92b84ed2 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -114,6 +114,14 @@ config PIC32_SPI
  to access the SPI NOR flash, MMC-over-SPI on platforms based on
  Microchip PIC32 family devices.
 
+config RENESAS_RPC_SPI
+   bool "Renesas RPC SPI driver"
+   depends on RCAR_GEN3
+   help
+ Enable the Renesas RPC SPI driver, used to access SPI NOR flash
+ on Renesas RCar Gen3 SoCs. This uses driver model and requires a
+ device tree binding to operate.
+
 config ROCKCHIP_SPI
bool "Rockchip SPI driver"
help
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 4b6000fd9a..176bfa05cf 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_MXS_SPI) += mxs_spi.o
 obj-$(CONFIG_ATCSPI200_SPI) += atcspi200_spi.o
 obj-$(CONFIG_OMAP3_SPI) += omap3_spi.o
 obj-$(CONFIG_PIC32_SPI) += pic32_spi.o
+obj-$(CONFIG_RENESAS_RPC_SPI) += renesas_rpc_spi.o
 obj-$(CONFIG_ROCKCHIP_SPI) += rk_spi.o
 obj-$(CONFIG_SANDBOX_SPI) += sandbox_spi.o
 obj-$(CONFIG_SH_SPI) += sh_spi.o
diff --git a/drivers/spi/renesas_rpc_spi.c b/drivers/spi/renesas_rpc_spi.c
new file mode 100644
index 00..e54f24c5d8
--- /dev/null
+++ b/drivers/spi/renesas_rpc_spi.c
@@ -0,0 +1,465 @@
+/*
+ * Renesas RCar Gen3 RPC QSPI driver
+ *
+ * Copyright (C) 2018 Marek Vasut 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RPC_CMNCR  0x  /* R/W */
+#define RPC_CMNCR_MD   BIT(31)
+#define RPC_CMNCR_SFDE BIT(24)
+#define RPC_CMNCR_MOIIO3(val)  (((val) & 0x3) << 22)
+#define RPC_CMNCR_MOIIO2(val)  (((val) & 0x3) << 20)
+#define RPC_CMNCR_MOIIO1(val)  (((val) & 0x3) << 18)
+#define RPC_CMNCR_MOIIO0(val)  (((val) & 0x3) << 16)
+#define RPC_CMNCR_MOIIO_HIZ(RPC_CMNCR_MOIIO0(3) | RPC_CMNCR_MOIIO1(3) | \
+RPC_CMNCR_MOIIO2(3) | RPC_CMNCR_MOIIO3(3))
+#define RPC_CMNCR_IO3FV(val)   (((val) & 0x3) << 14)
+#define RPC_CMNCR_IO2FV(val)   (((val) & 0x3) << 12)
+#define RPC_CMNCR_IO0FV(val)   (((val) & 0x3) << 8)
+#define RPC_CMNCR_IOFV_HIZ (RPC_CMNCR_IO0FV(3) | RPC_CMNCR_IO2FV(3) | \
+RPC_CMNCR_IO3FV(3))
+#define RPC_CMNCR_CPHATBIT(6)
+#define RPC_CMNCR_CPHARBIT(5)
+#define RPC_CMNCR_SSLP BIT(4)
+#define RPC_CMNCR_CPOL BIT(3)
+#define RPC_CMNCR_BSZ(val) (((val) & 0x3) << 0)
+
+#define RPC_SSLDR  0x0004  /* R/W */
+#define RPC_SSLDR_SPNDL(d) (((d) & 0x7) << 16)
+#define RPC_SSLDR_SLNDL(d) (((d) & 0x7) << 8)
+#define RPC_SSLDR_SCKDL(d) (((d) & 0x7) << 0)
+
+#define RPC_DRCR   0x000C  /* R/W */
+#define RPC_DRCR_SSLN  BIT(24)
+#define RPC_DRCR_RBURST(v) (((v) & 0x1F) << 16)
+#define RPC_DRCR_RCF   BIT(9)
+#define RPC_DRCR_RBE   BIT(8)
+#define RPC_DRCR_SSLE  BIT(0)
+
+#define RPC_DRCMR  0x0010  /* R/W */
+#define RPC_DRCMR_CMD(c)   (((c) & 0xFF) << 16)
+#define RPC_DRCMR_OCMD(c)  (((c) & 0xFF) << 0)
+
+#define RPC_DREAR  0x0014  /* R/W */
+#define RPC_DREAR_EAV(v)   (((v) & 0xFF) << 16)
+#define RPC_DREAR_EAC(v)   (((v) & 0x7) << 0)
+
+#define RPC_DROPR  0x0018  /* R/W */
+#define RPC_DROPR_OPD3(o)  (((o) & 0xFF) << 24)
+#define RPC_DROPR_OPD2(o)  (((o) & 0xFF) << 16)
+#define RPC_DROPR_OPD1(o)  (((o) & 0xFF) << 8)
+#define RPC_DROPR_OPD0(o)  (((o) & 0xFF) << 0)
+
+#define RPC_DRENR  0x001C  /* R/W */
+#define RPC_DRENR_CDB(o)   (u32)o) & 0x3) << 30))
+#define RPC_DRENR_OCDB(o)  (((o) & 0x3) << 28)
+#define RPC_DRENR_ADB(o)   (((o) & 0x3) << 24)
+#define RPC_DRENR_OPDB(o)  (((o) & 0x3) << 20)
+#define RPC_DRENR_SPIDB(o) (((o) & 0x3) << 16)
+#define RPC_DRENR_DME  BIT(15)
+#define RPC_DRENR_CDE  BIT(14)
+#define RPC_DRENR_OCDE BIT(12)
+#define RPC_DRENR_ADE(v)   (((v) & 0xF) << 8)
+#define RPC_DRENR_OPDE(v)  (((v) & 0xF) << 4)
+
+#define RPC_SMCR   0x0020  /* R/W */
+#define RPC_SMCR_SSLKP BIT(8)
+#define RPC_SMCR_SPIRE BIT(2)
+#define RPC_SMCR_SPIWE BIT(1)

[U-Boot] [PATCH] ARM: rmobile: Fix the memory map on Gen3

2018-04-09 Thread Marek Vasut
Fix up the memory map on Gen3 to match datasheet properly.
This simplifies the memory map setup as well, since we do
no longer need this massive complexity.

Signed-off-by: Marek Vasut 
Cc: Nobuhiro Iwamatsu 
---
 arch/arm/mach-rmobile/cpu_info.c |  3 -
 arch/arm/mach-rmobile/include/mach/rmobile.h |  1 -
 arch/arm/mach-rmobile/memmap-gen3.c  | 92 +++-
 3 files changed, 9 insertions(+), 87 deletions(-)

diff --git a/arch/arm/mach-rmobile/cpu_info.c b/arch/arm/mach-rmobile/cpu_info.c
index ba87d21b73..ce15741c41 100644
--- a/arch/arm/mach-rmobile/cpu_info.c
+++ b/arch/arm/mach-rmobile/cpu_info.c
@@ -18,9 +18,6 @@ int arch_cpu_init(void)
 #ifndef CONFIG_SYS_DCACHE_OFF
 void enable_caches(void)
 {
-#if defined(CONFIG_RCAR_GEN3)
-   rcar_gen3_memmap_fixup();
-#endif
dcache_enable();
 }
 #endif
diff --git a/arch/arm/mach-rmobile/include/mach/rmobile.h 
b/arch/arm/mach-rmobile/include/mach/rmobile.h
index ff0ca63f02..94ea366f45 100644
--- a/arch/arm/mach-rmobile/include/mach/rmobile.h
+++ b/arch/arm/mach-rmobile/include/mach/rmobile.h
@@ -41,7 +41,6 @@
 u32 rmobile_get_cpu_type(void);
 u32 rmobile_get_cpu_rev_integer(void);
 u32 rmobile_get_cpu_rev_fraction(void);
-void rcar_gen3_memmap_fixup(void);
 #endif /* __ASSEMBLY__ */
 
 #endif /* __ASM_ARCH_RMOBILE_H */
diff --git a/arch/arm/mach-rmobile/memmap-gen3.c 
b/arch/arm/mach-rmobile/memmap-gen3.c
index 801e392425..52cd000a17 100644
--- a/arch/arm/mach-rmobile/memmap-gen3.c
+++ b/arch/arm/mach-rmobile/memmap-gen3.c
@@ -9,77 +9,24 @@
 #include 
 #include 
 
-static struct mm_region r8a7795_mem_map[] = {
+static struct mm_region gen3_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
-   .size = 0x8000UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
-   }, {
-   .virt = 0x8000UL,
-   .phys = 0x8000UL,
-   .size = 0x8000UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
-   }, {
-   /* List terminator */
-   0,
-   }
-};
-
-static struct mm_region r8a7796_mem_map[] = {
-   {
-   .virt = 0x0UL,
-   .phys = 0x0UL,
-   .size = 0xe000UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
-   }, {
-   .virt = 0xe000UL,
-   .phys = 0xe000UL,
-   .size = 0xe000UL,
+   .size = 0x4000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
}, {
-   /* List terminator */
-   0,
-   }
-};
-
-static struct mm_region r8a77970_mem_map[] = {
-   {
-   .virt = 0x0UL,
-   .phys = 0x0UL,
-   .size = 0xe000UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
-   }, {
-   .virt = 0xe000UL,
-   .phys = 0xe000UL,
-   .size = 0xe000UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
-   }, {
-   /* List terminator */
-   0,
-   }
-};
-
-static struct mm_region r8a77995_mem_map[] = {
-   {
-   .virt = 0x0UL,
-   .phys = 0x0UL,
-   .size = 0xe000UL,
+   .virt = 0x4000UL,
+   .phys = 0x4000UL,
+   .size = 0x8000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
}, {
-   .virt = 0xe000UL,
-   .phys = 0xe000UL,
-   .size = 0xe000UL,
+   .virt = 0xc000UL,
+   .phys = 0xc000UL,
+   .size = 0x4000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
@@ -89,25 +36,4 @@ static struct mm_region r8a77995_mem_map[] = {
}
 };
 
-struct mm_region *mem_map = r8a7795_mem_map;
-
-void rcar_gen3_memmap_fixup(void)
-{
-   u32 cpu_type = rmobile_get_cpu_type();
-
-   switch (cpu_type) {
-   case RMOBILE_CPU_TYPE_R8A7795:
-   mem_map = r8a7795_mem_map;
-   break;
-   case RMOBILE_CPU_TYPE_R8A7796:
-   case RMOBILE_CPU_TYPE_R8A77965:
-   mem_map = r8a7796_mem_map;
-   break;
-   case RMOBILE_CPU_TYPE_R8A77970:
-   mem_map = r8a77970_mem_map;
- 

[U-Boot] [PATCH 3/3] bootvx: Explicitly clear the bootloader image size

2018-04-09 Thread Bin Meng
VxWorks bootloader stores its size at a pre-defined offset @ 0x5004.
Later when VxWorks kernel boots up and system memory information is
retrieved from the E820 table, the bootloader size will be subtracted
from the total system memory size to calculate the size of available
memory for the OS.

Explicitly clear the bootloader image size otherwise if memory
at this offset happens to contain some garbage data, the final
available memory size for the kernel is insane.

Signed-off-by: Bin Meng 
---

 cmd/elf.c | 7 +++
 include/vxworks.h | 9 +
 2 files changed, 16 insertions(+)

diff --git a/cmd/elf.c b/cmd/elf.c
index eec9f14..501f935 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -348,6 +348,13 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
info->entries = install_e820_map(E820MAX, data);
info->addr = (info->entries - 1) * sizeof(struct e820entry) +
 E820_DATA_OFFSET;
+
+   /*
+* Explicitly clear the bootloader image size otherwise if memory
+* at this offset happens to contain some garbage data, the final
+* available memory size for the kernel is insane.
+*/
+   *(u32 *)(base + BOOT_IMAGE_SIZE_OFFSET) = 0;
 #endif
 
/*
diff --git a/include/vxworks.h b/include/vxworks.h
index f600dfa..d912076 100644
--- a/include/vxworks.h
+++ b/include/vxworks.h
@@ -43,6 +43,15 @@ struct e820info {
u32 error;  /* must be zero */
 };
 
+/*
+ * VxWorks bootloader stores its size at a pre-defined offset @ 0x5004.
+ * Later when VxWorks kernel boots up and system memory information is
+ * retrieved from the E820 table, the bootloader size will be subtracted
+ * from the total system memory size to calculate the size of available
+ * memory for the OS.
+ */
+#define BOOT_IMAGE_SIZE_OFFSET 0x5004
+
 int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
 void boot_prep_vxworks(bootm_headers_t *images);
 void boot_jump_vxworks(bootm_headers_t *images);
-- 
2.7.4

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


[U-Boot] [PATCH 1/3] doc: vxworks: Minor update for clarity

2018-04-09 Thread Bin Meng
This corrects a typo and updates several places for clarity.

Signed-off-by: Bin Meng 
---

 doc/README.vxworks | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/README.vxworks b/doc/README.vxworks
index 3433e4f..eb1f458 100644
--- a/doc/README.vxworks
+++ b/doc/README.vxworks
@@ -30,11 +30,11 @@ the ePAPR standard, which is shown below (see ePAPR for 
more details):
 
 void (*kernel_entry)(fdt_addr, 0, 0, EPAPR_MAGIC, boot_IMA, 0, 0)
 
-For ARM, the calling convention is show below:
+For ARM, the calling convention is shown below:
 
 void (*kernel_entry)(void *fdt_addr)
 
-When booting new VxWorks kernel (uImage format), the parameters passed to bootm
+When booting a VxWorks 7 kernel (uImage format), the parameters passed to bootm
 is like below:
 
 bootm  - 
@@ -46,7 +46,7 @@ board-specific address before loading VxWorks. U-Boot 
supplies its address
 via "bootaddr" environment variable. To check where the bootline should be
 for a specific board, go to the VxWorks BSP for that board, and look for a
 parameter called BOOT_LINE_ADRS. Assign its value to "bootaddr". A typical
-value for "bootaddr" is 0x101200.
+value for "bootaddr" on an x86 board is 0x101200.
 
 If a "bootargs" variable is defined, its content will be copied to the memory
 location pointed by "bootaddr" as the kernel bootline. If "bootargs" is not
@@ -79,7 +79,7 @@ for "e820data" and "e820info" are 0x104000 and 0x104a00. But 
there is one
 exception on Intel Galileo, where "e820data" and "e820info" should be left
 unset, which assume the default location for VxWorks.
 
-Note since currently U-Boot does not support ACPI yet, VxWorks kernel must
+For boards on which ACPI is not supported by U-Boot yet, VxWorks kernel must
 be configured to use MP table and virtual wire interrupt mode. This requires
 INCLUDE_MPTABLE_BOOT_OP and INCLUDE_VIRTUAL_WIRE_MODE to be included in a
 VxWorks kernel configuration.
-- 
2.7.4

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


[U-Boot] [PATCH 2/3] bootvx: Prepare e820 related stuff from the given kernel memory base address

2018-04-09 Thread Bin Meng
At present two environment variables 'e820data'/'e820info' are required
to boot a VxWorks x86 kernel, but this is superfluous. The offset of
these two tables are actually at a fixed offset from the kernel memory
base address and we can provide the kernel memory base address to U-Boot
via only one variable 'vx_phys_mem_base'.

Note as it name indicates, the physical address should be provided.

Signed-off-by: Bin Meng 
---

 cmd/elf.c  | 21 -
 doc/README.vxworks | 18 +++---
 include/vxworks.h  | 12 +---
 3 files changed, 24 insertions(+), 27 deletions(-)

diff --git a/cmd/elf.c b/cmd/elf.c
index f874073..eec9f14 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -333,26 +333,21 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char 
* const argv[])
}
 
 #ifdef CONFIG_X86
+   ulong base;
+
/*
-* Since E820 information is critical to the kernel, if we don't
-* specify these in the environments, use a default one.
+* Get VxWorks's physical memory base address from environment,
+* if we don't specify it in the environment, use a default one.
 */
-   tmp = env_get("e820data");
-   if (tmp)
-   data = (struct e820entry *)simple_strtoul(tmp, NULL, 16);
-   else
-   data = (struct e820entry *)VXWORKS_E820_DATA_ADDR;
-   tmp = env_get("e820info");
-   if (tmp)
-   info = (struct e820info *)simple_strtoul(tmp, NULL, 16);
-   else
-   info = (struct e820info *)VXWORKS_E820_INFO_ADDR;
+   base = env_get_hex("vx_phys_mem_base", VXWORKS_PHYS_MEM_BASE);
+   data = (struct e820entry *)(base + E820_DATA_OFFSET);
+   info = (struct e820info *)(base + E820_INFO_OFFSET);
 
memset(info, 0, sizeof(struct e820info));
info->sign = E820_SIGNATURE;
info->entries = install_e820_map(E820MAX, data);
info->addr = (info->entries - 1) * sizeof(struct e820entry) +
-VXWORKS_E820_DATA_ADDR;
+E820_DATA_OFFSET;
 #endif
 
/*
diff --git a/doc/README.vxworks b/doc/README.vxworks
index eb1f458..b95a516 100644
--- a/doc/README.vxworks
+++ b/doc/README.vxworks
@@ -67,17 +67,13 @@ look like VxWorks hangs somewhere as nothing outputs on the 
serial console.
 
 x86-specific information
 
-Before loading an x86 kernel, two additional environment variables need to be
-provided. They are "e820data" and "e820info", which represent the address of
-E820 table and E820 information (defined by VxWorks) in system memory.
-
-Check VxWorks kernel configuration to look for BIOS_E820_DATA_START and
-BIOS_E820_INFO_START, and assign their values to "e820data" and "e820info"
-accordingly. If neither of these two are supplied, U-Boot assumes a default
-location at 0x4000 for "e820data" and 0x4a00 for "e820info". Typical values
-for "e820data" and "e820info" are 0x104000 and 0x104a00. But there is one
-exception on Intel Galileo, where "e820data" and "e820info" should be left
-unset, which assume the default location for VxWorks.
+Before loading an x86 kernel, one additional environment variable need to be
+provided. This is "vx_phys_mem_base", which represent the physical memory
+base address of VxWorks.
+
+Check VxWorks kernel configuration to look for LOCAL_MEM_LOCAL_ADRS. For
+VxWorks 7, this is normally a virtual address and you need find out its
+corresponding physical address and assign its value to "vx_phys_mem_base".
 
 For boards on which ACPI is not supported by U-Boot yet, VxWorks kernel must
 be configured to use MP table and virtual wire interrupt mode. This requires
diff --git a/include/vxworks.h b/include/vxworks.h
index f69b008..f600dfa 100644
--- a/include/vxworks.h
+++ b/include/vxworks.h
@@ -9,9 +9,15 @@
 #define _VXWORKS_H_
 
 /*
+ * Physical address of memory base for VxWorks x86
+ * This is LOCAL_MEM_LOCAL_ADRS in the VxWorks kernel configuration.
+ */
+#define VXWORKS_PHYS_MEM_BASE  0x10
+
+/*
  * VxWorks x86 E820 related stuff
  *
- * VxWorks on x86 gets E820 information from pre-defined address @
+ * VxWorks on x86 gets E820 information from pre-defined offset @
  * 0x4a00 and 0x4000. At 0x4a00 it's an information table defined
  * by VxWorks and the actual E820 table entries starts from 0x4000.
  * As defined by the BIOS E820 spec, the maximum number of E820 table
@@ -20,8 +26,8 @@
  * information that is retrieved from the BIOS E820 call and saved
  * later for sanity test during the kernel boot-up.
  */
-#define VXWORKS_E820_DATA_ADDR 0x4000
-#define VXWORKS_E820_INFO_ADDR 0x4a00
+#define E820_DATA_OFFSET   0x4000
+#define E820_INFO_OFFSET   0x4a00
 
 /* E820 info signatiure "SMAP" - System MAP */
 #define E820_SIGNATURE 0x534d4150
-- 
2.7.4

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


Re: [U-Boot] [U-Boot, v2, 2/5] ti: am335x: Fix bootargs when building without NET

2018-04-09 Thread Tom Rini
On Sun, Apr 01, 2018 at 09:22:35AM +, Alex Kiernan wrote:

> If DHCP/PXE commands are disabled then the compilation fails due to
> bootargs attempting to use them:
> 
>   include/config_distro_bootcmd.h:319:2: error: expected ‘}’ before 
> ‘BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE’
> 
> Ensure that if the command aren't enabled, we don't try and use them.
> 
> Signed-off-by: Alex Kiernan 
> Acked-by: Joe Hershberger 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 1/2] Migrate CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG to Kconfig

2018-04-09 Thread Tom Rini
On Sun, Apr 01, 2018 at 04:37:53PM +, Alex Kiernan wrote:

> Convert CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG to Kconfig
> 
> Signed-off-by: Alex Kiernan 
> Reviewed-by: Lukasz Majewski 
> Reviewed-by: Petr Vorel 
> Reviewed-by: Petr Vorel 

Applied to u-boot/master, thanks!

-- 
Tom


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


Re: [U-Boot] [U-Boot, v2, 2/2] Cleanup CONFIG_VERSION_VARIABLE migration

2018-04-09 Thread Tom Rini
On Sun, Apr 01, 2018 at 04:37:54PM +, Alex Kiernan wrote:

> CONFIG_VERSION_VARIABLE had already been mostly migrated to Kconfig,
> but two headers still referenced it. Also set defaults so that
> most of the defconfigs inherit the default rather than needing it
> to be set explicitly.
> 
> Signed-off-by: Alex Kiernan 
> Reviewed-by: Petr Vorel 

Applied to u-boot/master, thanks!

-- 
Tom


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


[U-Boot] [PATCH 13/15] mmc: matsushita-common: Export register access functions

2018-04-09 Thread Marek Vasut
Export the matsu_sd_{read,write}l() common register access
functions, so that they can be used by other drivers sharing
the common code.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 4 ++--
 drivers/mmc/matsushita-common.h | 4 
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index b143f5c229..3f538c354e 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -44,7 +44,7 @@ static void matsu_sd_writew(struct matsu_sd_priv *priv,
writew(val, priv->regbase + (reg >> 1));
 }
 
-static u32 matsu_sd_readl(struct matsu_sd_priv *priv, unsigned int reg)
+u32 matsu_sd_readl(struct matsu_sd_priv *priv, unsigned int reg)
 {
u32 val;
 
@@ -61,7 +61,7 @@ static u32 matsu_sd_readl(struct matsu_sd_priv *priv, 
unsigned int reg)
return readl(priv->regbase + reg);
 }
 
-static void matsu_sd_writel(struct matsu_sd_priv *priv,
+void matsu_sd_writel(struct matsu_sd_priv *priv,
   u32 val, unsigned int reg)
 {
if (priv->caps & MATSU_SD_CAP_64BIT)
diff --git a/drivers/mmc/matsushita-common.h b/drivers/mmc/matsushita-common.h
index b019b72b3e..3be91c310e 100644
--- a/drivers/mmc/matsushita-common.h
+++ b/drivers/mmc/matsushita-common.h
@@ -143,4 +143,8 @@ int matsu_sd_get_cd(struct udevice *dev);
 int matsu_sd_bind(struct udevice *dev);
 int matsu_sd_probe(struct udevice *dev, u32 quirks);
 
+u32 matsu_sd_readl(struct matsu_sd_priv *priv, unsigned int reg);
+void matsu_sd_writel(struct matsu_sd_priv *priv,
+u32 val, unsigned int reg);
+
 #endif /* __MATSUSHITA_COMMON_H__ */
-- 
2.16.2

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


[U-Boot] [PATCH 12/15] mmc: matsushita-common: Properly handle pin voltage configuration

2018-04-09 Thread Marek Vasut
Factor out the regulator handling into set_ios and add support for
selecting pin configuration based on the voltage to support UHS modes.

Signed-off-by: Marek Vasut 
Cc: Jaehoon Chung 
Cc: Masahiro Yamada 
---
 drivers/mmc/matsushita-common.c | 52 ++---
 drivers/mmc/matsushita-common.h |  3 +++
 2 files changed, 46 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/matsushita-common.c b/drivers/mmc/matsushita-common.c
index d5facd972f..b143f5c229 100644
--- a/drivers/mmc/matsushita-common.c
+++ b/drivers/mmc/matsushita-common.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -593,6 +594,46 @@ static void matsu_sd_set_clk_rate(struct matsu_sd_priv 
*priv,
udelay(1000);
 }
 
+static void matsu_sd_set_pins(struct udevice *dev)
+{
+   __maybe_unused struct mmc *mmc = mmc_get_mmc_dev(dev);
+
+#ifdef CONFIG_DM_REGULATOR
+   struct matsu_sd_priv *priv = dev_get_priv(dev);
+
+   if (priv->vqmmc_dev) {
+   if (mmc->signal_voltage == MMC_SIGNAL_VOLTAGE_180)
+   regulator_set_value(priv->vqmmc_dev, 180);
+   else
+   regulator_set_value(priv->vqmmc_dev, 330);
+   regulator_set_enable(priv->vqmmc_dev, true);
+   }
+#endif
+
+#ifdef CONFIG_PINCTRL
+   switch (mmc->selected_mode) {
+   case MMC_LEGACY:
+   case SD_LEGACY:
+   case MMC_HS:
+   case SD_HS:
+   case MMC_HS_52:
+   case MMC_DDR_52:
+   pinctrl_select_state(dev, "default");
+   break;
+   case UHS_SDR12:
+   case UHS_SDR25:
+   case UHS_SDR50:
+   case UHS_DDR50:
+   case UHS_SDR104:
+   case MMC_HS_200:
+   pinctrl_select_state(dev, "state_uhs");
+   break;
+   default:
+   break;
+   }
+#endif
+}
+
 int matsu_sd_set_ios(struct udevice *dev)
 {
struct matsu_sd_priv *priv = dev_get_priv(dev);
@@ -607,6 +648,7 @@ int matsu_sd_set_ios(struct udevice *dev)
return ret;
matsu_sd_set_ddr_mode(priv, mmc);
matsu_sd_set_clk_rate(priv, mmc);
+   matsu_sd_set_pins(dev);
 
return 0;
 }
@@ -671,9 +713,6 @@ int matsu_sd_probe(struct udevice *dev, u32 quirks)
fdt_addr_t base;
struct clk clk;
int ret;
-#ifdef CONFIG_DM_REGULATOR
-   struct udevice *vqmmc_dev;
-#endif
 
base = devfdt_get_addr(dev);
if (base == FDT_ADDR_T_NONE)
@@ -684,12 +723,7 @@ int matsu_sd_probe(struct udevice *dev, u32 quirks)
return -ENOMEM;
 
 #ifdef CONFIG_DM_REGULATOR
-   ret = device_get_supply_regulator(dev, "vqmmc-supply", _dev);
-   if (!ret) {
-   /* Set the regulator to 3.3V until we support 1.8V modes */
-   regulator_set_value(vqmmc_dev, 330);
-   regulator_set_enable(vqmmc_dev, true);
-   }
+   device_get_supply_regulator(dev, "vqmmc-supply", >vqmmc_dev);
 #endif
 
ret = clk_get_by_index(dev, 0, );
diff --git a/drivers/mmc/matsushita-common.h b/drivers/mmc/matsushita-common.h
index 8c81bbcc4b..b019b72b3e 100644
--- a/drivers/mmc/matsushita-common.h
+++ b/drivers/mmc/matsushita-common.h
@@ -130,6 +130,9 @@ struct matsu_sd_priv {
 #define MATSU_SD_CAP_RCAR_UHS  BIT(7)  /* Renesas RCar UHS/SDR modes */
 #define MATSU_SD_CAP_RCAR  \
(MATSU_SD_CAP_RCAR_GEN2 | MATSU_SD_CAP_RCAR_GEN3)
+#ifdef CONFIG_DM_REGULATOR
+   struct udevice *vqmmc_dev;
+#endif
 };
 
 int matsu_sd_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
-- 
2.16.2

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


[U-Boot] [GIT PULL] Xilinx patches for v2018.05-rc2

2018-04-09 Thread Michal Simek
Hi Tom,

please pull these changes to your tree.

Travis looks good.
https://travis-ci.org/michalsimek/u-boot/builds/364047688

And buildman output too.

Thanks,
Michal


The following changes since commit 5bc0543df3079add8152afa041b887d081d71839:

  treewide: Convert CONFIG_HOSTNAME to a string option (2018-04-08
18:31:09 -0400)

are available in the git repository at:

  git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.05-rc2

for you to fetch changes up to f190eaf002bf1434587d57c726b3dabfabbc8074:

  arm64: zynqmp: Add support for Xilinx zcu111-revA (2018-04-09 12:14:53
+0200)


Xilinx changes for v2018.05-rc2

- Various DT changes and sync with mainline kernel
- Various defconfig updates
- Add SPL init for zcu102 revA
- Add new zynqmp boards zcu100/zcu104/zcu106/zcu111/zc12XX
  and zc1751-dc3
- Net fixes - xlnx,phy-type
- 64bit axi ethernet support
- arasan: Fix nand write issue
- fpga fixes
- Maintainer file updates


Anton Gerasimov (2):
  ARM: dts: zynq: Update dts for Z-turn board
  ARM: dts: zynq: Rename dts for Z-turn board

Heinrich Schuchardt (1):
  MAINTAINERS: ZYNQMP: correct entries

Javier Martinez Canillas (1):
  ARM: dts: zynq: Add generic compatible string for I2C EEPROM

Luca Ceresoli (1):
  arm64: zynqmp: Enable booting to ATF

Michal Simek (38):
  arm: zynq: Handle ENXIO error return value properly
  MAINTAINERS: Fix zynqmp clock driver path
  arm64: zynqmp: Sync alignment with mainline
  arm64: zynqmp: Use maxim prefix for all maxim chips
  arm64: zynqmp: Use i2c-mux instead of i2cswitch instead
  arm64: zynqmp: Sync up license with mainline kernel
  arm64: zynqmp: Remove additional comments from dts files
  arm64: zynqmp: Use keycode from input/input.h
  arm64: zynqmp: Use s/_/-/g in node name for zcu102 rev1.0
  arm64: zynqmp: Fix spi flash partition definition for zc1751 dc2
  arm64: zynqmp: Use atmel prefix instead of at
  arm64: zynqmp: Add eeprom reference to eeprom nodes
  arm64: zynqmp: Enable ttcs for zc1751 dc5
  arm64: zynqmp: Remove u-boot commands from dts files
  arm64: zynqmp: Remove number from clock-generator node name
  arm64: zynqmp: Add silabs prefix to u69 for zcu102
  arm64: zynqmp: Remove double spaces from dts file
  arm: zynq: Remove 0x prefixes from cc108
  arm: zynq: Sync up licenses with mainline kernel
  arm: zynq: Use i2c-mux instead of i2cswitch for pca9548
  arm: zynq: Fix eeprom dt nodes
  arm: zynq: Use fixed partitions for spi flash for zc770 xm010
  clk: zynqmp: Add new compatible string for clock driver
  arm64: zynqmp: Enable pxe and dhcp if commands are enabled
  arm64: zynqmp: Enable ethernet phys for zc1751 dc5
  arm64: zynqmp: Enable mac address randomization for zc1751 dc5
  arm64: zynqmp: Enable Fixed link support
  arm64: zynqmp: Add low level initialization for zcu102-revA
  arm64: zynqmp: Add low level initialization for zc1751
  arm64: zynqmp: Remove power domain description
  arm64: zynqmp: Remove pinctrl settings
  arm64: zynqmp: Get 200MHz clock early for MMC
  arm64: zynqmp: Add support for zcu100 aka Ultra96 board
  arm64: zynqmp: Add support for zc1751 dc3
  arm64: zynqmp: Add support for zc12xx boards
  arm64: zynqmp: Add support for zcu104 customer board
  arm64: zynqmp: Add support for Xilinx zcu106-revA
  arm64: zynqmp: Add support for Xilinx zcu111-revA

Nitin Jain (1):
  fpga: zynqmp: Add support to get the PCAP status for fpga info command

Siva Durga Prasad Paladugu (4):
  fpga: zynqmp: Update zynqmp_load() as per latest xilfpga
  fpga: zynqmp: Fix the nonsecure bitstream loading issue
  fpga: zynq: Add delay after PCFG_PROG_B change
  net: phy: xilinx_phy: Read phytype using property xlnx,phy-type

Srinivas Goud (1):
  arm64: zynqmp: Update sd properties for dc5

Vipul Kumar (2):
  nand: arasan_nfc: Fixed NAND write issue
  axi: ethernet: Added support for 64 bit addressing for axi-ethernet

 MAINTAINERS|   6 +-
 arch/arm/dts/Makefile  |  11 +-
 arch/arm/dts/zynq-cc108.dts|  15 ++-
 arch/arm/dts/zynq-zc702.dts|   9 +-
 arch/arm/dts/zynq-zc706.dts|   9 +-
 arch/arm/dts/zynq-zc770-xm010.dts  |  24 ++--
 arch/arm/dts/zynq-zc770-xm011.dts  |   9 +-
 arch/arm/dts/zynq-zc770-xm012.dts  |  13 +-
 arch/arm/dts/zynq-zc770-xm013.dts  |   5 +-
 arch/arm/dts/zynq-zed.dts  |   5 +-
 arch/arm/dts/{zynq-zturn-myir.dts => zynq-zturn.dts}   |  61 ++---
 arch/arm/dts/zynq-zybo.dts   

Re: [U-Boot] [PATCH] imx: nitrogen6x: Convert Sabrelite to distro boot support

2018-04-09 Thread Gary Bisson
Hi Guillaume,

Thanks for your patch! Switching the upstream nitrogen6x configuration
to distro bootcmd has been in our todo list for some time since we also
use that in our own git repo.

On Fri, Apr 06, 2018 at 12:05:48PM +0200, Guillaume GARDET wrote:
> Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots.
> 
> Signed-off-by: Guillaume GARDET 
> Cc: Troy Kisky 
> Cc: Stefano Babic 
> Cc: Fabio Estevam 
> ---
>  include/configs/nitrogen6x.h | 86 
> ++--
>  1 file changed, 18 insertions(+), 68 deletions(-)
> 
> diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
> index c73cfb7f7e..2e2c499cb6 100644
> --- a/include/configs/nitrogen6x.h
> +++ b/include/configs/nitrogen6x.h
> @@ -102,82 +102,32 @@
>  #define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
>  
>  #if defined(CONFIG_SABRELITE)

Please also switch nitrogen6x to it, not only sabrelite.

> +#define BOOT_TARGET_DEVICES(func) \
> + func(MMC, mmc, 0) \
> + func(MMC, mmc, 1) \
> + func(SATA, sata, 0) \
> + func(USB, usb, 0) \
> + func(PXE, pxe, na) \

That currently doesn't build because CMD_PXE isn't selected in the
sabrelite defconfig.
"include/config_distro_bootcmd.h:319:2: error: expected ‘}’ before
‘BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE’"

Which brings a good point, all the above should depend on the storage
command being present, like done here [1].

> + func(DHCP, dhcp, na)
> +
> +#include 
> +
>  #define CONFIG_EXTRA_ENV_SETTINGS \
> - "script=boot.scr\0" \
> - "uimage=uImage\0" \
>   "console=ttymxc1\0" \
>   "fdt_high=0x\0" \
>   "initrd_high=0x\0" \
> - "fdt_file=imx6q-sabrelite.dtb\0" \
> + "fdtfile=imx6q-sabrelite.dtb\0" \

I wish the default efi_fdtfile would work, Fabio is there any plan to
populate the ${soc} variable like it is done for i.MX7? [2]
Then a small patch in the nitrogen6x.c would set the proper board env
variable.

That way there would be no difference in this header between sabrelite
vs. nitrogen6x.

>   "fdt_addr=0x1800\0" \

Do we need to keep fdt_addr since we define fdt_addr_r below?

> - "boot_fdt=try\0" \
> + "fdt_addr_r=0x1800\0" \
> + "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0"  \
> + "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
> + "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
> + "ramdisk_addr_r=0x1300\0" \
> + "ramdiskaddr=0x1300\0" \
>   "ip_dyn=yes\0" \
>   "usb_pgood_delay=2000\0" \
> - "mmcdevs=0 1\0" \
> - "mmcpart=1\0" \
> - "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
> - "mmcargs=setenv bootargs console=${console},${baudrate} " \
> - "root=${mmcroot}\0" \
> - "loadbootscript=" \
> - "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
> - "bootscript=echo Running bootscript from mmc ...; " \
> - "source\0" \
> - "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
> - "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
> - "mmcboot=echo Booting from mmc ...; " \
> - "run mmcargs; " \
> - "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
> - "if run loadfdt; then " \
> - "bootm ${loadaddr} - ${fdt_addr}; " \
> - "else " \
> - "if test ${boot_fdt} = try; then " \
> - "bootm; " \
> - "else " \
> - "echo WARN: Cannot load the DT; " \
> - "fi; " \
> - "fi; " \
> - "else " \
> - "bootm; " \
> - "fi;\0" \
> - "netargs=setenv bootargs console=${console},${baudrate} " \
> - "root=/dev/nfs " \
> - "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
> - "netboot=echo Booting from net ...; " \
> - "run netargs; " \
> - "if test ${ip_dyn} = yes; then " \
> - "setenv get_cmd dhcp; " \
> - "else " \
> - "setenv get_cmd tftp; " \
> - "fi; " \
> - "${get_cmd} ${uimage}; " \
> - "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
> - "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
> - "bootm ${loadaddr} - ${fdt_addr}; " \
> - "else " \
> - "if test ${boot_fdt} = try; then " \
> - "bootm; " \
> - "else " \
> - "echo WARN: Cannot load the DT; " \
> - "fi; " \
> - "fi; " \
> - "else " \
> - "bootm; " \
> - "fi;\0"
> 

Re: [U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Anand Moon
Hi Guillaume,

On 9 April 2018 at 21:59, Guillaume Gardet  wrote:
>
>
> Le 09/04/2018 à 18:02, Guillaume Gardet a écrit :
>>
>>
>>
>> Le 09/04/2018 à 17:18, Jean-Jacques Hiblot a écrit :
>>>
>>>
>>>
>>> On 09/04/2018 16:46, Guillaume Gardet wrote:



 Le 09/04/2018 à 16:21, Jean-Jacques Hiblot a écrit :
>
>
>
> On 09/04/2018 16:03, Guillaume Gardet wrote:
>>
>>
>>
>> Le 09/04/2018 à 15:58, Jean-Jacques Hiblot a écrit :
>>>
>>>
>>>
>>> On 09/04/2018 14:02, Guillaume Gardet wrote:

 Hi Jaehoon,

 There are problems with SD card access on Samsung Chromebook (snow)
 with latest master (and also 2018.05-rc1 and 2018.03).

 eMMC is ok, but SD card access leads to 'unable to select a mode'
 problem. If I disable HS mode, I can access the SD card without 
 problem:

 
 diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
 index 23f642980bf..28f4fa0f213 100644
 --- a/drivers/mmc/dw_mmc.c
 +++ b/drivers/mmc/dw_mmc.c
 @@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg,
 struct dwmci_host *host,
  cfg->host_caps |= MMC_MODE_4BIT;
  cfg->host_caps &= ~MMC_MODE_8BIT;
  }
 -cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
 +/* Temp workaround for Chromebook snow to avoid the 'unable to
 select a mode' error */
 +// cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

  cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
  }

 

 Once we try to select HS mode, all access to SD card result in
 failure, even when trying to setup a lower frequency mode, including SD
 legacy at 25 MHz.

 Any idea what is going? Maybe you have fixes pending?
>>>
>>>
>>> Can try with MMC_MODE_HS | MMC_MODE_HS_52MHz but with a lower
>>> max-frequency (<25MHz) ? It would be interesting to know if it could 
>>> come
>>> from a frequency limitation.
>>
>>
>> I already tried to change SD_HS freq (in mmc_mode2freq) from 5000
>> to 2500 with no difference.
>>
>>> Is there some pad configuration to do when using higher frequency?
>>
>>
>> I do not think so.
>
> Can you enable the debug output and post a log ?


 Here is the log from u-boot built from u-boot-mmc (latest commit:
 21c2ac32b845)
 Yes, I have no serial, so I retyped the messages, so I hope there is no
 typo:
 **
 selecting mode MMC legacy (freq : 0 MHz)
 selecting mode MMC legacy (freq : 25 MHz)
 sd card: widths [4, 1] modes [SD Legacy, SD High SPeed (50MHz)]
 host: widths [4, 1] modes [MMC legacy, SD Legacy, MMC High Speed
 (26MHz), SD High Speed (50MHz), MMC High Speed (52MHz), MMC DDR52 (52MHz)]
 trying mode SD High Speed (50MHz) width 4 (at 50 MHz)
 selecting mode SD High Speed (50 MHz) (freq : 50 MHz)
 unable to read ssr
 selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
 trying mode SD High Speed (50MHz) width 1 (at 50 MHz)
>>>
>>> So it fails either in sd_select_bus_width() or sd_set_card_speed()
>>> Can you try to limit the bus width to 1 ? Does it fail also at 50 MHz ?
>>
>>
>> Yes, it fails too.
>
>
> If I disable sd_set_card_speed, then it is working fine.
>
> Guillaume
>

Thanks for your investigation on this issue,
I feel their is some clk initialization for mmc for exynos platform is missing.

Best Regards
-Anand

>>
>> Guillaume
>>
>>>
 selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
 trying mode SD Legacy (25MHz) width 4 (at 25 MHz)
 selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
 trying mode SD Legacy (25MHz) width 1 (at 25 MHz)
 selecting mode SD Legacy (25 MHz) (freq : 25 MHz)
 unable to select a mode
 mmc_init: -524, time 127
 ** Bad device mmc 1 **
 **

 Note that eMMC (on mmc 0) is working fine with MMC DDR52 (52MHz).

 Guillaume

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


[U-Boot] [PATCH v1 1/2] stm32mp: regulator: add SoC pwr regulator support

2018-04-09 Thread Patrice Chotard
From: Patrick Delaunay 

This driver binds and manages the following regulator of
SoC's PWR block :
  - reg11
  - reg18
  - usb33

Signed-off-by: Patrick Delaunay 
Signed-off-by: Patrice Chotard 
---

 arch/arm/mach-stm32mp/Makefile |   1 +
 arch/arm/mach-stm32mp/include/mach/stm32.h |   1 +
 arch/arm/mach-stm32mp/pwr_regulator.c  | 275 +
 arch/arm/mach-stm32mp/syscon.c |   2 +
 4 files changed, 279 insertions(+)
 create mode 100644 arch/arm/mach-stm32mp/pwr_regulator.c

diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
index a495c53be8ca..83e8e64b7e5a 100644
--- a/arch/arm/mach-stm32mp/Makefile
+++ b/arch/arm/mach-stm32mp/Makefile
@@ -9,3 +9,4 @@ obj-y += dram_init.o
 obj-y += syscon.o
 
 obj-$(CONFIG_SPL_BUILD) += spl.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR) += pwr_regulator.o
diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h 
b/arch/arm/mach-stm32mp/include/mach/stm32.h
index c7a27894c451..91dc58d82df2 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
@@ -29,6 +29,7 @@
 enum {
STM32MP_SYSCON_UNKNOWN,
STM32MP_SYSCON_STGEN,
+   STM32MP_SYSCON_PWR,
 };
 
 /*
diff --git a/arch/arm/mach-stm32mp/pwr_regulator.c 
b/arch/arm/mach-stm32mp/pwr_regulator.c
new file mode 100644
index ..187ffc092ce7
--- /dev/null
+++ b/arch/arm/mach-stm32mp/pwr_regulator.c
@@ -0,0 +1,275 @@
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ *
+ * SPDX-License-Identifier:GPL-2.0+BSD-3-Clause
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define STM32MP_PWR_CR3 0xc
+#define STM32MP_PWR_CR3_USB33DEN BIT(24)
+#define STM32MP_PWR_CR3_USB33RDY BIT(26)
+#define STM32MP_PWR_CR3_REG18DEN BIT(28)
+#define STM32MP_PWR_CR3_REG18RDY BIT(29)
+#define STM32MP_PWR_CR3_REG11DEN BIT(30)
+#define STM32MP_PWR_CR3_REG11RDY BIT(31)
+
+struct stm32mp_pwr_reg_info {
+   u32 enable;
+   u32 ready;
+   char *name;
+};
+
+struct stm32mp_pwr_priv {
+   struct regmap *regmap;
+};
+
+static int stm32mp_pwr_write(struct udevice *dev, u8 reg,
+const u8 *buff, int len)
+{
+   struct stm32mp_pwr_priv *priv = dev_get_priv(dev);
+   u32 val = *(u32 *)buff;
+
+   if (len != 4)
+   return -EINVAL;
+
+   return regmap_write(priv->regmap, STM32MP_PWR_CR3, val);
+}
+
+static int stm32mp_pwr_read(struct udevice *dev, uint reg, uint8_t *buff,
+   int len)
+{
+   struct stm32mp_pwr_priv *priv = dev_get_priv(dev);
+
+   if (len != 4)
+   return -EINVAL;
+
+   return regmap_read(priv->regmap, STM32MP_PWR_CR3, (u32 *)buff);
+}
+
+static int stm32mp_pwr_ofdata_to_platdata(struct udevice *dev)
+{
+   struct stm32mp_pwr_priv *priv = dev_get_priv(dev);
+   struct regmap *regmap;
+
+   regmap = syscon_get_regmap_by_driver_data(STM32MP_SYSCON_PWR);
+   if (IS_ERR(regmap)) {
+   pr_err("%s: unable to find regmap (%ld)\n", __func__,
+  PTR_ERR(regmap));
+   return PTR_ERR(regmap);
+   }
+   priv->regmap = regmap;
+
+   return 0;
+}
+
+static const struct pmic_child_info pwr_children_info[] = {
+   { .prefix = "reg", .driver = "stm32mp_pwr_regulator"},
+   { .prefix = "usb", .driver = "stm32mp_pwr_regulator"},
+   { },
+};
+
+static int stm32mp_pwr_bind(struct udevice *dev)
+{
+   int children;
+
+   children = pmic_bind_children(dev, dev->node, pwr_children_info);
+   if (!children)
+   dev_dbg(dev, "no child found\n");
+
+   return 0;
+}
+
+static struct dm_pmic_ops stm32mp_pwr_ops = {
+   .read = stm32mp_pwr_read,
+   .write = stm32mp_pwr_write,
+};
+
+static const struct udevice_id stm32mp_pwr_ids[] = {
+   { .compatible = "st,stm32mp1,pwr-reg" },
+   { }
+};
+
+U_BOOT_DRIVER(stm32mp_pwr_pmic) = {
+   .name = "stm32mp_pwr_pmic",
+   .id = UCLASS_PMIC,
+   .of_match = stm32mp_pwr_ids,
+   .bind = stm32mp_pwr_bind,
+   .ops = _pwr_ops,
+   .ofdata_to_platdata = stm32mp_pwr_ofdata_to_platdata,
+   .priv_auto_alloc_size = sizeof(struct stm32mp_pwr_priv),
+};
+
+static const struct stm32mp_pwr_reg_info stm32mp_pwr_reg11 = {
+   .enable = STM32MP_PWR_CR3_REG11DEN,
+   .ready = STM32MP_PWR_CR3_REG11RDY,
+   .name = "reg11"
+};
+
+static const struct stm32mp_pwr_reg_info stm32mp_pwr_reg18 = {
+   .enable = STM32MP_PWR_CR3_REG18DEN,
+   .ready = STM32MP_PWR_CR3_REG18RDY,
+   .name = "reg18"
+};
+
+static const struct stm32mp_pwr_reg_info stm32mp_pwr_usb33 = {
+   .enable = STM32MP_PWR_CR3_USB33DEN,
+   .ready = STM32MP_PWR_CR3_USB33RDY,
+   .name = "usb33"
+};
+
+static const struct stm32mp_pwr_reg_info *stm32mp_pwr_reg_infos[] = {
+   _pwr_reg11,
+   _pwr_reg18,
+ 

[U-Boot] [PATCH v2 5/6] ARM: mvebu: a38x: restore support for setting timing

2018-04-09 Thread Chris Packham
This restores support for configuring the timing mode based on the
ddr_topology. This was originally implemented in commit 90bcc3d38d2b
("driver/ddr: Add support for setting timing in hws_topology_map") but
was removed as part of the upstream sync.

Signed-off-by: Chris Packham 
---

Changes in v2: New

 board/CZ.NIC/turris_omnia/turris_omnia.c  | 6 --
 board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 3 ++-
 board/Marvell/db-88f6820-gp/db-88f6820-gp.c   | 3 ++-
 board/gdsys/a38x/controlcenterdc.c| 3 ++-
 board/solidrun/clearfog/clearfog.c| 3 ++-
 drivers/ddr/marvell/a38x/ddr3_training.c  | 8 
 drivers/ddr/marvell/a38x/ddr_topology_def.h   | 3 +++
 drivers/ddr/marvell/a38x/mv_ddr_plat.c| 5 -
 drivers/ddr/marvell/a38x/mv_ddr_topology.h| 6 ++
 9 files changed, 29 insertions(+), 11 deletions(-)

diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c 
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 9477a802acde..3535e30e3ed9 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -214,7 +214,8 @@ static struct mv_ddr_topology_map board_topology_map_1g = {
MV_DDR_DIE_CAP_4GBIT,   /* mem_size */
DDR_FREQ_800,   /* frequency */
0, 0,   /* cas_wl cas_l */
-   MV_DDR_TEMP_NORMAL} },  /* temperature */
+   MV_DDR_TEMP_NORMAL, /* temperature */
+   MV_DDR_TIM_2T} },   /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
{ {0} },/* raw spd data */
@@ -235,7 +236,8 @@ static struct mv_ddr_topology_map board_topology_map_2g = {
MV_DDR_DIE_CAP_8GBIT,   /* mem_size */
DDR_FREQ_800,   /* frequency */
0, 0,   /* cas_wl cas_l */
-   MV_DDR_TEMP_NORMAL} },  /* temperature */
+   MV_DDR_TEMP_NORMAL, /* temperature */
+   MV_DDR_TIM_2T} },   /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
{ {0} },/* raw spd data */
diff --git a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c 
b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
index 2a092cb80418..aeb617172163 100644
--- a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
+++ b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
@@ -70,7 +70,8 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_DIE_CAP_2GBIT,   /* mem_size */
DDR_FREQ_800,   /* frequency */
0, 0,   /* cas_wl cas_l */
-   MV_DDR_TEMP_LOW} }, /* temperature */
+   MV_DDR_TEMP_LOW,/* temperature */
+   MV_DDR_TIM_DEFAULT} },  /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
{ {0} },/* raw spd data */
diff --git a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c 
b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
index e3b6f2d8a7e6..073b5388080a 100644
--- a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
+++ b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
@@ -91,7 +91,8 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_DIE_CAP_4GBIT,   /* mem_size */
DDR_FREQ_800,   /* frequency */
0, 0,   /* cas_wl cas_l */
-   MV_DDR_TEMP_LOW} }, /* temperature */
+   MV_DDR_TEMP_LOW,/* temperature */
+   MV_DDR_TIM_DEFAULT} },  /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
{ {0} },/* raw spd data */
diff --git a/board/gdsys/a38x/controlcenterdc.c 
b/board/gdsys/a38x/controlcenterdc.c
index 1b3b881c3996..0ad6825f3057 100644
--- a/board/gdsys/a38x/controlcenterdc.c
+++ b/board/gdsys/a38x/controlcenterdc.c
@@ -54,7 +54,8 @@ static struct mv_ddr_topology_map ddr_topology_map = {
MV_DDR_DIE_CAP_4GBIT,   /* mem_size */
DDR_FREQ_533,   /* frequency */
0, 0,   /* cas_wl cas_l */
-   MV_DDR_TEMP_LOW} }, /* temperature */
+   MV_DDR_TEMP_LOW,/* temperature */
+   MV_DDR_TIM_DEFAULT} },  /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
{ {0} },/* raw spd data */
diff --git a/board/solidrun/clearfog/clearfog.c 
b/board/solidrun/clearfog/clearfog.c
index 

[U-Boot] [PATCH] sunxi: improve SATAPWR and MACPWR

2018-04-09 Thread Mylène Josserand
This commit adds a dependency on SATA for SATAPWR because
if we do not have SATA enabled, we will not have this pin
configured.

By default, these two configs (SATAPWR and MACPWR) are equals
to "". Because of that, they are always defined so we need to
check if the variables are not empty to perform the gpio request.
Otherwise, if SATA is enabled but SATAPWR is not configured, we will have
a mdelay of 500ms for nothing (because no pin requested).

Signed-off-by: Mylène Josserand 
---
 arch/arm/mach-sunxi/Kconfig |  1 +
 board/sunxi/board.c | 21 +
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index b868f0e350..7d36719700 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -911,6 +911,7 @@ endchoice
 config SATAPWR
string "SATA power pin"
default ""
+   depends on SATA
help
  Set the pins used to power the SATA. This takes a string in the
  format understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 322dd9e23a..5b080607c1 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -230,16 +230,21 @@ int board_init(void)
return ret;
 
 #ifdef CONFIG_SATAPWR
-   satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
-   gpio_request(satapwr_pin, "satapwr");
-   gpio_direction_output(satapwr_pin, 1);
-   /* Give attached sata device time to power-up to avoid link timeouts */
-   mdelay(500);
+   if (strlen(CONFIG_SATAPWR)) {
+   satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
+   gpio_request(satapwr_pin, "satapwr");
+   gpio_direction_output(satapwr_pin, 1);
+   /* Give attached sata device time to power-up to avoid link 
timeouts */
+   mdelay(500);
+   }
 #endif
+
 #ifdef CONFIG_MACPWR
-   macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
-   gpio_request(macpwr_pin, "macpwr");
-   gpio_direction_output(macpwr_pin, 1);
+   if (strlen(CONFIG_MACPWR)) {
+   macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
+   gpio_request(macpwr_pin, "macpwr");
+   gpio_direction_output(macpwr_pin, 1);
+   }
 #endif
 
 #ifdef CONFIG_DM_I2C
-- 
2.11.0

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


[U-Boot] [PATCH v2 6/6] ARM: mvebu: a38x: use non-zero size for ddr scrubbing

2018-04-09 Thread Chris Packham
From: Chris Packham 

Make ddr3_calc_mem_cs_size() global scope and use it in
ddr3_new_tip_ecc_scrub to correctly initialize all of DDR memory.

Signed-off-by: Chris Packham 
---
This has been reported upstream at
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/6 

Changes in v2: New

 drivers/ddr/marvell/a38x/mv_ddr_plat.c | 2 +-
 drivers/ddr/marvell/a38x/mv_ddr_plat.h | 1 +
 drivers/ddr/marvell/a38x/xor.c | 3 +++
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/ddr/marvell/a38x/mv_ddr_plat.c 
b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
index 1ab72e36189e..5a527b67a84d 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_plat.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
@@ -996,7 +996,7 @@ static u32 ddr3_get_device_size(u32 cs)
}
 }
 
-static int ddr3_calc_mem_cs_size(u32 cs, uint64_t *cs_size)
+int ddr3_calc_mem_cs_size(u32 cs, uint64_t *cs_size)
 {
u32 cs_mem_size;
 
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_plat.h 
b/drivers/ddr/marvell/a38x/mv_ddr_plat.h
index 73e54c4b735c..8ea3c8b5c48d 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_plat.h
+++ b/drivers/ddr/marvell/a38x/mv_ddr_plat.h
@@ -233,4 +233,5 @@ u32 mv_ddr_dm_pad_get(void);
 int mv_ddr_pre_training_fixup(void);
 int mv_ddr_post_training_fixup(void);
 int mv_ddr_manual_cal_do(void);
+int ddr3_calc_mem_cs_size(u32 cs, uint64_t *cs_size);
 #endif /* _MV_DDR_PLAT_H */
diff --git a/drivers/ddr/marvell/a38x/xor.c b/drivers/ddr/marvell/a38x/xor.c
index 368432165fa3..d2f90449d5ed 100644
--- a/drivers/ddr/marvell/a38x/xor.c
+++ b/drivers/ddr/marvell/a38x/xor.c
@@ -348,6 +348,9 @@ void ddr3_new_tip_ecc_scrub(void)
for (cs_c = 0; cs_c < max_cs; cs_c++)
cs_ena |= 1 << cs_c;
 
+   /* assume that all CS have same size */
+   ddr3_calc_mem_cs_size(0, _mem_size);
+
mv_sys_xor_init(max_cs, cs_ena, cs_mem_size, 0);
total_mem_size = max_cs * cs_mem_size;
mv_xor_mem_init(0, 0, total_mem_size, 0xdeadbeef, 0xdeadbeef);
-- 
2.16.2

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


[U-Boot] [PATCH v1 0/2] Add STM32MP157 SoC Power regulator

2018-04-09 Thread Patrice Chotard

This series :
   _ adds stmpu157 SoC power regulator driver
   _ populates DT with SoC power regulator entry


Patrice Chotard (1):
  ARM: dts: stm32mp157: Add SoC pwr regulator entry

Patrick Delaunay (1):
  stm32mp: regulator: add SoC pwr regulator support

 arch/arm/dts/stm32mp157.dtsi   |  33 
 arch/arm/mach-stm32mp/Makefile |   1 +
 arch/arm/mach-stm32mp/include/mach/stm32.h |   1 +
 arch/arm/mach-stm32mp/pwr_regulator.c  | 275 +
 arch/arm/mach-stm32mp/syscon.c |   2 +
 5 files changed, 312 insertions(+)
 create mode 100644 arch/arm/mach-stm32mp/pwr_regulator.c

-- 
1.9.1

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


[U-Boot] [PATCH] mmc: fix check of returned value of sd_read_ssr function

2018-04-09 Thread Guillaume GARDET
sd_read_ssr returns 0 if it succeed.

Signed-off-by: Guillaume GARDET 
Cc: Jaehoon Chung 

---
 drivers/mmc/mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index c930893300..92ea78b8af 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1689,7 +1689,7 @@ static int sd_select_mode_and_width(struct mmc *mmc, uint 
card_caps)
 
 #if CONFIG_IS_ENABLED(MMC_WRITE)
err = sd_read_ssr(mmc);
-   if (!err)
+   if (err)
pr_warn("unable to read ssr\n");
 #endif
if (!err)
-- 
2.13.6

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


[U-Boot] [PATCH v2 2/6] ARM: mvebu: a38x: move sys_env_device_rev_get

2018-04-09 Thread Chris Packham
Move sys_env_device_rev_get() from the ddr training code to
sys_env_lib.c (which currently resides with the serdes code). This
brings sys_env_device_rev_get() into line with sys_env_device_id_get()
and sys_env_model_get().

Signed-off-by: Chris Packham 
---

Changes in v2:
- remove unused #include

 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c | 26 --
 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  1 -
 drivers/ddr/marvell/a38x/ddr3_init.c  | 24 
 3 files changed, 24 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c 
b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
index cc3e5e23c0dd..ec2d89a66b0b 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
+++ b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
@@ -13,8 +13,6 @@
 #include "seq_exec.h"
 #include "sys_env_lib.h"
 
-#include "../../../drivers/ddr/marvell/a38x/ddr3_a38x.h"
-
 #ifdef CONFIG_ARMADA_38X
 enum unit_id sys_env_soc_unit_nums[MAX_UNITS_ID][MAX_DEV_ID_NUM] = {
 /* 68206810 6811 6828 */
@@ -235,3 +233,27 @@ u32 sys_env_device_id_get(void)
 
return g_dev_id;
 }
+
+/*
+ * sys_env_device_rev_get - Get Marvell controller device revision number
+ *
+ * DESCRIPTION:
+ *   This function returns 8bit describing the device revision as defined
+ *   Revision ID Register.
+ *
+ * INPUT:
+ *   None.
+ *
+ * OUTPUT:
+ *   None.
+ *
+ * RETURN:
+ *   8bit desscribing Marvell controller revision number
+ */
+u8 sys_env_device_rev_get(void)
+{
+   u32 value;
+
+   value = reg_read(DEV_VERSION_ID_REG);
+   return (value & (REVISON_ID_MASK)) >> REVISON_ID_OFFS;
+}
diff --git a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h 
b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
index a413c51043ee..15626cbca7d5 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
+++ b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
@@ -8,7 +8,6 @@
 #define _SYS_ENV_LIB_H
 
 #include "../../../drivers/ddr/marvell/a38x/ddr3_init.h"
-#include "../../../drivers/ddr/marvell/a38x/ddr3_hws_hw_training.h"
 
 /* Serdes definitions */
 #define COMMON_PHY_BASE_ADDR   0x18300
diff --git a/drivers/ddr/marvell/a38x/ddr3_init.c 
b/drivers/ddr/marvell/a38x/ddr3_init.c
index 55baad498ae5..032c4d54f359 100644
--- a/drivers/ddr/marvell/a38x/ddr3_init.c
+++ b/drivers/ddr/marvell/a38x/ddr3_init.c
@@ -108,30 +108,6 @@ static int ddr3_hws_tune_training_params(u8 dev_num);
 /* A39x revisions */
 #define MV_88F69XX_Z1_ID   0x2
 
-/*
- * sys_env_device_rev_get - Get Marvell controller device revision number
- *
- * DESCRIPTION:
- *   This function returns 8bit describing the device revision as defined
- *   Revision ID Register.
- *
- * INPUT:
- *   None.
- *
- * OUTPUT:
- *   None.
- *
- * RETURN:
- *   8bit desscribing Marvell controller revision number
- */
-u8 sys_env_device_rev_get(void)
-{
-   u32 value;
-
-   value = reg_read(DEV_VERSION_ID_REG);
-   return (value & (REVISON_ID_MASK)) >> REVISON_ID_OFFS;
-}
-
 /*
  * sys_env_dlb_config_ptr_get
  *
-- 
2.16.2

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


[U-Boot] [PATCH v2 1/6] ARM: mvebu: a38x: move definition of PEX_CFG_DIRECT_ACCESS

2018-04-09 Thread Chris Packham
PEX_CFG_DIRECT_ACCESS was defined in ddr3_hws_hw_training_def.h despite
only being used in the serdes code. Move this definition to ctrl_pex.h
where all the other PEX defines are. Also remove the duplicate
definition of PEX_DEVICE_AND_VENDOR_ID which is already defined in
ctrl_pex.h.

Signed-off-by: Chris Packham 
---

Changes in v2: None

 arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h  | 1 +
 drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h 
b/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h
index ca8a4d206a36..d6f0d4fcd381 100644
--- a/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h
+++ b/arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h
@@ -47,6 +47,7 @@
 
 /* Controller revision info */
 #define PEX_DEVICE_AND_VENDOR_ID   0x000
+#define PEX_CFG_DIRECT_ACCESS(if, reg) (PEX_IF_REGS_BASE(if) + (reg))
 
 /* PCI Express Configuration Address Register */
 #define PXCAR_REG_NUM_OFFS 2
diff --git a/drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h 
b/drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h
index 06d0ab10aa2a..bca0af89a72d 100644
--- a/drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h
+++ b/drivers/ddr/marvell/a38x/ddr3_hws_hw_training_def.h
@@ -422,8 +422,6 @@
 
 /* Power Management Clock Gating Control Register */
 #define POWER_MNG_CTRL_REG 0x18220
-#define PEX_DEVICE_AND_VENDOR_ID   0x000
-#define PEX_CFG_DIRECT_ACCESS(if, reg) (PEX_IF_REGS_BASE(if) + (reg))
 #define PMC_PEXSTOPCLOCK_OFFS(p)   ((p) < 8 ? (5 + (p)) : (18 + (p)))
 #define PMC_PEXSTOPCLOCK_MASK(p)   (1 << PMC_PEXSTOPCLOCK_OFFS(p))
 #define PMC_PEXSTOPCLOCK_EN(p) (1 << PMC_PEXSTOPCLOCK_OFFS(p))
-- 
2.16.2

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


[U-Boot] [PATCH v2 0/6] ARM: mvebu: a38x: updates to ddr training code

2018-04-09 Thread Chris Packham
This series updates the ddr training code in u-boot with the latest
publicly available version from Marvell which can be found at
https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git
(mv_ddr-armada-17.10 branch).

I've tried to make the delta as small as possible without breaking
bisect-ability.

The first 2 patches have already been sent as
http://patchwork.ozlabs.org/patch/894866/ and
http://patchwork.ozlabs.org/patch/894865/

The bulk of the changes are in patch 4. Naturally this doesn't pass
checkpatch.pl but I'm erring on the side of being able to diff with the
upstream source. Also due to it's size this patch may not make it to the
mailing list so the full series can be retrieved from the mv-ddr branch
of https://github.com/cpackham/u-boot.git.

I've tested this series on the db-88f6820-amc board and on a custom
board that is not upstream (yet). I've also build tested the other a38x
boards. More testing on actual hardware would be greatly appreciated.

Changes in v2:
- remove unused #include

Chris Packham (6):
  ARM: mvebu: a38x: move definition of PEX_CFG_DIRECT_ACCESS
  ARM: mvebu: a38x: move sys_env_device_rev_get
  ARM: mvebu: a38x: remove some unused code
  ARM: mvebu: a38x: sync ddr training code with upstream
  ARM: mvebu: a38x: restore support for setting timing
  ARM: mvebu: a38x: use non-zero size for ddr scrubbing

 arch/arm/mach-mvebu/serdes/a38x/ctrl_pex.h |1 +
 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c  |   26 +-
 arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h  |1 -
 board/CZ.NIC/turris_omnia/turris_omnia.c   |   38 +-
 board/Marvell/db-88f6820-amc/db-88f6820-amc.c  |   21 +-
 board/Marvell/db-88f6820-gp/db-88f6820-gp.c|   21 +-
 board/gdsys/a38x/controlcenterdc.c |   22 +-
 board/solidrun/clearfog/clearfog.c |   21 +-
 drivers/ddr/marvell/a38x/Makefile  |   10 +-
 drivers/ddr/marvell/a38x/ddr3_a38x.c   |  737 --
 drivers/ddr/marvell/a38x/ddr3_a38x.h   |   93 --
 drivers/ddr/marvell/a38x/ddr3_a38x_mc_static.h |  226 ---
 drivers/ddr/marvell/a38x/ddr3_a38x_topology.h  |   22 -
 drivers/ddr/marvell/a38x/ddr3_a38x_training.c  |   40 -
 drivers/ddr/marvell/a38x/ddr3_debug.c  |  742 ++
 drivers/ddr/marvell/a38x/ddr3_hws_hw_training.c|  148 --
 drivers/ddr/marvell/a38x/ddr3_hws_hw_training.h|   49 -
 .../ddr/marvell/a38x/ddr3_hws_hw_training_def.h|  464 --
 drivers/ddr/marvell/a38x/ddr3_hws_sil_training.h   |   17 -
 drivers/ddr/marvell/a38x/ddr3_init.c   |  798 ++-
 drivers/ddr/marvell/a38x/ddr3_init.h   |  300 +---
 drivers/ddr/marvell/a38x/ddr3_logging_def.h|   10 +-
 drivers/ddr/marvell/a38x/ddr3_patterns_64bit.h |1 +
 drivers/ddr/marvell/a38x/ddr3_topology_def.h   |6 +-
 drivers/ddr/marvell/a38x/ddr3_training.c   | 1491 +++-
 drivers/ddr/marvell/a38x/ddr3_training_bist.c  |  548 +--
 .../marvell/a38x/ddr3_training_centralization.c|  108 +-
 drivers/ddr/marvell/a38x/ddr3_training_db.c|  267 +++-
 drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c   |   98 +-
 drivers/ddr/marvell/a38x/ddr3_training_ip.h|   19 +-
 drivers/ddr/marvell/a38x/ddr3_training_ip_bist.h   |6 +-
 drivers/ddr/marvell/a38x/ddr3_training_ip_db.h |   71 +-
 drivers/ddr/marvell/a38x/ddr3_training_ip_def.h|   34 +-
 drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c | 1134 +--
 drivers/ddr/marvell/a38x/ddr3_training_ip_engine.h |9 +-
 drivers/ddr/marvell/a38x/ddr3_training_ip_flow.h   |  305 +---
 drivers/ddr/marvell/a38x/ddr3_training_ip_prv_if.h |   17 +-
 drivers/ddr/marvell/a38x/ddr3_training_ip_static.h |   31 -
 drivers/ddr/marvell/a38x/ddr3_training_leveling.c  | 1347 ++
 drivers/ddr/marvell/a38x/ddr3_training_leveling.h  |2 +-
 drivers/ddr/marvell/a38x/ddr3_training_pbs.c   |  201 +--
 drivers/ddr/marvell/a38x/ddr3_training_static.c|  539 ---
 drivers/ddr/marvell/a38x/ddr_ml_wrapper.h  |  149 ++
 drivers/ddr/marvell/a38x/ddr_topology_def.h|   84 +-
 drivers/ddr/marvell/a38x/mv_ddr_build_message.c|1 +
 drivers/ddr/marvell/a38x/mv_ddr_common.c   |   48 +
 drivers/ddr/marvell/a38x/mv_ddr_common.h   |   21 +
 drivers/ddr/marvell/a38x/mv_ddr_plat.c | 1451 +++
 drivers/ddr/marvell/a38x/mv_ddr_plat.h |  237 
 drivers/ddr/marvell/a38x/mv_ddr_regs.h |  447 ++
 drivers/ddr/marvell/a38x/mv_ddr_spd.c  |  378 +
 drivers/ddr/marvell/a38x/mv_ddr_spd.h  |  290 
 drivers/ddr/marvell/a38x/mv_ddr_sys_env_lib.c  |  103 ++
 drivers/ddr/marvell/a38x/mv_ddr_sys_env_lib.h  |  118 ++
 drivers/ddr/marvell/a38x/mv_ddr_topology.c |  198 +++
 drivers/ddr/marvell/a38x/mv_ddr_topology.h |  130 ++
 drivers/ddr/marvell/a38x/seq_exec.h 

[U-Boot] [PATCH v1 2/2] ARM: dts: stm32mp157: Add SoC pwr regulator entry

2018-04-09 Thread Patrice Chotard
Add SoC power regulator entry for reg11, reg18 and usb33
regulator.

Signed-off-by: Patrice Chotard 
---

 arch/arm/dts/stm32mp157.dtsi | 33 +
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/dts/stm32mp157.dtsi b/arch/arm/dts/stm32mp157.dtsi
index b84899a1ea94..a798144de2b7 100644
--- a/arch/arm/dts/stm32mp157.dtsi
+++ b/arch/arm/dts/stm32mp157.dtsi
@@ -123,6 +123,39 @@
};
};
 
+   pwr: pwr@50001000 {
+   compatible = "st,stm32mp1-pwr", "st,stm32-pwr", 
"syscon", "simple-mfd";
+   reg = <0x50001000 0x400>;
+   system-power-controller;
+   interrupts = ;
+   st,sysrcc = <>;
+   clocks = <_clk PLL2_R>;
+   clock-names = "phyclk";
+
+   pwr-regulators@c {
+   compatible = "st,stm32mp1,pwr-reg";
+   st,tzcr = < 0x0 0x1>;
+
+   reg11: reg11 {
+   regulator-name = "reg11";
+   regulator-min-microvolt = <110>;
+   regulator-max-microvolt = <110>;
+   };
+
+   reg18: reg18 {
+   regulator-name = "reg18";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   };
+
+   usb33: usb33 {
+   regulator-name = "usb33";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+   };
+   };
+
pinctrl: pin-controller {
compatible = "st,stm32mp157-pinctrl";
#address-cells = <1>;
-- 
1.9.1

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


Re: [U-Boot] Question regarding cpu_get_count(..)

2018-04-09 Thread Christian Gmeiner
2018-04-09 10:26 GMT+02:00 Bin Meng :
> Hi Christian,
>
> On Mon, Apr 9, 2018 at 3:52 PM, Christian Gmeiner
>  wrote:
>> Hi Bin
>>
>> 2018-04-06 10:30 GMT+02:00 Christian Gmeiner :
>>> Hi Bin
>>>
>>> 2018-04-06 9:47 GMT+02:00 Bin Meng :
 Hi Christian,

 On Fri, Apr 6, 2018 at 2:55 PM, Christian Gmeiner
  wrote:
> Hi
>
> I tried my luck on the u-boot irc channel but nobody cared so I am
> asking this here again.
> Does cpu_get_count(..) return the number of physical CPUs or the
> number of logical CPUs?
>
> I am currently preparing a patch set which adds
> arch/x86/cpu/queensbay/cpu.c and there I need
> to specify a struct cpu_ops with a function called get_count(). But
> what must I return (physical vs. logical CPU count)?
>

 It's logical CPUs, say you have one physical CPU, each with
 dual-threads, so get_count() returns 2.

>>>
>>> Good to know. I am looking into an issue where vxworks 7 intel gen is not 
>>> able
>>> to detect the correct amount of physical and logical CPUs (on a blob 
>>> UEFI-Bios).
>>> I compared the new platform with an older queensbay based one the there are 
>>> some
>>> discrepancies. As vx7 makes use of a handful of BIOS tables I thought I 
>>> start at
>>> the root (get_count()) and move up. So as a result of this that means that 
>>> the
>>> MP table has one "Processor Entry" per logical CPU - or? I tired to get that
>>> information for the spec but failed.
>>>
 But Intel CrownBay already supports SMP in U-Boot. What patch are you
 working on?
>>>
>>> I am out of office today and do not have access to my wip git rep :(
>>> But I needed
>>> to set some speed frequency registers.. but can tell you more on Monday.
>>>
>>
>> Okay.. yeah I need to configure speed: https://hastebin.com/toqihobali.cpp
>>
>> So the end result is to get all BIOS tables standard conform and vx7 should
>> be happy - I hope.
>>
>
> I am not sure I understand the mods here. Are you saying that vx7 is
> not happy due to U-Boot is missing some core speed register
> configuration?
>

No - I am happy with the code basis as is. In order to fix some
performance issues
regarding cache I ended adding cpu.c. That was some months ago.

Now some guys and me need to bring up vx7 smp on a handful of targets and we are
seeing some wired vxCpuIdTopology() outputs on different targets.
Looks like u-boot
is okay but a vendor binary bios has problems

https://hastebin.com/qojenuqoge.js

To sum it up:
* cpu_get_count(..) needs to return the number of logical CPUs.
* The generated MP-Table has one "Processor Entry" per logical CPU

I will prepare a proper patch for the cpu.c addition during the week.
-- 
greets
--
Christian Gmeiner, MSc

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


[U-Boot] [PATCH v2 3/6] ARM: mvebu: a38x: remove some unused code

2018-04-09 Thread Chris Packham
No in-tree code defines SUPPORT_STATIC_DUNIT_CONFIG or
STATIC_ALGO_SUPPORT. Remove ddr3_a38x_mc_static.h and use unifdef to
remove unused sections in the rest of the ddr/marvell/a38x code.

Signed-off-by: Chris Packham 
---
Much of this code is moved/removed in the updated DDR code so this
commit helps minimise the final delta.

Changes in v2: New

 drivers/ddr/marvell/a38x/ddr3_a38x.c|  51 ---
 drivers/ddr/marvell/a38x/ddr3_a38x_mc_static.h  | 226 
 drivers/ddr/marvell/a38x/ddr3_debug.c   |   9 -
 drivers/ddr/marvell/a38x/ddr3_init.c|  29 --
 drivers/ddr/marvell/a38x/ddr3_init.h|   1 -
 drivers/ddr/marvell/a38x/ddr3_training.c|  41 ---
 drivers/ddr/marvell/a38x/ddr3_training_static.c | 438 
 7 files changed, 795 deletions(-)
 delete mode 100644 drivers/ddr/marvell/a38x/ddr3_a38x_mc_static.h

diff --git a/drivers/ddr/marvell/a38x/ddr3_a38x.c 
b/drivers/ddr/marvell/a38x/ddr3_a38x.c
index c082122f25c3..22390325003d 100644
--- a/drivers/ddr/marvell/a38x/ddr3_a38x.c
+++ b/drivers/ddr/marvell/a38x/ddr3_a38x.c
@@ -77,41 +77,6 @@ struct trip_delay_element 
a38x_board_round_trip_delay_array[] = {
{ 4282, 6160 }  /* ECC PUP */
 };
 
-#ifdef STATIC_ALGO_SUPPORT
-/* package trace */
-static struct trip_delay_element a38x_package_round_trip_delay_array[] = {
-   /* IF BUS DQ_DELAY CK_DELAY */
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 },
-   { 0, 0 }
-};
-
-static int a38x_silicon_delay_offset[] = {
-   /* board 0 */
-   0,
-   /* board 1 */
-   0,
-   /* board 2 */
-   0
-};
-#endif
 
 static u8 a38x_bw_per_freq[DDR_FREQ_LIMIT] = {
0x3,/* DDR_FREQ_100 */
@@ -368,22 +333,6 @@ static int ddr3_tip_init_a38x_silicon(u32 dev_num, u32 
board_id)
 
ddr3_tip_register_dq_table(dev_num, dq_bit_map_2_phy_pin);
 
-#ifdef STATIC_ALGO_SUPPORT
-   {
-   struct hws_tip_static_config_info static_config;
-   u32 board_offset =
-   board_id * A38X_NUMBER_OF_INTERFACES *
-   tm->num_of_bus_per_interface;
-
-   static_config.silicon_delay =
-   a38x_silicon_delay_offset[board_id];
-   static_config.package_trace_arr =
-   a38x_package_round_trip_delay_array;
-   static_config.board_trace_arr =
-   _board_round_trip_delay_array[board_offset];
-   ddr3_tip_init_static_config_db(dev_num, _config);
-   }
-#endif
status = ddr3_tip_a38x_get_init_freq(dev_num, _freq);
if (MV_OK != status) {
DEBUG_TRAINING_ACCESS(DEBUG_LEVEL_ERROR,
diff --git a/drivers/ddr/marvell/a38x/ddr3_a38x_mc_static.h 
b/drivers/ddr/marvell/a38x/ddr3_a38x_mc_static.h
deleted file mode 100644
index b879a010311b..
--- a/drivers/ddr/marvell/a38x/ddr3_a38x_mc_static.h
+++ /dev/null
@@ -1,226 +0,0 @@
-/*
- * Copyright (C) Marvell International Ltd. and its affiliates
- *
- * SPDX-License-Identifier:GPL-2.0
- */
-
-#ifndef _DDR3_A38X_MC_STATIC_H
-#define _DDR3_A38X_MC_STATIC_H
-
-#include "ddr3_a38x.h"
-
-#ifdef SUPPORT_STATIC_DUNIT_CONFIG
-
-#ifdef CONFIG_CUSTOMER_BOARD_SUPPORT
-static struct reg_data ddr3_customer_800[] = {
-   /* parameters for customer board (based on 800MHZ) */
-   {0x1400,0x7b00cc30, 0x},
-   {0x1404,0x36301820, 0x},
-   {0x1408,0x5415baab, 0x},
-   {0x140c,0x38411def, 0x},
-   {0x1410,0x1830, 0x},
-   {0x1414,0x0700, 0x},
-   {0x1424,0x0060f3ff, 0x},
-   {0x1428,0x0011a940, 0x},
-   {0x142c,0x28c5134,  0x},
-   {0x1474,0x, 0x},
-   {0x147c,0xd771, 0x},
-   {0x1494,0x0003, 0x},
-   {0x149c,0x0300, 0x},
-   {0x14a8,0x, 0x},
-   {0x14cc,0xbd09000d, 0x},
-   {0x1504,0xfff1, 0x},
-   {0x150c,0xffe5, 0x},
-   {0x1514,0x, 0x},
-   {0x151c,0x, 0x},
-   {0x1538,0x0b0b, 0x},
-   {0x153c,0x0c0c, 0x},
-   {0x15d0,0x0670, 0x},
-   {0x15d4,0x0046, 0x},
-   {0x15d8,0x0010, 0x},
-   {0x15dc,0x, 0x},
-   {0x15e0,0x0023, 0x},
-   {0x15e4,0x00203c18, 0x},
-  

[U-Boot] [PATCH V2] imx: nitrogen6x: Convert Sabrelite to distro boot support

2018-04-09 Thread Guillaume GARDET

Boot tested with boot.scr script and EFI/Grub2 on mmc0 and mmc1 slots.

Signed-off-by: Guillaume GARDET 
Cc: Troy Kisky 
Cc: Stefano Babic 
Cc: Fabio Estevam 

---
Changes in V2:
  * add mx6qsabrelite_defconfig update

 configs/mx6qsabrelite_defconfig | 16 ++--
 include/configs/nitrogen6x.h| 86 +
 2 files changed, 22 insertions(+), 80 deletions(-)

diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
index 7499704058..c644754929 100644
--- a/configs/mx6qsabrelite_defconfig
+++ b/configs/mx6qsabrelite_defconfig
@@ -3,17 +3,15 @@ CONFIG_ARCH_MX6=y
 CONFIG_SYS_TEXT_BASE=0x1780
 CONFIG_TARGET_NITROGEN6X=y
 CONFIG_CMD_HDMIDETECT=y
+CONFIG_DISTRO_DEFAULTS=y
 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/boundary/nitrogen6x/nitrogen6q.cfg,MX6Q,DDR_MB=1024,SABRELITE"
 CONFIG_BOOTDELAY=3
+# CONFIG_USE_BOOTCOMMAND is not set
 CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
-CONFIG_SUPPORT_RAW_INITRD=y
 CONFIG_BOARD_EARLY_INIT_F=y
-CONFIG_HUSH_PARSER=y
 CONFIG_FASTBOOT=y
 CONFIG_FASTBOOT_BUF_ADDR=0x1200
-CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_MEMTEST=y
-CONFIG_SYS_ALT_MEMTEST=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
@@ -22,21 +20,15 @@ CONFIG_CMD_SATA=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
 CONFIG_CMD_BMP=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_TIME=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
+# CONFIG_ISO_PARTITION is not set
+# CONFIG_EFI_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_DM=y
 CONFIG_DWC_AHSATA=y
-CONFIG_FSL_ESDHC=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SST=y
 CONFIG_PHYLIB=y
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h
index 7d2cf0bd8c..3161b1dd79 100644
--- a/include/configs/nitrogen6x.h
+++ b/include/configs/nitrogen6x.h
@@ -102,82 +102,32 @@
 #define CONFIG_UMSDEVS CONFIG_DRIVE_SATA CONFIG_DRIVE_MMC
 
 #if defined(CONFIG_SABRELITE)
+#define BOOT_TARGET_DEVICES(func) \
+   func(MMC, mmc, 0) \
+   func(MMC, mmc, 1) \
+   func(SATA, sata, 0) \
+   func(USB, usb, 0) \
+   func(PXE, pxe, na) \
+   func(DHCP, dhcp, na)
+
+#include 
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
-   "script=boot.scr\0" \
-   "uimage=uImage\0" \
"console=ttymxc1\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
-   "fdt_file=imx6q-sabrelite.dtb\0" \
+   "fdtfile=imx6q-sabrelite.dtb\0" \
"fdt_addr=0x1800\0" \
-   "boot_fdt=try\0" \
+   "fdt_addr_r=0x1800\0" \
+   "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0"  \
+   "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
+   "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
+   "ramdisk_addr_r=0x1300\0" \
+   "ramdiskaddr=0x1300\0" \
"ip_dyn=yes\0" \
"usb_pgood_delay=2000\0" \
-   "mmcdevs=0 1\0" \
-   "mmcpart=1\0" \
-   "mmcroot=/dev/mmcblk0p2 rootwait rw\0" \
-   "mmcargs=setenv bootargs console=${console},${baudrate} " \
-   "root=${mmcroot}\0" \
-   "loadbootscript=" \
-   "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
-   "bootscript=echo Running bootscript from mmc ...; " \
-   "source\0" \
-   "loaduimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0" \
-   "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
-   "mmcboot=echo Booting from mmc ...; " \
-   "run mmcargs; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if run loadfdt; then " \
-   "bootm ${loadaddr} - ${fdt_addr}; " \
-   "else " \
-   "if test ${boot_fdt} = try; then " \
-   "bootm; " \
-   "else " \
-   "echo WARN: Cannot load the DT; " \
-   "fi; " \
-   "fi; " \
-   "else " \
-   "bootm; " \
-   "fi;\0" \
-   "netargs=setenv bootargs console=${console},${baudrate} " \
-   "root=/dev/nfs " \
-   "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
-   "netboot=echo Booting from net ...; " \
-   "run netargs; " \
-   "if test ${ip_dyn} = yes; then " \
-   "setenv get_cmd dhcp; " \
-   "else " \
-   "setenv get_cmd tftp; " \
-   "fi; " \
-   "${get_cmd} ${uimage}; " \
-   "if test ${boot_fdt} = yes || test ${boot_fdt} = try; then " \
-   "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
- 

Re: [U-Boot] Question regarding cpu_get_count(..)

2018-04-09 Thread Christian Gmeiner
Hi Bin

2018-04-06 10:30 GMT+02:00 Christian Gmeiner :
> Hi Bin
>
> 2018-04-06 9:47 GMT+02:00 Bin Meng :
>> Hi Christian,
>>
>> On Fri, Apr 6, 2018 at 2:55 PM, Christian Gmeiner
>>  wrote:
>>> Hi
>>>
>>> I tried my luck on the u-boot irc channel but nobody cared so I am
>>> asking this here again.
>>> Does cpu_get_count(..) return the number of physical CPUs or the
>>> number of logical CPUs?
>>>
>>> I am currently preparing a patch set which adds
>>> arch/x86/cpu/queensbay/cpu.c and there I need
>>> to specify a struct cpu_ops with a function called get_count(). But
>>> what must I return (physical vs. logical CPU count)?
>>>
>>
>> It's logical CPUs, say you have one physical CPU, each with
>> dual-threads, so get_count() returns 2.
>>
>
> Good to know. I am looking into an issue where vxworks 7 intel gen is not able
> to detect the correct amount of physical and logical CPUs (on a blob 
> UEFI-Bios).
> I compared the new platform with an older queensbay based one the there are 
> some
> discrepancies. As vx7 makes use of a handful of BIOS tables I thought I start 
> at
> the root (get_count()) and move up. So as a result of this that means that the
> MP table has one "Processor Entry" per logical CPU - or? I tired to get that
> information for the spec but failed.
>
>> But Intel CrownBay already supports SMP in U-Boot. What patch are you
>> working on?
>
> I am out of office today and do not have access to my wip git rep :(
> But I needed
> to set some speed frequency registers.. but can tell you more on Monday.
>

Okay.. yeah I need to configure speed: https://hastebin.com/toqihobali.cpp

So the end result is to get all BIOS tables standard conform and vx7 should
be happy - I hope.

-- 
greets
--
Christian Gmeiner, MSc

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


Re: [U-Boot] [PATCH] kconfig: add CONFIG_CC_COVERAGE

2018-04-09 Thread Christian Gmeiner
Hi

2018-04-08 16:30 GMT+02:00 Tom Rini :
> On Thu, Mar 29, 2018 at 09:49:30AM +0200, Christian Gmeiner wrote:
>
>> Make it possible to use gcc code coverage analysis.
>>
>> Signed-off-by: Christian Gmeiner 
>> ---
>>  .gitignore | 4 
>>  Kconfig| 8 
>>  Makefile   | 6 ++
>>  3 files changed, 18 insertions(+)
>>
>> diff --git a/.gitignore b/.gitignore
>> index 29757aa51e..f1b801579c 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -85,3 +85,7 @@ GTAGS
>>  *.orig
>>  *~
>>  \#*#
>> +
>> +# gcc code coverage files
>> +*.gcda
>> +*.gcno
>> diff --git a/Kconfig b/Kconfig
>> index 6670913799..f092f72b25 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -59,6 +59,14 @@ config CC_OPTIMIZE_FOR_SIZE
>>
>> This option is enabled by default for U-Boot.
>>
>> +config CC_COVERAGE
>> + bool "Enable code coverage analysis"
>> + default n
>> + depends on SANDBOX
>> + help
>> +   Enabling this option will pass "--coverage" to gcc to compile
>> +   and link code instrumented for coverage analysis.
>
> We shouldn't need default n, as that is the normal default.  And why is
> this only on SANDBOX?
>

The default thing will get fixed in V2. If we want to record code coverage on
real hardware we need to add an infrastructure to store the generated analysis
data. In the sandbox case this information is stored in the local
filesystem (*.gcda).
To get a feeling what may be needs to be done for the real target patch have a
look at:
https://mcuoneclipse.com/2014/12/26/code-coverage-for-embedded-target-with-eclipse-gcc-and-gcov/

My goal is it to get some code coverage data for unit tests that are run in the
sandboxed environment.

Is it okay for you to only cover the sandbox case or do you want/need
the full blown
solution?

>> +
>>  config DISTRO_DEFAULTS
>>   bool "Select defaults suitable for booting general purpose Linux 
>> distributions"
>>   default y if ARCH_SUNXI || TEGRA
>> diff --git a/Makefile b/Makefile
>> index 5fa14789d9..d06193e8f4 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -720,6 +720,12 @@ else
>>  PLATFORM_LIBGCC := -L $(shell dirname `$(CC) $(c_flags) 
>> -print-libgcc-file-name`) -lgcc
>>  endif
>>  PLATFORM_LIBS += $(PLATFORM_LIBGCC)
>> +
>> +ifdef CONFIG_CC_COVERAGE
>> +KBUILD_CFLAGS+= --coverage
>> +PLATFORM_LIBGCC += -lgcov
>
> Consistent spacing please, thanks!

Opps.. will be fixed in V2.

-- 
greets
--
Christian Gmeiner, MSc

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


Re: [U-Boot] [RFC PATCH] net: phy: Don't limit phy addresses by default

2018-04-09 Thread Dr. Philipp Tomsich

> On 9 Apr 2018, at 10:01, Neil Armstrong  wrote:
> 
> On 30/03/2018 18:52, Joe Hershberger wrote:
>> Some boards expect to find more than one phy while other boards are old
>> and need to be limited to a specific phy address. Only limit the phy
>> address for boards that opt in.
>> 
>> Signed-off-by: Joe Hershberger 

Reviewed-by: Philipp Tomsich 

See below for recommended change.

>> 
>> ---
>> 
>> configs/am335x_baltos_defconfig| 1 +
>> configs/am335x_shc_defconfig   | 1 +
>> configs/am335x_shc_ict_defconfig   | 1 +
>> configs/am335x_shc_netboot_defconfig   | 1 +
>> configs/am335x_shc_prompt_defconfig| 1 +
>> configs/am335x_shc_sdboot_defconfig| 1 +
>> configs/am335x_shc_sdboot_prompt_defconfig | 1 +
>> configs/devkit3250_defconfig   | 1 +
>> configs/ds414_defconfig| 1 +
>> configs/khadas-vim_defconfig   | 1 +
>> configs/libretech-cc_defconfig | 1 +
>> configs/p212_defconfig | 1 +
>> configs/pepper_defconfig   | 1 +
>> configs/work_92105_defconfig   | 1 +
>> configs/x600_defconfig | 1 +
>> drivers/net/phy/Kconfig| 8 
>> 16 files changed, 23 insertions(+)
>> 
>> diff --git a/configs/am335x_baltos_defconfig 
>> b/configs/am335x_baltos_defconfig
>> index ab7d96d..ed7d3a7 100644
>> --- a/configs/am335x_baltos_defconfig
>> +++ b/configs/am335x_baltos_defconfig
>> @@ -42,6 +42,7 @@ CONFIG_BOOTCOUNT_LIMIT=y
>> CONFIG_SYS_OMAP24_I2C_SPEED=1000
>> CONFIG_MMC_OMAP_HS=y
>> CONFIG_NAND=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/am335x_shc_defconfig b/configs/am335x_shc_defconfig
>> index fb714da..ade16b9 100644
>> --- a/configs/am335x_shc_defconfig
>> +++ b/configs/am335x_shc_defconfig
>> @@ -35,6 +35,7 @@ CONFIG_CMD_MMC=y
>> # CONFIG_SPL_ISO_PARTITION is not set
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_MMC_OMAP_HS=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/am335x_shc_ict_defconfig 
>> b/configs/am335x_shc_ict_defconfig
>> index 2568e3d..ac19a74 100644
>> --- a/configs/am335x_shc_ict_defconfig
>> +++ b/configs/am335x_shc_ict_defconfig
>> @@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y
>> # CONFIG_SPL_ISO_PARTITION is not set
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_MMC_OMAP_HS=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/am335x_shc_netboot_defconfig 
>> b/configs/am335x_shc_netboot_defconfig
>> index 16071fb..31f1847 100644
>> --- a/configs/am335x_shc_netboot_defconfig
>> +++ b/configs/am335x_shc_netboot_defconfig
>> @@ -37,6 +37,7 @@ CONFIG_CMD_MMC=y
>> # CONFIG_SPL_ISO_PARTITION is not set
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_MMC_OMAP_HS=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/am335x_shc_prompt_defconfig 
>> b/configs/am335x_shc_prompt_defconfig
>> index bbad6dd..803304e 100644
>> --- a/configs/am335x_shc_prompt_defconfig
>> +++ b/configs/am335x_shc_prompt_defconfig
>> @@ -34,6 +34,7 @@ CONFIG_CMD_MMC=y
>> # CONFIG_SPL_ISO_PARTITION is not set
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_MMC_OMAP_HS=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/am335x_shc_sdboot_defconfig 
>> b/configs/am335x_shc_sdboot_defconfig
>> index 82a61a3..2d4f4d1 100644
>> --- a/configs/am335x_shc_sdboot_defconfig
>> +++ b/configs/am335x_shc_sdboot_defconfig
>> @@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y
>> # CONFIG_SPL_ISO_PARTITION is not set
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_MMC_OMAP_HS=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/am335x_shc_sdboot_prompt_defconfig 
>> b/configs/am335x_shc_sdboot_prompt_defconfig
>> index 82a61a3..2d4f4d1 100644
>> --- a/configs/am335x_shc_sdboot_prompt_defconfig
>> +++ b/configs/am335x_shc_sdboot_prompt_defconfig
>> @@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y
>> # CONFIG_SPL_ISO_PARTITION is not set
>> CONFIG_ENV_IS_IN_MMC=y
>> CONFIG_MMC_OMAP_HS=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHYLIB=y
>> CONFIG_SYS_NS16550=y
>> CONFIG_OMAP3_SPI=y
>> diff --git a/configs/devkit3250_defconfig b/configs/devkit3250_defconfig
>> index e1a9b49..b69808c 100644
>> --- a/configs/devkit3250_defconfig
>> +++ b/configs/devkit3250_defconfig
>> @@ -36,6 +36,7 @@ CONFIG_MTD_NOR_FLASH=y
>> CONFIG_NAND=y
>> CONFIG_SPL_NAND_SIMPLE=y
>> CONFIG_PHYLIB=y
>> +CONFIG_PHY_ADDR_ENABLE=y
>> CONFIG_PHY_ADDR=31
>> CONFIG_DM_SERIAL=y
>> CONFIG_SYS_NS16550=y
>> diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig
>> index 5d1d6ab..d68e64e 100644
>> --- a/configs/ds414_defconfig
>> +++ b/configs/ds414_defconfig
>> @@ -39,6 +39,7 @@ 

Re: [U-Boot] Question regarding cpu_get_count(..)

2018-04-09 Thread Bin Meng
Hi Christian,

On Mon, Apr 9, 2018 at 3:52 PM, Christian Gmeiner
 wrote:
> Hi Bin
>
> 2018-04-06 10:30 GMT+02:00 Christian Gmeiner :
>> Hi Bin
>>
>> 2018-04-06 9:47 GMT+02:00 Bin Meng :
>>> Hi Christian,
>>>
>>> On Fri, Apr 6, 2018 at 2:55 PM, Christian Gmeiner
>>>  wrote:
 Hi

 I tried my luck on the u-boot irc channel but nobody cared so I am
 asking this here again.
 Does cpu_get_count(..) return the number of physical CPUs or the
 number of logical CPUs?

 I am currently preparing a patch set which adds
 arch/x86/cpu/queensbay/cpu.c and there I need
 to specify a struct cpu_ops with a function called get_count(). But
 what must I return (physical vs. logical CPU count)?

>>>
>>> It's logical CPUs, say you have one physical CPU, each with
>>> dual-threads, so get_count() returns 2.
>>>
>>
>> Good to know. I am looking into an issue where vxworks 7 intel gen is not 
>> able
>> to detect the correct amount of physical and logical CPUs (on a blob 
>> UEFI-Bios).
>> I compared the new platform with an older queensbay based one the there are 
>> some
>> discrepancies. As vx7 makes use of a handful of BIOS tables I thought I 
>> start at
>> the root (get_count()) and move up. So as a result of this that means that 
>> the
>> MP table has one "Processor Entry" per logical CPU - or? I tired to get that
>> information for the spec but failed.
>>
>>> But Intel CrownBay already supports SMP in U-Boot. What patch are you
>>> working on?
>>
>> I am out of office today and do not have access to my wip git rep :(
>> But I needed
>> to set some speed frequency registers.. but can tell you more on Monday.
>>
>
> Okay.. yeah I need to configure speed: https://hastebin.com/toqihobali.cpp
>
> So the end result is to get all BIOS tables standard conform and vx7 should
> be happy - I hope.
>

I am not sure I understand the mods here. Are you saying that vx7 is
not happy due to U-Boot is missing some core speed register
configuration?

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


Re: [U-Boot] [U-Boot, 36/36] rockchip: add common board file for rockchip platform

2018-04-09 Thread Dr. Philipp Tomsich
Kever,

> On 9 Apr 2018, at 00:35, Tom Rini  wrote:
> 
> On Sun, Apr 08, 2018 at 09:45:22AM +0800, Kever Yang wrote:
>> Philipp,
>> 
>> 
>> On 04/02/2018 05:28 AM, Philipp Tomsich wrote:
>>> 
>>> 
>>> On Tue, 27 Mar 2018, Kever Yang wrote:
>>> 
 We use common board/spl/tpl file for all rockchip SoCs,
 - all the SoC spec setting should move into SoC file like rk3288.c;
 - tpl is option and only purpose to init DRAM, clock, uart(option);
 - spl do secure relate one time init, boot device select, boot into
  U-Boot or trust or OS in falcon mode;
 - board do boot mode detect, enable regulator, usb init and so on.
>>> 
>>> There's too much going on in a single commit/single series.
>>> This needs to be split up into multiple, independent steps (e.g. one
>>> for the timer changes, another one for the UART changes)...
>> 
>> I understand review the patches piece by piece is much more comfortable,
>> and this patch including "too much" things. And I never expect this
>> patch set
>> can be merge quickly, but we have to do this ASAP before more SoC coming.
>> I have do a lot of test and re-work in my local branch and at last make
>> it landed in
>> rockchip vendor U-Boot, with testing in most of SoCs(not including
>> rk3066/rk3188).
>> Well, I do try to split it into pieces, but I found that actually not
>> help very much
>> except waste much more time:
>> - The target is(very clear) to make rockchip soc board file in a good
>> shape with common files,
>> instead of copy-paste for each soc(more than 10 of them now)
>> - then we need to identify what's common and what should go to soc and
>> board;
>> - remove using common rockchip timer and use arm generic timer instead
>> for armv7
>> SoCs(rk3066 and rk3188 need still using rockchip timer)
>> - most soc need to do uart init, boot order select, and some
>> arch_cpu_init().
>> - don't break the boards already working, so I still leave some code
>> which not so common
>> in board file, but I would like to remove or move them into right
>> place if I got a board
>> to verify;

Having a clean commit-history and the ability to bisect and revert individual
patches is an important requirement for the overall project.

I thought to have already provided you the needed guidance on how to get
most fo this merged and highlighted where architectural discussions will be
needed.

So to get most of this merged quickly, you will need to break this up into
series that are more manageable (this is likely to not be a full list):
 * the changes for split out the UART configs
 * the timer changes
 * adding a common board-file and switching boards over
For the common board-file, you should add this first and then start moving
SoCs over onto this new file.  I believe (my memory may be wrong) to have
commented so in some of the individual reviews.

Finally, there’s a few architectural issues to discuss:
 1. You are merging the “board”-files, but these are now merged across
multiple SoCs and across multiple boards per SoC.  This is already
causing some fraying at the edges (e.g. the number of rk_* hooks and
the weak functions added).  We should very carefully consider how
this will affect adding boards (which may have a specific market
segment in mind and may—for lack of a better example—not want
to have rockusb included) in the future.
 2. The new weak-functions are causing a major headache: they are at
odds with us trying to move to DM across the entire tree. I strongly
believe that these weak functions will cause added debug issues in
the short term and that they will eventually be replaced with more
DM-like model in the long term.

Thanks,
Philipp.

>> @Simon, @Tom,
>> This patch set is to remove some common files and add some other common
>> files for
>> all Rockchip SoCs, I have to make sure the whole patch set can running
>> good for all SoCs,
>> but it's really hard to make every patch to build and work perfect for
>> all SoCs, is there
>> any mandatory rules for this?
> 
> So you mean possibly breaking some existing platforms?  I don't like the
> idea of doing that...
> 
> -- 
> Tom

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


Re: [U-Boot] [U-Boot, 36/36] rockchip: add common board file for rockchip platform

2018-04-09 Thread Dr. Philipp Tomsich
Kever,

> On 8 Apr 2018, at 03:45, Kever Yang  wrote:
> 
> Philipp,
> 
> 
> On 04/02/2018 05:28 AM, Philipp Tomsich wrote:
>> 
>> 
>> On Tue, 27 Mar 2018, Kever Yang wrote:
>> 
>>> We use common board/spl/tpl file for all rockchip SoCs,
>>> - all the SoC spec setting should move into SoC file like rk3288.c;
>>> - tpl is option and only purpose to init DRAM, clock, uart(option);
>>> - spl do secure relate one time init, boot device select, boot into
>>>  U-Boot or trust or OS in falcon mode;
>>> - board do boot mode detect, enable regulator, usb init and so on.
>> 
>> There's too much going on in a single commit/single series.
>> This needs to be split up into multiple, independent steps (e.g. one
>> for the timer changes, another one for the UART changes)...
> 
> I understand review the patches piece by piece is much more comfortable,

In fact I do not like to do these reviews, as they are a tiresome chore…
…but they need to be done, as some issues are best caught at this stage.
Note, that a good commit message (i.e. one that summarises the status
quo/presents the motivation for the specific change; then summarises
what is changed how and to what effect; finally notes on anything that
the reviewer/someone debugging in the future should know) helps very
much in reviewing.

However, a review can not catch all issues and once a patch-set gets
to a certain level of complexity, it is likely to introduce unnecessary
breakage that could have been avoided in a review (if there simply
hadn’t been too many changes at once).

Consequently, we need a clean history consisting of orthogonal changes
so we can bisect and revert if necessary (and I’d prefer not to revert an
entire series)… which again requires patches that are (a) in a healthy
application-order and (b) do a well-defined number of things well.

> and this patch including "too much" things. And I never expect this
> patch set
> can be merge quickly, but we have to do this ASAP before more SoC coming.

The quickest way to get at least some of this merged quickly (e.g. the
UART changes) is to have smaller series for these.

> I have do a lot of test and re-work in my local branch and at last make
> it landed in
> rockchip vendor U-Boot, with testing in most of SoCs(not including
> rk3066/rk3188).
> Well, I do try to split it into pieces, but I found that actually not
> help very much
> except waste much more time:
> - The target is(very clear) to make rockchip soc board file in a good
> shape with common files,
> instead of copy-paste for each soc(more than 10 of them now)
> - then we need to identify what's common and what should go to soc and
> board;
> - remove using common rockchip timer and use arm generic timer instead
> for armv7
> SoCs(rk3066 and rk3188 need still using rockchip timer)
> - most soc need to do uart init, boot order select, and some
> arch_cpu_init().
> - don't break the boards already working, so I still leave some code
> which not so common
> in board file, but I would like to remove or move them into right
> place if I got a board
> to verify;
> 
> @Simon, @Tom,
> This patch set is to remove some common files and add some other common
> files for
> all Rockchip SoCs, I have to make sure the whole patch set can running
> good for all SoCs,
> but it's really hard to make every patch to build and work perfect for
> all SoCs, is there
> any mandatory rules for this?
> 
> I have to do a lot of temporary work for this like add temporary MACRO
> for those SoCs
> convert to use common code, and remove it after all the SoCs have
> convert to use common
> code, which have no any help for what we get at last, but it really cost
> a lot of time.
> 
>> 
>>> 
>>> Signed-off-by: Kever Yang 
>> 
>> See below for requested changes (beyond splitting this up).
>> Reviewing this in this state is a real chore, so I'll probably have
>> more comments, once I see this presented in more manageable parcels.
>> 
>>> ---
>>> 
>>> arch/arm/mach-rockchip/Makefile |  23 +
>>> arch/arm/mach-rockchip/board.c  | 136 
>>> arch/arm/mach-rockchip/spl.c| 195
>>> 
>>> arch/arm/mach-rockchip/tpl.c| 111 +++
>>> 4 files changed, 445 insertions(+), 20 deletions(-)
>>> create mode 100644 arch/arm/mach-rockchip/board.c
>>> create mode 100644 arch/arm/mach-rockchip/spl.c
>>> create mode 100644 arch/arm/mach-rockchip/tpl.c
>>> 
>>> diff --git a/arch/arm/mach-rockchip/Makefile
>>> b/arch/arm/mach-rockchip/Makefile
>>> index e1b0519..3aba66c 100644
>>> --- a/arch/arm/mach-rockchip/Makefile
>>> +++ b/arch/arm/mach-rockchip/Makefile
>>> @@ -11,15 +11,8 @@
>>> obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
>>> obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
>>> 
>>> -obj-tpl-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-tpl.o
>>> -obj-tpl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-tpl.o
>>> -
>>> 

Re: [U-Boot] [RFC PATCH] net: phy: Don't limit phy addresses by default

2018-04-09 Thread Neil Armstrong
On 30/03/2018 18:52, Joe Hershberger wrote:
> Some boards expect to find more than one phy while other boards are old
> and need to be limited to a specific phy address. Only limit the phy
> address for boards that opt in.
> 
> Signed-off-by: Joe Hershberger 
> 
> ---
> 
>  configs/am335x_baltos_defconfig| 1 +
>  configs/am335x_shc_defconfig   | 1 +
>  configs/am335x_shc_ict_defconfig   | 1 +
>  configs/am335x_shc_netboot_defconfig   | 1 +
>  configs/am335x_shc_prompt_defconfig| 1 +
>  configs/am335x_shc_sdboot_defconfig| 1 +
>  configs/am335x_shc_sdboot_prompt_defconfig | 1 +
>  configs/devkit3250_defconfig   | 1 +
>  configs/ds414_defconfig| 1 +
>  configs/khadas-vim_defconfig   | 1 +
>  configs/libretech-cc_defconfig | 1 +
>  configs/p212_defconfig | 1 +
>  configs/pepper_defconfig   | 1 +
>  configs/work_92105_defconfig   | 1 +
>  configs/x600_defconfig | 1 +
>  drivers/net/phy/Kconfig| 8 
>  16 files changed, 23 insertions(+)
> 
> diff --git a/configs/am335x_baltos_defconfig b/configs/am335x_baltos_defconfig
> index ab7d96d..ed7d3a7 100644
> --- a/configs/am335x_baltos_defconfig
> +++ b/configs/am335x_baltos_defconfig
> @@ -42,6 +42,7 @@ CONFIG_BOOTCOUNT_LIMIT=y
>  CONFIG_SYS_OMAP24_I2C_SPEED=1000
>  CONFIG_MMC_OMAP_HS=y
>  CONFIG_NAND=y
> +CONFIG_PHY_ADDR_ENABLE=y
>  CONFIG_PHYLIB=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_OMAP3_SPI=y
> diff --git a/configs/am335x_shc_defconfig b/configs/am335x_shc_defconfig
> index fb714da..ade16b9 100644
> --- a/configs/am335x_shc_defconfig
> +++ b/configs/am335x_shc_defconfig
> @@ -35,6 +35,7 @@ CONFIG_CMD_MMC=y
>  # CONFIG_SPL_ISO_PARTITION is not set
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_MMC_OMAP_HS=y
> +CONFIG_PHY_ADDR_ENABLE=y
>  CONFIG_PHYLIB=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_OMAP3_SPI=y
> diff --git a/configs/am335x_shc_ict_defconfig 
> b/configs/am335x_shc_ict_defconfig
> index 2568e3d..ac19a74 100644
> --- a/configs/am335x_shc_ict_defconfig
> +++ b/configs/am335x_shc_ict_defconfig
> @@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y
>  # CONFIG_SPL_ISO_PARTITION is not set
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_MMC_OMAP_HS=y
> +CONFIG_PHY_ADDR_ENABLE=y
>  CONFIG_PHYLIB=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_OMAP3_SPI=y
> diff --git a/configs/am335x_shc_netboot_defconfig 
> b/configs/am335x_shc_netboot_defconfig
> index 16071fb..31f1847 100644
> --- a/configs/am335x_shc_netboot_defconfig
> +++ b/configs/am335x_shc_netboot_defconfig
> @@ -37,6 +37,7 @@ CONFIG_CMD_MMC=y
>  # CONFIG_SPL_ISO_PARTITION is not set
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_MMC_OMAP_HS=y
> +CONFIG_PHY_ADDR_ENABLE=y
>  CONFIG_PHYLIB=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_OMAP3_SPI=y
> diff --git a/configs/am335x_shc_prompt_defconfig 
> b/configs/am335x_shc_prompt_defconfig
> index bbad6dd..803304e 100644
> --- a/configs/am335x_shc_prompt_defconfig
> +++ b/configs/am335x_shc_prompt_defconfig
> @@ -34,6 +34,7 @@ CONFIG_CMD_MMC=y
>  # CONFIG_SPL_ISO_PARTITION is not set
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_MMC_OMAP_HS=y
> +CONFIG_PHY_ADDR_ENABLE=y
>  CONFIG_PHYLIB=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_OMAP3_SPI=y
> diff --git a/configs/am335x_shc_sdboot_defconfig 
> b/configs/am335x_shc_sdboot_defconfig
> index 82a61a3..2d4f4d1 100644
> --- a/configs/am335x_shc_sdboot_defconfig
> +++ b/configs/am335x_shc_sdboot_defconfig
> @@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y
>  # CONFIG_SPL_ISO_PARTITION is not set
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_MMC_OMAP_HS=y
> +CONFIG_PHY_ADDR_ENABLE=y
>  CONFIG_PHYLIB=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_OMAP3_SPI=y
> diff --git a/configs/am335x_shc_sdboot_prompt_defconfig 
> b/configs/am335x_shc_sdboot_prompt_defconfig
> index 82a61a3..2d4f4d1 100644
> --- a/configs/am335x_shc_sdboot_prompt_defconfig
> +++ b/configs/am335x_shc_sdboot_prompt_defconfig
> @@ -36,6 +36,7 @@ CONFIG_CMD_MMC=y
>  # CONFIG_SPL_ISO_PARTITION is not set
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_MMC_OMAP_HS=y
> +CONFIG_PHY_ADDR_ENABLE=y
>  CONFIG_PHYLIB=y
>  CONFIG_SYS_NS16550=y
>  CONFIG_OMAP3_SPI=y
> diff --git a/configs/devkit3250_defconfig b/configs/devkit3250_defconfig
> index e1a9b49..b69808c 100644
> --- a/configs/devkit3250_defconfig
> +++ b/configs/devkit3250_defconfig
> @@ -36,6 +36,7 @@ CONFIG_MTD_NOR_FLASH=y
>  CONFIG_NAND=y
>  CONFIG_SPL_NAND_SIMPLE=y
>  CONFIG_PHYLIB=y
> +CONFIG_PHY_ADDR_ENABLE=y
>  CONFIG_PHY_ADDR=31
>  CONFIG_DM_SERIAL=y
>  CONFIG_SYS_NS16550=y
> diff --git a/configs/ds414_defconfig b/configs/ds414_defconfig
> index 5d1d6ab..d68e64e 100644
> --- a/configs/ds414_defconfig
> +++ b/configs/ds414_defconfig
> @@ -39,6 +39,7 @@ CONFIG_SPL_OF_TRANSLATE=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_BAR=y
>  CONFIG_SPI_FLASH_STMICRO=y
> +CONFIG_PHY_ADDR_ENABLE=y
>  CONFIG_PHY_GIGE=y
>  CONFIG_MVNETA=y
>  CONFIG_PCI=y
> diff --git a/configs/khadas-vim_defconfig b/configs/khadas-vim_defconfig

Re: [U-Boot] [PATCH v4 1/2] SPI Flash: add support of sst26wf* flash ICs protection ops

2018-04-09 Thread Jagan Teki
On Mon, Apr 9, 2018 at 4:27 PM, Eugeniy Paltsev
 wrote:
> sst26wf flash series block protection implementation differs
> from other SST series, so add specific implementation
> flash_lock/flash_unlock/flash_is_locked functions for sst26wf
> flash ICs.
>
> Signed-off-by: Eugeniy Paltsev 
> ---
> Changes v3->v4:
>  * Make sst26_process_bpr() and sst26_lock_ctl() functions static.
>
> Changes v2->v3:
>  * Move SST26 command defenition to sf_internal.h
>  * Merge sst26_set_bpr, sst26_clear_bpr and sst26_check_bpr functions
>into single sst26_process_bpr function.
>  * Use SF_UNLOCKED/SF_LOCKED instead of magic numbers in
>sst26_lock_ctl()
>
> Changes v1->v2:
>  * Use generic defines from linux/sizes.h instead of custom ones.
>
>  drivers/mtd/spi/sf_internal.h |  18 +
>  drivers/mtd/spi/spi_flash.c   | 165 
> ++
>  2 files changed, 183 insertions(+)
>
> diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
> index 839cdbe1b0..a17dcc4de1 100644
> --- a/drivers/mtd/spi/sf_internal.h
> +++ b/drivers/mtd/spi/sf_internal.h
> @@ -26,6 +26,11 @@ enum spi_nor_option_flags {
> SNOR_F_USE_UPAGE= BIT(3),
>  };
>
> +enum flash_lock_status {
> +   SF_UNLOCKED = 0,
> +   SF_LOCKED   = 1,
> +};

Try to use existing relevant error codes.

> +
>  #define SPI_FLASH_3B_ADDR_LEN  3
>  #define SPI_FLASH_CMD_LEN  (1 + SPI_FLASH_3B_ADDR_LEN)
>  #define SPI_FLASH_16MB_BOUN0x100
> @@ -87,6 +92,19 @@ enum spi_nor_option_flags {
>
>  /* SST specific */
>  #ifdef CONFIG_SPI_FLASH_SST
> +#define SST26_CMD_READ_BPR 0x72
> +#define SST26_CMD_WRITE_BPR0x42
> +
> +#define SST26_BPR_8K_NUM   4
> +#define SST26_MAX_BPR_REG_LEN  (18 + 1)
> +#define SST26_BOUND_REG_SIZE   ((32 + SST26_BPR_8K_NUM * 8) * SZ_1K)
> +
> +enum lock_ctl {
> +   CTL_LOCK,
> +   CTL_UNLOCK,
> +   CTL_CHECK
> +};

SST26_CTL_* ?

> +
>  # define CMD_SST_BP0x02/* Byte Program */
>  # define CMD_SST_AAI_WP0xAD/* Auto Address Incr Word 
> Program */
>
> diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
> index 2e61685d3e..0f4e7fd5d4 100644
> --- a/drivers/mtd/spi/spi_flash.c
> +++ b/drivers/mtd/spi/spi_flash.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include "sf_internal.h"
> @@ -842,6 +843,161 @@ int stm_unlock(struct spi_flash *flash, u32 ofs, size_t 
> len)
>  }
>  #endif
>
> +#if defined(CONFIG_SPI_FLASH_SST)

Please move this code inside of existing #ifdef of SST (commented same
in previous version)

> +static bool sst26_process_bpr(u32 bpr_size, u8 *cmd, u32 bit, enum lock_ctl 
> ctl)
> +{
> +   switch (ctl) {
> +   case CTL_LOCK:
> +   cmd[bpr_size - (bit / 8) - 1] |= BIT(bit % 8);
> +   break;
> +   case CTL_UNLOCK:
> +   cmd[bpr_size - (bit / 8) - 1] &= ~BIT(bit % 8);
> +   break;
> +   case CTL_CHECK:
> +   return !!(cmd[bpr_size - (bit / 8) - 1] & BIT(bit % 
> 8));
> +   }
> +
> +   return false;
> +}
> +
> +/*
> + * sst26wf016/sst26wf032/sst26wf064 have next block protection:
> + * 4x   - 8  KByte blocks - read & write protection bits - upper addresses
> + * 1x   - 32 KByte blocks - write protection bits
> + * rest - 64 KByte blocks - write protection bits
> + * 1x   - 32 KByte blocks - write protection bits
> + * 4x   - 8  KByte blocks - read & write protection bits - lower addresses
> + *
> + * We'll support only per 64k lock/unlock so lower and upper 64 KByte region
> + * will be treated as single block.
> + */
> +
> +/*
> + * Lock, unlock or check lock status of the flash region of the flash 
> (depending
> + * on the lock_ctl value)
> + */
> +static int sst26_lock_ctl(struct spi_flash *flash, u32 ofs, size_t len, enum 
> lock_ctl ctl)
> +{
> +   u32 i, bpr_ptr, rptr_64k, lptr_64k, bpr_size;
> +   bool lower_64k = false, upper_64k = false;
> +   u8 cmd, bpr_buff[SST26_MAX_BPR_REG_LEN] = {};
> +   int ret;
> +
> +   /* Check length and offset for 64k alignment */
> +   if ((ofs & (SZ_64K - 1)) || (len & (SZ_64K - 1)))
> +   return -EINVAL;
> +
> +   if (ofs + len > flash->size)
> +   return -EINVAL;
> +
> +   /* SST26 family has only 16 Mbit, 32 Mbit and 64 Mbit IC */
> +   if (flash->size != SZ_2M &&
> +   flash->size != SZ_4M &&
> +   flash->size != SZ_8M)
> +   return -EINVAL;
> +
> +   bpr_size = 2 + (flash->size / SZ_64K / 8);
> +
> +   cmd = SST26_CMD_READ_BPR;
> +   ret = spi_flash_read_common(flash, , 1, bpr_buff, bpr_size);
> +   if (ret < 0) {
> +   printf("SF: fail to read block-protection register\n");
> +  

Re: [U-Boot] [PATCH] sunxi: improve SATAPWR and MACPWR

2018-04-09 Thread Maxime Ripard
Hi,

On Mon, Apr 09, 2018 at 12:17:26PM +0200, Mylène Josserand wrote:
> This commit adds a dependency on SATA for SATAPWR because
> if we do not have SATA enabled, we will not have this pin
> configured.
> 
> By default, these two configs (SATAPWR and MACPWR) are equals
> to "". Because of that, they are always defined so we need to
> check if the variables are not empty to perform the gpio request.
> Otherwise, if SATA is enabled but SATAPWR is not configured, we will have
> a mdelay of 500ms for nothing (because no pin requested).

You should turn this commit log the other way around. First state what
the issue is (you have a 500ms delay all the time, even when SATA is
not present on the board), then why (because SATAPWR will be defined
all the time to "", so the ifdef condition will always be evaluated to
true), then what you're doing about it (adding a depends on and
checking for strlen).

It's also not clear why you need both, and why just adding the depends
on wouldn't be enough.

> Signed-off-by: Mylène Josserand 
> ---
>  arch/arm/mach-sunxi/Kconfig |  1 +
>  board/sunxi/board.c | 21 +
>  2 files changed, 14 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index b868f0e350..7d36719700 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -911,6 +911,7 @@ endchoice
>  config SATAPWR
>   string "SATA power pin"
>   default ""
> + depends on SATA
>   help
> Set the pins used to power the SATA. This takes a string in the
> format understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 322dd9e23a..5b080607c1 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -230,16 +230,21 @@ int board_init(void)
>   return ret;
>  
>  #ifdef CONFIG_SATAPWR
> - satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
> - gpio_request(satapwr_pin, "satapwr");
> - gpio_direction_output(satapwr_pin, 1);
> - /* Give attached sata device time to power-up to avoid link timeouts */
> - mdelay(500);
> + if (strlen(CONFIG_SATAPWR)) {

What about if (IS_ENABLED(CONFIG_SATAPWR) && strlen(CONFIG_SATAPWR))

> + satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
> + gpio_request(satapwr_pin, "satapwr");
> + gpio_direction_output(satapwr_pin, 1);
> + /* Give attached sata device time to power-up to avoid link 
> timeouts */
> + mdelay(500);
> + }
>  #endif
> +
>  #ifdef CONFIG_MACPWR
> - macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
> - gpio_request(macpwr_pin, "macpwr");
> - gpio_direction_output(macpwr_pin, 1);
> + if (strlen(CONFIG_MACPWR)) {
> + macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
> + gpio_request(macpwr_pin, "macpwr");
> + gpio_direction_output(macpwr_pin, 1);
> + }

You should split that part in a separate commit.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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


[U-Boot] [PATCH v4 1/2] SPI Flash: add support of sst26wf* flash ICs protection ops

2018-04-09 Thread Eugeniy Paltsev
sst26wf flash series block protection implementation differs
from other SST series, so add specific implementation
flash_lock/flash_unlock/flash_is_locked functions for sst26wf
flash ICs.

Signed-off-by: Eugeniy Paltsev 
---
Changes v3->v4:
 * Make sst26_process_bpr() and sst26_lock_ctl() functions static.

Changes v2->v3:
 * Move SST26 command defenition to sf_internal.h
 * Merge sst26_set_bpr, sst26_clear_bpr and sst26_check_bpr functions
   into single sst26_process_bpr function.
 * Use SF_UNLOCKED/SF_LOCKED instead of magic numbers in
   sst26_lock_ctl()

Changes v1->v2:
 * Use generic defines from linux/sizes.h instead of custom ones.

 drivers/mtd/spi/sf_internal.h |  18 +
 drivers/mtd/spi/spi_flash.c   | 165 ++
 2 files changed, 183 insertions(+)

diff --git a/drivers/mtd/spi/sf_internal.h b/drivers/mtd/spi/sf_internal.h
index 839cdbe1b0..a17dcc4de1 100644
--- a/drivers/mtd/spi/sf_internal.h
+++ b/drivers/mtd/spi/sf_internal.h
@@ -26,6 +26,11 @@ enum spi_nor_option_flags {
SNOR_F_USE_UPAGE= BIT(3),
 };
 
+enum flash_lock_status {
+   SF_UNLOCKED = 0,
+   SF_LOCKED   = 1,
+};
+
 #define SPI_FLASH_3B_ADDR_LEN  3
 #define SPI_FLASH_CMD_LEN  (1 + SPI_FLASH_3B_ADDR_LEN)
 #define SPI_FLASH_16MB_BOUN0x100
@@ -87,6 +92,19 @@ enum spi_nor_option_flags {
 
 /* SST specific */
 #ifdef CONFIG_SPI_FLASH_SST
+#define SST26_CMD_READ_BPR 0x72
+#define SST26_CMD_WRITE_BPR0x42
+
+#define SST26_BPR_8K_NUM   4
+#define SST26_MAX_BPR_REG_LEN  (18 + 1)
+#define SST26_BOUND_REG_SIZE   ((32 + SST26_BPR_8K_NUM * 8) * SZ_1K)
+
+enum lock_ctl {
+   CTL_LOCK,
+   CTL_UNLOCK,
+   CTL_CHECK
+};
+
 # define CMD_SST_BP0x02/* Byte Program */
 # define CMD_SST_AAI_WP0xAD/* Auto Address Incr Word 
Program */
 
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index 2e61685d3e..0f4e7fd5d4 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "sf_internal.h"
@@ -842,6 +843,161 @@ int stm_unlock(struct spi_flash *flash, u32 ofs, size_t 
len)
 }
 #endif
 
+#if defined(CONFIG_SPI_FLASH_SST)
+static bool sst26_process_bpr(u32 bpr_size, u8 *cmd, u32 bit, enum lock_ctl 
ctl)
+{
+   switch (ctl) {
+   case CTL_LOCK:
+   cmd[bpr_size - (bit / 8) - 1] |= BIT(bit % 8);
+   break;
+   case CTL_UNLOCK:
+   cmd[bpr_size - (bit / 8) - 1] &= ~BIT(bit % 8);
+   break;
+   case CTL_CHECK:
+   return !!(cmd[bpr_size - (bit / 8) - 1] & BIT(bit % 8));
+   }
+
+   return false;
+}
+
+/*
+ * sst26wf016/sst26wf032/sst26wf064 have next block protection:
+ * 4x   - 8  KByte blocks - read & write protection bits - upper addresses
+ * 1x   - 32 KByte blocks - write protection bits
+ * rest - 64 KByte blocks - write protection bits
+ * 1x   - 32 KByte blocks - write protection bits
+ * 4x   - 8  KByte blocks - read & write protection bits - lower addresses
+ *
+ * We'll support only per 64k lock/unlock so lower and upper 64 KByte region
+ * will be treated as single block.
+ */
+
+/*
+ * Lock, unlock or check lock status of the flash region of the flash 
(depending
+ * on the lock_ctl value)
+ */
+static int sst26_lock_ctl(struct spi_flash *flash, u32 ofs, size_t len, enum 
lock_ctl ctl)
+{
+   u32 i, bpr_ptr, rptr_64k, lptr_64k, bpr_size;
+   bool lower_64k = false, upper_64k = false;
+   u8 cmd, bpr_buff[SST26_MAX_BPR_REG_LEN] = {};
+   int ret;
+
+   /* Check length and offset for 64k alignment */
+   if ((ofs & (SZ_64K - 1)) || (len & (SZ_64K - 1)))
+   return -EINVAL;
+
+   if (ofs + len > flash->size)
+   return -EINVAL;
+
+   /* SST26 family has only 16 Mbit, 32 Mbit and 64 Mbit IC */
+   if (flash->size != SZ_2M &&
+   flash->size != SZ_4M &&
+   flash->size != SZ_8M)
+   return -EINVAL;
+
+   bpr_size = 2 + (flash->size / SZ_64K / 8);
+
+   cmd = SST26_CMD_READ_BPR;
+   ret = spi_flash_read_common(flash, , 1, bpr_buff, bpr_size);
+   if (ret < 0) {
+   printf("SF: fail to read block-protection register\n");
+   return ret;
+   }
+
+   rptr_64k = min_t(u32, ofs + len , flash->size - SST26_BOUND_REG_SIZE);
+   lptr_64k = max_t(u32, ofs, SST26_BOUND_REG_SIZE);
+
+   upper_64k = ((ofs + len) > (flash->size - SST26_BOUND_REG_SIZE));
+   lower_64k = (ofs < SST26_BOUND_REG_SIZE);
+
+   /* Lower bits in block-protection register are about 64k region */
+   bpr_ptr = lptr_64k / SZ_64K - 1;
+
+   /* Process 64K blocks region */
+   while (lptr_64k < rptr_64k) {
+   if 

[U-Boot] [PATCH v4 2/2] SF: add support for sst26wf016, sst26wf032, sst26wf064

2018-04-09 Thread Eugeniy Paltsev
This commit adds support for the SST sst26wf016, sst26wf032
and sst26wf064 flash IC.

Signed-off-by: Eugeniy Paltsev 
---
Changes v3->v4:
 * None.

Changes v2->v3:
 * None.

Changes v1->v2:
 * None.

 drivers/mtd/spi/spi_flash_ids.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
index b789219e4e..dbb4ac4d32 100644
--- a/drivers/mtd/spi/spi_flash_ids.c
+++ b/drivers/mtd/spi/spi_flash_ids.c
@@ -151,6 +151,9 @@ const struct spi_flash_info spi_flash_ids[] = {
{"sst25wf040", INFO(0xbf2504, 0x0,  64 * 1024, 8, SECT_4K | 
SST_WR) },
{"sst25wf040b",INFO(0x621613, 0x0,  64 * 1024, 8, SECT_4K) },
{"sst25wf080", INFO(0xbf2505, 0x0,  64 * 1024,16, SECT_4K | 
SST_WR) },
+   {"sst26wf016", INFO(0xbf2651, 0x0,  64 * 1024,32, SECT_4K) },
+   {"sst26wf032", INFO(0xbf2622, 0x0,  64 * 1024,64, SECT_4K) },
+   {"sst26wf064", INFO(0xbf2643, 0x0,  64 * 1024,   128, SECT_4K) },
 #endif
 #ifdef CONFIG_SPI_FLASH_WINBOND/* WINBOND */
{"w25p80", INFO(0xef2014, 0x0,  64 * 1024,16, 0) },
-- 
2.14.3

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


[U-Boot] [PATCH v4 0/2] SF: add support for sst26wf016, sst26wf032, sst26wf064

2018-04-09 Thread Eugeniy Paltsev
Add support for the SST sst26wf016, sst26wf032 and sst26wf064 flash IC:

sst26wf*** flash series block protection implementation differs from other
SST series, so we add implementation for sst26wf*** lock/unlock/is_locked
functions.

Add sst26wf016, sst26wf032 and sst26wf064 flash IC info to spi_flash_ids list.

Changes v3->v4:
 * Make sst26_process_bpr() and sst26_lock_ctl() functions static.

Changes v2->v3:
 * Move SST26 command defenition to sf_internal.h
 * Merge sst26_set_bpr, sst26_clear_bpr and sst26_check_bpr functions
   into single sst26_process_bpr function.
 * Use SF_UNLOCKED/SF_LOCKED instead of magic numbers in
   sst26_lock_ctl()

Changes v1->v2:
 * Use generic defines from linux/sizes.h instead of custom ones.

Eugeniy Paltsev (2):
  SPI Flash: add support of sst26wf* flash ICs protection ops
  SF: add support for sst26wf016, sst26wf032, sst26wf064

 drivers/mtd/spi/sf_internal.h   |  18 +
 drivers/mtd/spi/spi_flash.c | 165 
 drivers/mtd/spi/spi_flash_ids.c |   3 +
 3 files changed, 186 insertions(+)

-- 
2.14.3

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


[U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Guillaume Gardet

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) with latest 
master (and also 2018.05-rc1 and 2018.03).

eMMC is ok, but SD card access leads to 'unable to select a mode' problem. If I 
disable HS mode, I can access the SD card without problem:

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
 }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to select a 
mode' error */
+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

 cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }


Once we try to select HS mode, all access to SD card result in failure, even 
when trying to setup a lower frequency mode, including SD legacy at 25 MHz.

Any idea what is going? Maybe you have fixes pending?


Guillaume


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


[U-Boot] [PATCH] sunxi: A64/H5 devices: enable usb keyboard support

2018-04-09 Thread Peter Robinson
Now the A64/H5 SoCs support video output it's useful to enable usb keyboard
support so console can be used via standard keyboard/video interface.

Tested on Pine64.

Signed-off-by: Peter Robinson 
---
 configs/a64-olinuxino_defconfig   | 2 ++
 configs/bananapi_m64_defconfig| 2 ++
 configs/nanopi_a64_defconfig  | 2 ++
 configs/nanopi_neo2_defconfig | 2 ++
 configs/nanopi_neo_plus2_defconfig| 2 ++
 configs/orangepi_pc2_defconfig| 2 ++
 configs/orangepi_win_defconfig| 2 ++
 configs/orangepi_zero_plus2_defconfig | 2 ++
 configs/pine64_plus_defconfig | 2 ++
 configs/sopine_baseboard_defconfig| 2 ++
 10 files changed, 20 insertions(+)

diff --git a/configs/a64-olinuxino_defconfig b/configs/a64-olinuxino_defconfig
index 6edefa4f67..c4cdec4771 100644
--- a/configs/a64-olinuxino_defconfig
+++ b/configs/a64-olinuxino_defconfig
@@ -13,3 +13,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-olinuxino"
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_DM_KEYBOARD=y
+CONFIG_USB_KEYBOARD=y
diff --git a/configs/bananapi_m64_defconfig b/configs/bananapi_m64_defconfig
index 60cbfd9b2b..4174dd7aac 100644
--- a/configs/bananapi_m64_defconfig
+++ b/configs/bananapi_m64_defconfig
@@ -14,3 +14,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-bananapi-m64"
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_DM_KEYBOARD=y
+CONFIG_USB_KEYBOARD=y
diff --git a/configs/nanopi_a64_defconfig b/configs/nanopi_a64_defconfig
index 122fcc5794..3bef473d48 100644
--- a/configs/nanopi_a64_defconfig
+++ b/configs/nanopi_a64_defconfig
@@ -12,3 +12,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-nanopi-a64"
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_DM_KEYBOARD=y
+CONFIG_USB_KEYBOARD=y
diff --git a/configs/nanopi_neo2_defconfig b/configs/nanopi_neo2_defconfig
index f27529d7d4..6622a186f3 100644
--- a/configs/nanopi_neo2_defconfig
+++ b/configs/nanopi_neo2_defconfig
@@ -13,3 +13,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-nanopi-neo2"
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_DM_KEYBOARD=y
+CONFIG_USB_KEYBOARD=y
diff --git a/configs/nanopi_neo_plus2_defconfig 
b/configs/nanopi_neo_plus2_defconfig
index 5f69799e06..1c6ad4647d 100644
--- a/configs/nanopi_neo_plus2_defconfig
+++ b/configs/nanopi_neo_plus2_defconfig
@@ -14,3 +14,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-nanopi-neo-plus2"
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_DM_KEYBOARD=y
+CONFIG_USB_KEYBOARD=y
diff --git a/configs/orangepi_pc2_defconfig b/configs/orangepi_pc2_defconfig
index 893780a0f7..7d01e6f27c 100644
--- a/configs/orangepi_pc2_defconfig
+++ b/configs/orangepi_pc2_defconfig
@@ -15,3 +15,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-orangepi-pc2"
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_DM_KEYBOARD=y
+CONFIG_USB_KEYBOARD=y
diff --git a/configs/orangepi_win_defconfig b/configs/orangepi_win_defconfig
index 0fd297752d..85f0731c3c 100644
--- a/configs/orangepi_win_defconfig
+++ b/configs/orangepi_win_defconfig
@@ -13,3 +13,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-orangepi-win"
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_DM_KEYBOARD=y
+CONFIG_USB_KEYBOARD=y
diff --git a/configs/orangepi_zero_plus2_defconfig 
b/configs/orangepi_zero_plus2_defconfig
index b48f13e7b1..4f1f008ea8 100644
--- a/configs/orangepi_zero_plus2_defconfig
+++ b/configs/orangepi_zero_plus2_defconfig
@@ -15,3 +15,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-orangepi-zero-plus2"
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_DM_KEYBOARD=y
+CONFIG_USB_KEYBOARD=y
diff --git a/configs/pine64_plus_defconfig b/configs/pine64_plus_defconfig
index 23365a57c3..42281a9d7d 100644
--- a/configs/pine64_plus_defconfig
+++ b/configs/pine64_plus_defconfig
@@ -15,3 +15,5 @@ CONFIG_RTL8211E_PINE64_GIGABIT_FIX=y
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_DM_KEYBOARD=y
+CONFIG_USB_KEYBOARD=y
diff --git a/configs/sopine_baseboard_defconfig 
b/configs/sopine_baseboard_defconfig
index 503e3903ca..30cb6b93d0 100644
--- a/configs/sopine_baseboard_defconfig
+++ b/configs/sopine_baseboard_defconfig
@@ -19,3 +19,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus"
 CONFIG_SUN8I_EMAC=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_DM_KEYBOARD=y
+CONFIG_USB_KEYBOARD=y
-- 
2.17.0

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


Re: [U-Boot] [PATCH v1 0/2] Fix DM_SCSI on DRA7 platforms

2018-04-09 Thread Michal Simek
On 6.4.2018 15:58, Jean-Jacques Hiblot wrote:
> 
> 
> On 06/04/2018 14:00, Michal Simek wrote:
>> Hi,
>>
>> On 6.4.2018 11:13, Jean-Jacques Hiblot wrote:
>>> Enhancements to SCSI support for driver model have broken the support
>>> for
>>> DM_SCSI on DRA7 platforms. This series fixes it.
>>>
>>> Tested on:
>>> - dra76 evm
>>>
>>>
>>> Jean-Jacques Hiblot (2):
>>>    dwc_ahci: Fix breakage
>>>    configs: dra7xx_evm/dra7xx_hs_evm: Enable AHCI and PIPE3
>>>
>>>   configs/dra7xx_evm_defconfig    |  2 ++
>>>   configs/dra7xx_hs_evm_defconfig |  2 ++
>>>   drivers/ata/dwc_ahci.c  | 23 ++-
>>>   3 files changed, 14 insertions(+), 13 deletions(-)
>>>
>> I have seen similar issue with 2018.01 release but I have just tested it
>> with sata_ceva.c on latest on zcu102 and I can't see any issue.
>>
>> Here was my quick hack.
>> https://github.com/Xilinx/u-boot-xlnx/commit/df365a0d76352c4b675444c660cc4eb53b36d51e
>>
>>
>> Anyway I have used your patch as source of changes for ceva sata and I
>> have tested it on the top of latest and also on xilinx v2018.1(+ revert
>> of my hack) and it is working properly.
>>
>> Anyway I think that will be good if you can retest driver on the HEAD
> I'm not sure I understand what you mean by HEAD.
> I had tested the disk with commit
> e294ba0678359bc32085c1714329af37e33e8f16 (4th april, so pretty recent),
> it didn't work.


HEAD - latest u-boot commit in master branch.

> Honestly I haven't tried to understand the reason why it broke, I just
> modified the driver to match was is done in the straightforward PCI driver.

Ok. I get it.

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


Re: [U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Guillaume Gardet



Le 09/04/2018 à 15:58, Jean-Jacques Hiblot a écrit :



On 09/04/2018 14:02, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) with latest 
master (and also 2018.05-rc1 and 2018.03).

eMMC is ok, but SD card access leads to 'unable to select a mode' problem. If I 
disable HS mode, I can access the SD card without problem:

diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, struct 
dwmci_host *host,
     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
 }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to select a 
mode' error */
+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

 cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }


Once we try to select HS mode, all access to SD card result in failure, even 
when trying to setup a lower frequency mode, including SD legacy at 25 MHz.

Any idea what is going? Maybe you have fixes pending?


Can try with MMC_MODE_HS | MMC_MODE_HS_52MHz but with a lower max-frequency 
(<25MHz) ? It would be interesting to know if it could come from a frequency 
limitation.


I already tried to change SD_HS freq (in mmc_mode2freq) from 5000 to 
2500 with no difference.


Is there some pad configuration to do when using higher frequency?


I do not think so.

Guillaume





JJ




Guillaume








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


Re: [U-Boot] [PATCH v2] arm64: Add SMC and HVC commands

2018-04-09 Thread Michalis Pappas


On 04/09/2018 04:25 PM, Tom Rini wrote:

On Mon, Apr 09, 2018 at 04:11:01PM +0300, Michalis Pappas wrote:

This patch adds smc and hvc commands, that allow issuing Secure Monitor
Calls and Hypervisor Calls conforming to the ARM SMC Calling Convention.

Add Kconfig items to allow each command can be individually enabled.

Signed-off-by: Michalis Pappas 
---

  cmd/Kconfig  | 14 ++
  cmd/Makefile |  2 ++
  cmd/smccc.c  | 72 
  3 files changed, 88 insertions(+)
  create mode 100644 cmd/smccc.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 136836d146..a2b09620f3 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1348,6 +1348,20 @@ config CMD_HASH
  saved to memory or to an environment variable. It is also possible
  to verify a hash against data in memory.

+config CMD_HVC
+   bool "Support the 'hvc' command"
+   depends on ARM64
+   help
+ Allows issuing Hypervisor Calls (HVCs). Mostly useful for
+ development and testing.
+
+config CMD_SMC
+   bool "Support the 'smc' command"
+   depends on ARM64
+   help
+ Allows issuing Secure Monitor Calls (SMCs). Mostly useful for
+ development and testing.

Sorry for not catching this before, in both cases we should depend on
ARM_SMCC as that's what provides the underlying functions and is
available on both ARMv7 and ARMv8.



Ah, you're right, I should had spotted that too. Will replace the ARM64 
dependendy with ARM_SMCCC and issue another patch.


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


Re: [U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Jean-Jacques Hiblot



On 09/04/2018 16:03, Guillaume Gardet wrote:



Le 09/04/2018 à 15:58, Jean-Jacques Hiblot a écrit :



On 09/04/2018 14:02, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) 
with latest master (and also 2018.05-rc1 and 2018.03).


eMMC is ok, but SD card access leads to 'unable to select a mode' 
problem. If I disable HS mode, I can access the SD card without 
problem:
 


diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, 
struct dwmci_host *host,

     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
 }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to 
select a mode' error */

+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

 cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }
 



Once we try to select HS mode, all access to SD card result in 
failure, even when trying to setup a lower frequency mode, including 
SD legacy at 25 MHz.


Any idea what is going? Maybe you have fixes pending?


Can try with MMC_MODE_HS | MMC_MODE_HS_52MHz but with a lower 
max-frequency (<25MHz) ? It would be interesting to know if it could 
come from a frequency limitation.


I already tried to change SD_HS freq (in mmc_mode2freq) from 5000 
to 2500 with no difference.



Is there some pad configuration to do when using higher frequency?


I do not think so.

Can you enable the debug output and post a log ?


Guillaume





JJ




Guillaume











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


Re: [U-Boot] [PATCH] sunxi: improve SATAPWR and MACPWR

2018-04-09 Thread Mylène Josserand
Hi,

On Mon, 9 Apr 2018 13:42:28 +0200
Maxime Ripard  wrote:

> Hi,
> 
> On Mon, Apr 09, 2018 at 12:17:26PM +0200, Mylène Josserand wrote:
> > This commit adds a dependency on SATA for SATAPWR because
> > if we do not have SATA enabled, we will not have this pin
> > configured.
> > 
> > By default, these two configs (SATAPWR and MACPWR) are equals
> > to "". Because of that, they are always defined so we need to
> > check if the variables are not empty to perform the gpio request.
> > Otherwise, if SATA is enabled but SATAPWR is not configured, we will have
> > a mdelay of 500ms for nothing (because no pin requested).  
> 
> You should turn this commit log the other way around. First state what
> the issue is (you have a 500ms delay all the time, even when SATA is
> not present on the board), then why (because SATAPWR will be defined
> all the time to "", so the ifdef condition will always be evaluated to
> true), then what you're doing about it (adding a depends on and
> checking for strlen).
> 
> It's also not clear why you need both, and why just adding the depends
> on wouldn't be enough.

Okay, thank you for the review, I will try to be more precise in
my commit log.

> 
> > Signed-off-by: Mylène Josserand 
> > ---
> >  arch/arm/mach-sunxi/Kconfig |  1 +
> >  board/sunxi/board.c | 21 +
> >  2 files changed, 14 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index b868f0e350..7d36719700 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -911,6 +911,7 @@ endchoice
> >  config SATAPWR
> > string "SATA power pin"
> > default ""
> > +   depends on SATA
> > help
> >   Set the pins used to power the SATA. This takes a string in the
> >   format understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of
> > diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> > index 322dd9e23a..5b080607c1 100644
> > --- a/board/sunxi/board.c
> > +++ b/board/sunxi/board.c
> > @@ -230,16 +230,21 @@ int board_init(void)
> > return ret;
> >  
> >  #ifdef CONFIG_SATAPWR
> > -   satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
> > -   gpio_request(satapwr_pin, "satapwr");
> > -   gpio_direction_output(satapwr_pin, 1);
> > -   /* Give attached sata device time to power-up to avoid link timeouts */
> > -   mdelay(500);
> > +   if (strlen(CONFIG_SATAPWR)) {  
> 
> What about if (IS_ENABLED(CONFIG_SATAPWR) && strlen(CONFIG_SATAPWR))

You already indicated me this (privately) and I tested it.
I finally did not use it because "IS_ENABLED" seems to work only for
boolean or tristate options. When I tested it, it fails to recognize
the configuration because it is a "string", I guess.
Here is the error I got:

error: pasting "__ARG_PLACEHOLDER_" and  does not give a valid
preprocessing token

Moreover, in case CONFIG_SATA is not enabled, it leads also to an error
on "strlen" function because CONFIG_SATAPWR is not defined anymore.

That is why I kept the use of "#ifdef CONFIG_SATAPWR".

> 
> > +   satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
> > +   gpio_request(satapwr_pin, "satapwr");
> > +   gpio_direction_output(satapwr_pin, 1);
> > +   /* Give attached sata device time to power-up to avoid link 
> > timeouts */
> > +   mdelay(500);
> > +   }
> >  #endif
> > +
> >  #ifdef CONFIG_MACPWR
> > -   macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
> > -   gpio_request(macpwr_pin, "macpwr");
> > -   gpio_direction_output(macpwr_pin, 1);
> > +   if (strlen(CONFIG_MACPWR)) {
> > +   macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
> > +   gpio_request(macpwr_pin, "macpwr");
> > +   gpio_direction_output(macpwr_pin, 1);
> > +   }  
> 
> You should split that part in a separate commit.

ack.

Best regards,

Mylène

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


Re: [U-Boot] [PATCH] sunxi: A64/H5 devices: enable usb keyboard support

2018-04-09 Thread Maxime Ripard
On Mon, Apr 09, 2018 at 01:15:00PM +0100, Peter Robinson wrote:
> Now the A64/H5 SoCs support video output it's useful to enable usb keyboard
> support so console can be used via standard keyboard/video interface.
> 
> Tested on Pine64.
> 
> Signed-off-by: Peter Robinson 

Don't forget any maintainers when you're sending a patch :)

> ---
>  configs/a64-olinuxino_defconfig   | 2 ++
>  configs/bananapi_m64_defconfig| 2 ++
>  configs/nanopi_a64_defconfig  | 2 ++
>  configs/nanopi_neo2_defconfig | 2 ++
>  configs/nanopi_neo_plus2_defconfig| 2 ++
>  configs/orangepi_pc2_defconfig| 2 ++
>  configs/orangepi_win_defconfig| 2 ++
>  configs/orangepi_zero_plus2_defconfig | 2 ++
>  configs/pine64_plus_defconfig | 2 ++
>  configs/sopine_baseboard_defconfig| 2 ++
>  10 files changed, 20 insertions(+)
> 
> diff --git a/configs/a64-olinuxino_defconfig b/configs/a64-olinuxino_defconfig
> index 6edefa4f67..c4cdec4771 100644
> --- a/configs/a64-olinuxino_defconfig
> +++ b/configs/a64-olinuxino_defconfig
> @@ -13,3 +13,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-olinuxino"
>  CONFIG_SUN8I_EMAC=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
> +CONFIG_DM_KEYBOARD=y
> +CONFIG_USB_KEYBOARD=y

Both are already selected by ARCH_SUNXI if DISTRO_DEFAULTS is set. In
turn, DISTRO_DEFAULTS is enabled by default if ARCH_SUNXI is. Why do
you need to enable it in the defconfig?

If this doesn't work for some reason, this should be fixed at the
Kconfig level, not in the defconfig.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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] sunxi: A64/H5 devices: enable usb keyboard support

2018-04-09 Thread Peter Robinson
On Mon, Apr 9, 2018 at 1:53 PM, Maxime Ripard  wrote:
> On Mon, Apr 09, 2018 at 01:15:00PM +0100, Peter Robinson wrote:
>> Now the A64/H5 SoCs support video output it's useful to enable usb keyboard
>> support so console can be used via standard keyboard/video interface.
>>
>> Tested on Pine64.
>>
>> Signed-off-by: Peter Robinson 
>
> Don't forget any maintainers when you're sending a patch :)

The list in the cc: is what ./scripts/get_maintainer.pl returned when
run against the patch

>> ---
>>  configs/a64-olinuxino_defconfig   | 2 ++
>>  configs/bananapi_m64_defconfig| 2 ++
>>  configs/nanopi_a64_defconfig  | 2 ++
>>  configs/nanopi_neo2_defconfig | 2 ++
>>  configs/nanopi_neo_plus2_defconfig| 2 ++
>>  configs/orangepi_pc2_defconfig| 2 ++
>>  configs/orangepi_win_defconfig| 2 ++
>>  configs/orangepi_zero_plus2_defconfig | 2 ++
>>  configs/pine64_plus_defconfig | 2 ++
>>  configs/sopine_baseboard_defconfig| 2 ++
>>  10 files changed, 20 insertions(+)
>>
>> diff --git a/configs/a64-olinuxino_defconfig 
>> b/configs/a64-olinuxino_defconfig
>> index 6edefa4f67..c4cdec4771 100644
>> --- a/configs/a64-olinuxino_defconfig
>> +++ b/configs/a64-olinuxino_defconfig
>> @@ -13,3 +13,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-olinuxino"
>>  CONFIG_SUN8I_EMAC=y
>>  CONFIG_USB_EHCI_HCD=y
>>  CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
>> +CONFIG_DM_KEYBOARD=y
>> +CONFIG_USB_KEYBOARD=y
>
> Both are already selected by ARCH_SUNXI if DISTRO_DEFAULTS is set. In
> turn, DISTRO_DEFAULTS is enabled by default if ARCH_SUNXI is. Why do
> you need to enable it in the defconfig?
>
> If this doesn't work for some reason, this should be fixed at the
> Kconfig level, not in the defconfig.
>
> Maxime
>
> --
> Maxime Ripard, 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] treewide: fix up files incorrectly marked executable

2018-04-09 Thread Anatolij Gustschin
Hi Fabio,

On Sat,  7 Apr 2018 18:06:27 -0300
Fabio Estevam feste...@gmail.com wrote:
...
> Do the same in the U-Boot source tree.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  drivers/video/anx9804.c   | 0
>  include/configs/blanche.h | 0
>  2 files changed, 0 insertions(+), 0 deletions(-)
>  mode change 100755 => 100644 drivers/video/anx9804.c
>  mode change 100755 => 100644 include/configs/blanche.h

Applied to u-boot-video/master, thanks!

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


[U-Boot] [usb dwc3] xHCI driver -- a hint needed.

2018-04-09 Thread Yuri Frolov

Hi,

I've been trying to bring up a dwc3 usb controller included in 32-bit MIPS chip.
Usb is the one port usb2.0 host module, compliant with xHCI Revision 1.0, UTMI+ 
Low Pin interface (ULPI) Revision 1.1 and AMBA AXI Protocol specification. 
g_snpsid register reports 0x5533290a revision.

It's verified, that linux kernel support is ok, usb is fully functional.

axi {
<...>

usb@1F04D050 {
compatible = "be,baikal-dwc3";
reg = <0x1f04d050 0x4>;
interrupts = <0x0 0x45 0x4>;
#address-cells = <0x1>;
#size-cells = <0x1>;
clocks = <0xf 0x0>;
clock-names = "usb";
ranges;
status = "okay";

dwc3@1F10 {
compatible = "snps,dwc3", "synopsys,dwc3", 
"generic-xhci";
reg = <0x1f10 0x1>;
interrupts = <0x0 0x44 0x4>;
dr_mode = "host";
tx-fifo-resize;
maximum-speed = "high-speed";
};
};
};

whereas in u-boot 'usb start' fails on hub initialization (as I can see):

Any ideas why this could happen?.. Any direction where to look at?
Any suggestions will be greatly appreciated.

# usb start
(Re)start USB...
USB0:   dwc3_reg->g_snpsid: 0x5533290a
Register 1000140 NbrPorts 1
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... New Device 0
set address 1
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 
0x12
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 
0x9
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 
0x1F
get_conf_no 0 Result 25, wLength 31
if 0, ep 0
##EP epmaxpacketin[1] = 8
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0
new device strings: Mfr=1, Product=2, SerialNumber=0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 
0xFF
USB device number 1 default language ID 0x409
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 
length 0xFF
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409 
length 0xFF
Manufacturer U-Boot
Product  XHCI Host Controller
SerialNumber
USB hub found
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 
0x4
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 
0xC
1 ports detected
ganged power switching
standalone hub
individual port over-current protection
TT requires at most 8 FS bit times (666 ns)
power on to power good time: 20ms
hub controller current requirement: 0mA
port 1 is removable
usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4
get_hub_status returned status 1, change 801
local power source is lost (inactive)
no over-current condition exists
enabling power on all ports
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0
port 1 returns 0
devnum=1 poweron: query_delay=100 connect_timeout=1100
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
Port 1 Status 101 Change 1
devnum=1 port=1: USB dev found
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
portstatus 101, change 1, 12 Mb/s
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 
0x0
usb_hub_port_reset: resetting port 1...
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
portstatus 111, change 0, 12 Mb/s
STAT_C_CONNECTION = 0 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 0
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
portstatus 503, change 10, 480 Mb/s
STAT_C_CONNECTION = 0 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 1
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 
0x0
New Device 1
XHCI timeout on event type 33... cannot recover.
BUG: failure at drivers/usb/host/xhci-ring.c:474/xhci_wait_for_event()!
BUG!
Reset CPU by CPC

Here is the drivers/usb/host/xhci-baikal.c:

#include 
#include 
#include 

#include 
#include 
#include 

#include "xhci.h"

/* Declare global data pointer */
DECLARE_GLOBAL_DATA_PTR;

struct baikal_xhci {
struct xhci_hccr *hcd;
struct dwc3 *dwc3_reg;
};

static struct baikal_xhci baikal;

int __attribute__((weak)) board_usb_init(int index, enum usb_init_type init);

static int baikal_xhci_core_init(struct 

[U-Boot] [PATCH v2] arm64: Add SMC and HVC commands

2018-04-09 Thread Michalis Pappas
This patch adds smc and hvc commands, that allow issuing Secure Monitor
Calls and Hypervisor Calls conforming to the ARM SMC Calling Convention.

Add Kconfig items to allow each command can be individually enabled.

Signed-off-by: Michalis Pappas 
---

 cmd/Kconfig  | 14 ++
 cmd/Makefile |  2 ++
 cmd/smccc.c  | 72 
 3 files changed, 88 insertions(+)
 create mode 100644 cmd/smccc.c

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 136836d146..a2b09620f3 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1348,6 +1348,20 @@ config CMD_HASH
  saved to memory or to an environment variable. It is also possible
  to verify a hash against data in memory.

+config CMD_HVC
+   bool "Support the 'hvc' command"
+   depends on ARM64
+   help
+ Allows issuing Hypervisor Calls (HVCs). Mostly useful for
+ development and testing.
+
+config CMD_SMC
+   bool "Support the 'smc' command"
+   depends on ARM64
+   help
+ Allows issuing Secure Monitor Calls (SMCs). Mostly useful for
+ development and testing.
+
 config HASH_VERIFY
bool "hash -v"
depends on CMD_HASH
diff --git a/cmd/Makefile b/cmd/Makefile
index 9a358e4801..5656a1a40a 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_CMD_FS_GENERIC) += fs.o
 obj-$(CONFIG_CMD_FUSE) += fuse.o
 obj-$(CONFIG_CMD_GETTIME) += gettime.o
 obj-$(CONFIG_CMD_GPIO) += gpio.o
+obj-$(CONFIG_CMD_HVC) += smccc.o
 obj-$(CONFIG_CMD_I2C) += i2c.o
 obj-$(CONFIG_CMD_IOTRACE) += iotrace.o
 obj-$(CONFIG_CMD_HASH) += hash.o
@@ -113,6 +114,7 @@ obj-$(CONFIG_CMD_SHA1SUM) += sha1sum.o
 obj-$(CONFIG_CMD_SETEXPR) += setexpr.o
 obj-$(CONFIG_CMD_SPI) += spi.o
 obj-$(CONFIG_CMD_STRINGS) += strings.o
+obj-$(CONFIG_CMD_SMC) += smccc.o
 obj-$(CONFIG_CMD_TERMINAL) += terminal.o
 obj-$(CONFIG_CMD_TIME) += time.o
 obj-$(CONFIG_CMD_TRACE) += trace.o
diff --git a/cmd/smccc.c b/cmd/smccc.c
new file mode 100644
index 00..2fa7c23999
--- /dev/null
+++ b/cmd/smccc.c
@@ -0,0 +1,72 @@
+/*
+ * Copyright 2018
+ * Michalis Pappas 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int do_call(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   struct arm_smccc_res res;
+
+   unsigned long fid;
+
+   unsigned long a1;
+   unsigned long a2;
+   unsigned long a3;
+   unsigned long a4;
+   unsigned long a5;
+   unsigned long a6;
+   unsigned long a7;
+
+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   fid = simple_strtoul(argv[1], NULL, 16);
+
+   a1 = argc > 2 ? simple_strtoul(argv[2], NULL, 16) : 0;
+   a2 = argc > 3 ? simple_strtoul(argv[3], NULL, 16) : 0;
+   a3 = argc > 4 ? simple_strtoul(argv[4], NULL, 16) : 0;
+   a4 = argc > 5 ? simple_strtoul(argv[5], NULL, 16) : 0;
+   a5 = argc > 6 ? simple_strtoul(argv[6], NULL, 16) : 0;
+   a6 = argc > 7 ? simple_strtoul(argv[7], NULL, 16) : 0;
+   a7 = argc > 8 ? simple_strtoul(argv[8], NULL, 16) : 0;
+
+   if (!strcmp(argv[0], "smc"))
+   arm_smccc_smc(fid, a1, a2, a3, a4, a5, a6, a7, );
+   else
+   arm_smccc_hvc(fid, a1, a2, a3, a4, a5, a6, a7, );
+
+   printf("Res:  %ld %ld %ld %ld\n", res.a0, res.a1, res.a2, res.a3);
+
+   return 0;
+}
+
+#ifdef CONFIG_CMD_SMC
+U_BOOT_CMD(
+   smc,8,  2,  do_call,
+   "Issue a Secure Monitor Call",
+   " [arg1 ... arg6] [id]\n"
+   "  - fid Function ID\n"
+   "  - arg SMC arguments, passed to X1-X6 (default to zero)\n"
+   "  - id  Secure OS ID / Session ID, passed to W7 (defaults to zero)\n"
+);
+#endif
+
+#ifdef CONFIG_CMD_HVC
+U_BOOT_CMD(
+   hvc,8,  2,  do_call,
+   "Issue a Hypervisor Call",
+   " [arg1...arg7] [id]\n"
+   "  - fid Function ID\n"
+   "  - arg HVC arguments, passed to X1-X6 (default to zero)\n"
+   "  - id  Session ID, passed to W7 (defaults to zero)\n"
+);
+#endif
+
--
2.17.0

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


Re: [U-Boot] [PATCH] kconfig: add CONFIG_CC_COVERAGE

2018-04-09 Thread Tom Rini
On Mon, Apr 09, 2018 at 10:01:59AM +0200, Christian Gmeiner wrote:
> Hi
> 
> 2018-04-08 16:30 GMT+02:00 Tom Rini :
> > On Thu, Mar 29, 2018 at 09:49:30AM +0200, Christian Gmeiner wrote:
> >
> >> Make it possible to use gcc code coverage analysis.
> >>
> >> Signed-off-by: Christian Gmeiner 
> >> ---
> >>  .gitignore | 4 
> >>  Kconfig| 8 
> >>  Makefile   | 6 ++
> >>  3 files changed, 18 insertions(+)
> >>
> >> diff --git a/.gitignore b/.gitignore
> >> index 29757aa51e..f1b801579c 100644
> >> --- a/.gitignore
> >> +++ b/.gitignore
> >> @@ -85,3 +85,7 @@ GTAGS
> >>  *.orig
> >>  *~
> >>  \#*#
> >> +
> >> +# gcc code coverage files
> >> +*.gcda
> >> +*.gcno
> >> diff --git a/Kconfig b/Kconfig
> >> index 6670913799..f092f72b25 100644
> >> --- a/Kconfig
> >> +++ b/Kconfig
> >> @@ -59,6 +59,14 @@ config CC_OPTIMIZE_FOR_SIZE
> >>
> >> This option is enabled by default for U-Boot.
> >>
> >> +config CC_COVERAGE
> >> + bool "Enable code coverage analysis"
> >> + default n
> >> + depends on SANDBOX
> >> + help
> >> +   Enabling this option will pass "--coverage" to gcc to compile
> >> +   and link code instrumented for coverage analysis.
> >
> > We shouldn't need default n, as that is the normal default.  And why is
> > this only on SANDBOX?
> >
> 
> The default thing will get fixed in V2. If we want to record code coverage on
> real hardware we need to add an infrastructure to store the generated analysis
> data. In the sandbox case this information is stored in the local
> filesystem (*.gcda).
> To get a feeling what may be needs to be done for the real target patch have a
> look at:
> https://mcuoneclipse.com/2014/12/26/code-coverage-for-embedded-target-with-eclipse-gcc-and-gcov/
> 
> My goal is it to get some code coverage data for unit tests that are run in 
> the
> sandboxed environment.
> 
> Is it okay for you to only cover the sandbox case or do you want/need
> the full blown
> solution?

While it would be cool to do this on real hardware, I guess that makes
sense to do in a follow up.  Thanks for explaining!

-- 
Tom


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


[U-Boot] [PULL] efi patch queue 2018-04-09

2018-04-09 Thread Alexander Graf
Hi Tom,

Sorry the previous request failed travis checks. This one passes.

This is my current patch queue for efi.  Please pull.

Alex


The following changes since commit 645b5afbb8215b3386cd6fc2dc3119bd68e4c760:

  Prepare v2018.05-rc1 (2018-04-02 20:31:36 -0400)

are available in the git repository at:

  git://github.com/agraf/u-boot.git tags/signed-efi-next

for you to fetch changes up to f4cf153a487486428a061b5d866fe2f68653b2f8:

  efi_loader: correctly set the machine type in the PE header (2018-04-09 
10:20:59 +0200)


Patch queue for efi - 2018-04-09

Highlights this time around:

  - Lots of minor spec compliance fixes
  - Support full range of GOP BLT commands
  - More fine grained error checking
  - Network fixes (init, DP)
  - Lots of other bug fixes...


Alexander Graf (6):
  git: mailrc: Add myself and efi to list
  efi_loader: Optimize GOP switch
  efi_loader: Optimize GOP more
  efi_loader: Fix return value for efi_add_runtime_mmio
  efi_loader: Fix network DP with DM_ETH
  efi_loader: Respect DT reserved regions

Heinrich Schuchardt (49):
  efi_loader: parameter checks for LoadImage
  efi_loader: remove deprecated ConsoleControlProtocol
  efi_loader: delete doc/README.efi
  efi_loader: provide new doc/README.uefi
  efi_loader: efi_smbios_register should have a return value
  efi_loader: return efi_status_t from efi_gop_register
  efi_loader: return efi_status_t from efi_net_register
  efi_loader: consistently return efi_status_t efi_watchdog_register
  efi_loader: simplify calling efi_init_obj_list
  efi_loader: exit status for efi_reset_system_init
  efi_loader: efi_get_time_init should return status code
  efi_loader: do_bootefi_exec should always return an EFI status code
  efi_loader: check initialization of EFI subsystem is successful
  efi_loader: support device tree for bootefi selftest
  efi_selftest: check installation of the device tree
  efi_loader: correct input of special keys
  efi_loader: check parameter in InstallConfigurationTable
  efi_loader: clear signaled state in CheckEvent
  efi_loader: fix formatting errors
  efi_loader: manage events in a linked list
  efi_loader: define GUIDS for event groups
  efi_loader: implement event groups
  efi_loader: implement missing bit blit operations in gop
  efi_selftest: test gop bitblt
  efi_loader: add missing EFI_RESET_PLATFORM_SPECIFIC
  efi_selftest: unit test for EFI_SIMPLE_TEXT_INPUT_PROTOCOL
  efi_loader: show UEFI revision in helloworld
  efi_loader: use constants in efi_allocate_pages()
  efi_selftest: fix device tree unit test
  efi_selftest: unit test for event groups
  efi_loader: correctly support parameter delta in Blt
  efi_loader: use TPL_NOTIFY for network timer event
  efi_loader: RestoreTPL should execute queued events
  efi_loader: use __always_inline for pixel conversion
  efi_loader: use efi_uintn_t for LoadImage
  efi_loader: save image relocation address and size
  efi_loader: ImageSize must be multiple of SectionAlignment
  efi_loader: correct types for EFI_LOADED_IMAGE_PROTOCOL
  efi_loader: use correct types in EFI_FILE_PROTOCOL
  efi_loader: correctly determine the boot partition
  efi_loader: use const for GUIDs in the EFI_FILE_PROTOCOL
  efi_loader: ascii2unicode(): add trailing \0
  efi_loader: implement EFI_FILE_SYSTEM_INFO
  efi_selftest: partition label for test image
  efi_selftest: test getinfo(EFI_FILE_SYSTEM_INFO)
  efi_loader: new functions to print loaded image information
  arm: print information about loaded UEFI images
  efi_loader: completely initialize network
  efi_loader: correctly set the machine type in the PE header

Ivan Gorinov (1):
  efi_loader: Check machine type in the image header

Leif Lindholm (1):
  efi_loader: Initial EFI_DEVICE_PATH_UTILITIES_PROTOCOL

Patrick Wildt (2):
  efi_loader: complete efi_pxe_mode struct definition
  efi_loader: initialize device path on alloc

Simon Glass (1):
  efi: Correct header order in efi_memory

 MAINTAINERS  |   2 +-
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c  |   5 +-
 arch/arm/cpu/armv8/fwcall.c  |   1 +
 arch/arm/lib/interrupts.c|  13 +
 arch/arm/mach-bcm283x/reset.c|   5 +-
 arch/x86/config.mk   |   6 +-
 cmd/bootefi.c| 229 ++--
 doc/README.efi   |  86 --
 doc/README.uefi  | 332 +++
 doc/git-mailrc   |   2 +
 include/efi_api.h| 141 +++---
 include/efi_loader.h   

Re: [U-Boot] [PATCH v2] arm64: Add SMC and HVC commands

2018-04-09 Thread Tom Rini
On Mon, Apr 09, 2018 at 04:11:01PM +0300, Michalis Pappas wrote:
> This patch adds smc and hvc commands, that allow issuing Secure Monitor
> Calls and Hypervisor Calls conforming to the ARM SMC Calling Convention.
> 
> Add Kconfig items to allow each command can be individually enabled.
> 
> Signed-off-by: Michalis Pappas 
> ---
> 
>  cmd/Kconfig  | 14 ++
>  cmd/Makefile |  2 ++
>  cmd/smccc.c  | 72 
>  3 files changed, 88 insertions(+)
>  create mode 100644 cmd/smccc.c
> 
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 136836d146..a2b09620f3 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1348,6 +1348,20 @@ config CMD_HASH
> saved to memory or to an environment variable. It is also possible
> to verify a hash against data in memory.
> 
> +config CMD_HVC
> + bool "Support the 'hvc' command"
> + depends on ARM64
> + help
> +   Allows issuing Hypervisor Calls (HVCs). Mostly useful for
> +   development and testing.
> +
> +config CMD_SMC
> + bool "Support the 'smc' command"
> + depends on ARM64
> + help
> +   Allows issuing Secure Monitor Calls (SMCs). Mostly useful for
> +   development and testing.

Sorry for not catching this before, in both cases we should depend on
ARM_SMCC as that's what provides the underlying functions and is
available on both ARMv7 and ARMv8.

-- 
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] arm64: Add SMC and HVC commands

2018-04-09 Thread Michalis Pappas

Thanks for the feedback, I just sent a v2 addressing both issues


On 04/09/2018 04:26 AM, Fabio Estevam wrote:

On Fri, Apr 6, 2018 at 7:06 AM, Michalis Pappas  wrote:


+config CMD_HVC
+   bool "Support the 'hvc' command"
+   depends on ARM64
+   default n

No need to pass 'default n' as this is already the default behavior.


+   help
+ Allows issuing Hypervisor Calls (HVCs)
+
+config CMD_SMC
+   bool "Support the 'smc' command"
+   depends on ARM64
+   default n

Ditto.


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


Re: [U-Boot] [PATCH u-boot 2/2] ARM: meson: Add cpu info display for GX SoCs

2018-04-09 Thread Neil Armstrong
On 08/04/2018 15:50, Simon Glass wrote:
> Hi,
> 
> On 28 March 2018 at 05:54, Neil Armstrong  wrote:
>> The Amlogic SoCs have a registers containing the die revision
>> and packaging type to determine the SoC family and package marketing
>> name like S905X for the GXL SoC Family.
>> This code is taken for the Linux meson-gx-socinfo driver and adapted
>> to U-Boot printing.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  arch/arm/include/asm/arch-meson/gx.h |   1 +
>>  arch/arm/mach-meson/Makefile |   2 +-
>>  arch/arm/mach-meson/cpu_info.c   | 105 
>> +++
>>  configs/khadas-vim_defconfig |   2 +-
>>  configs/libretech-cc_defconfig   |   2 +-
>>  configs/odroid-c2_defconfig  |   2 +-
>>  configs/odroid_defconfig |   1 +
>>  configs/p212_defconfig   |   2 +-
>>  8 files changed, 112 insertions(+), 5 deletions(-)
>>  create mode 100644 arch/arm/mach-meson/cpu_info.c
> 
> Please can you use driver model's CPU interface for this?
> 
> Regards,
> Simon
> 

You are right, I totally missed this one.

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


Re: [U-Boot] [PATCH u-boot 2/2] ARM: meson: Add cpu info display for GX SoCs

2018-04-09 Thread Neil Armstrong
On 04/04/2018 22:49, Beniamino Galvani wrote:
> On Wed, Mar 28, 2018 at 11:54:37AM +0200, Neil Armstrong wrote:
>> The Amlogic SoCs have a registers containing the die revision
>> and packaging type to determine the SoC family and package marketing
>> name like S905X for the GXL SoC Family.
>> This code is taken for the Linux meson-gx-socinfo driver and adapted
>> to U-Boot printing.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  arch/arm/include/asm/arch-meson/gx.h |   1 +
>>  arch/arm/mach-meson/Makefile |   2 +-
>>  arch/arm/mach-meson/cpu_info.c   | 105 
>> +++
>>  configs/khadas-vim_defconfig |   2 +-
>>  configs/libretech-cc_defconfig   |   2 +-
>>  configs/odroid-c2_defconfig  |   2 +-
>>  configs/odroid_defconfig |   1 +
>>  configs/p212_defconfig   |   2 +-
>>  8 files changed, 112 insertions(+), 5 deletions(-)
>>  create mode 100644 arch/arm/mach-meson/cpu_info.c
>>
>> diff --git a/arch/arm/include/asm/arch-meson/gx.h 
>> b/arch/arm/include/asm/arch-meson/gx.h
>> index 7930efd..6d5b4ea 100644
>> --- a/arch/arm/include/asm/arch-meson/gx.h
>> +++ b/arch/arm/include/asm/arch-meson/gx.h
>> @@ -17,6 +17,7 @@
>>  /* Always-On Peripherals registers */
>>  #define GX_AO_ADDR(off) (GX_AOBUS_BASE + ((off) << 2))
>>  
>> +#define GX_AO_SEC_SD_CFG8   GX_AO_ADDR(0x88)
>>  #define GX_AO_SEC_GP_CFG0   GX_AO_ADDR(0x90)
>>  #define GX_AO_SEC_GP_CFG3   GX_AO_ADDR(0x93)
>>  #define GX_AO_SEC_GP_CFG4   GX_AO_ADDR(0x94)
>> diff --git a/arch/arm/mach-meson/Makefile b/arch/arm/mach-meson/Makefile
>> index b4e8dde..5a01ff0 100644
>> --- a/arch/arm/mach-meson/Makefile
>> +++ b/arch/arm/mach-meson/Makefile
>> @@ -4,4 +4,4 @@
>>  # SPDX-License-Identifier:  GPL-2.0+
>>  #
>>  
>> -obj-y += board.o sm.o eth.o
>> +obj-y += board.o sm.o eth.o cpu_info.o
>> diff --git a/arch/arm/mach-meson/cpu_info.c b/arch/arm/mach-meson/cpu_info.c
>> new file mode 100644
>> index 000..657768f
>> --- /dev/null
>> +++ b/arch/arm/mach-meson/cpu_info.c
>> @@ -0,0 +1,105 @@
>> +/*
>> + * Copyright (C) 2018 BayLibre, SAS
>> + * Author: Neil Armstrong 
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#ifdef CONFIG_DISPLAY_CPUINFO
>> +
>> +#define SOCINFO_MAJOR   GENMASK(31, 24)
>> +#define SOCINFO_PACKGENMASK(23, 16)
>> +#define SOCINFO_MINOR   GENMASK(15, 8)
>> +#define SOCINFO_MISCGENMASK(7, 0)
>> +
>> +static const struct meson_gx_soc_id {
>> +const char *name;
>> +unsigned int id;
>> +} soc_ids[] = {
>> +{ "GXBB", 0x1f },
>> +{ "GXTVBB", 0x20 },
>> +{ "GXL", 0x21 },
>> +{ "GXM", 0x22 },
>> +{ "TXL", 0x23 },
>> +};
>> +
>> +static const struct meson_gx_package_id {
>> +const char *name;
>> +unsigned int major_id;
>> +unsigned int pack_id;
>> +} soc_packages[] = {
>> +{ "S905", 0x1f, 0 },
>> +{ "S905M", 0x1f, 0x20 },
>> +{ "S905D", 0x21, 0 },
>> +{ "S905X", 0x21, 0x80 },
>> +{ "S905L", 0x21, 0xc0 },
>> +{ "S905M2", 0x21, 0xe0 },
>> +{ "S912", 0x22, 0 },
>> +};
>> +
>> +static inline unsigned int socinfo_to_major(u32 socinfo)
>> +{
>> +return FIELD_GET(SOCINFO_MAJOR, socinfo);
>> +}
>> +
>> +static inline unsigned int socinfo_to_minor(u32 socinfo)
>> +{
>> +return FIELD_GET(SOCINFO_MINOR, socinfo);
>> +}
>> +
>> +static inline unsigned int socinfo_to_pack(u32 socinfo)
>> +{
>> +return FIELD_GET(SOCINFO_PACK, socinfo);
>> +}
>> +
>> +static inline unsigned int socinfo_to_misc(u32 socinfo)
>> +{
>> +return FIELD_GET(SOCINFO_MISC, socinfo);
>> +}
>> +
>> +static const char *socinfo_to_package_id(u32 socinfo)
>> +{
>> +unsigned int pack = socinfo_to_pack(socinfo) & 0xf0;
>> +unsigned int major = socinfo_to_major(socinfo);
>> +int i;
>> +
>> +for (i = 0 ; i < ARRAY_SIZE(soc_packages) ; ++i) {
>> +if (soc_packages[i].major_id == major &&
>> +soc_packages[i].pack_id == pack)
>> +return soc_packages[i].name;
>> +}
>> +
>> +return "Unknown";
>> +}
>> +
>> +static const char *socinfo_to_soc_id(u32 socinfo)
>> +{
>> +unsigned int id = socinfo_to_major(socinfo);
>> +int i;
>> +
>> +for (i = 0 ; i < ARRAY_SIZE(soc_ids) ; ++i) {
>> +if (soc_ids[i].id == id)
>> +return soc_ids[i].name;
>> +}
>> +
>> +return "Unknown";
>> +}
>> +
>> +int print_cpuinfo(void)
>> +{
>> +u32 socinfo = readl(GX_AO_SEC_SD_CFG8);
> 
> Perhaps, add a blank line between declarations and code? checkpatch
> issues a warning about this.

Ok

> 
>> +printf("CPU: Amlogic Meson %s (%s) rev %x:%x (%x:%x)\n",
>> +socinfo_to_soc_id(socinfo),
>> +socinfo_to_package_id(socinfo),
>> +socinfo_to_major(socinfo),
>> +socinfo_to_minor(socinfo),
>> +socinfo_to_pack(socinfo),
>> +

Re: [U-Boot] [PATCH u-boot 1/2] ARM: meson: rename GXBB to GX

2018-04-09 Thread Neil Armstrong
On 04/04/2018 22:40, Beniamino Galvani wrote:
> On Wed, Mar 28, 2018 at 11:54:36AM +0200, Neil Armstrong wrote:
>> Taking into account the Amlogic Family name starts with GX, including
>> the GXBB, GXL and GXM SoCs.
>>
>> Signed-off-by: Neil Armstrong 
> 
> Hi,
> 
> looks good to me, but perhaps can you align again register values and
> other macros in gx.h?
> 
> Beniamino
> 

Will do,

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


Re: [U-Boot] [PATCH] sunxi: A64/H5 devices: enable usb keyboard support

2018-04-09 Thread Antony Antony
On Mon, Apr 09, 2018 at 01:15:00PM +0100, Peter Robinson wrote:
> Now the A64/H5 SoCs support video output it's useful to enable usb keyboard
> support so console can be used via standard keyboard/video interface.
> 
> Tested on Pine64.

Is it usefull on devices without video output(no HDMI, VGA)?


>  configs/nanopi_neo2_defconfig | 2 ++
>  configs/nanopi_neo_plus2_defconfig| 2 ++


> --- a/configs/nanopi_neo2_defconfig
> +++ b/configs/nanopi_neo2_defconfig
> @@ -13,3 +13,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-nanopi-neo2"
>  CONFIG_SUN8I_EMAC=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
> +CONFIG_DM_KEYBOARD=y
> +CONFIG_USB_KEYBOARD=y
> diff --git a/configs/nanopi_neo_plus2_defconfig 
> b/configs/nanopi_neo_plus2_defconfig
> index 5f69799e06..1c6ad4647d 100644
> --- a/configs/nanopi_neo_plus2_defconfig
> +++ b/configs/nanopi_neo_plus2_defconfig
> @@ -14,3 +14,5 @@ CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-nanopi-neo-plus2"
>  # CONFIG_SPL_EFI_PARTITION is not set
>  CONFIG_SUN8I_EMAC=y
>  CONFIG_USB_EHCI_HCD=y
> +CONFIG_DM_KEYBOARD=y
> +CONFIG_USB_KEYBOARD=y

these two devices have no video out. I am not sure all these have HDMI output.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v4 1/2] SPI Flash: add support of sst26wf* flash ICs protection ops

2018-04-09 Thread Eugeniy Paltsev
Hi Jagan,

On Mon, 2018-04-09 at 16:52 +0530, Jagan Teki wrote:
> On Mon, Apr 9, 2018 at 4:27 PM, Eugeniy Paltsev
>  wrote:
> > sst26wf flash series block protection implementation differs
> > from other SST series, so add specific implementation
> > flash_lock/flash_unlock/flash_is_locked functions for sst26wf
> > flash ICs.
> > 
> > +enum flash_lock_status {
> > +   SF_UNLOCKED = 0,
> > +   SF_LOCKED   = 1,
> > +};
> 
> Try to use existing relevant error codes.

Hmm, I can return something like EACCES (positive value) if flash is locked. Is 
it OK?

> > +
> >  #define SPI_FLASH_3B_ADDR_LEN  3
> > +enum lock_ctl {
> > +   CTL_LOCK,
> > +   CTL_UNLOCK,
> > +   CTL_CHECK
> > +};
> 
> SST26_CTL_* ?
OK.

> > 
> > +#if defined(CONFIG_SPI_FLASH_SST)
> 
> Please move this code inside of existing #ifdef of SST (commented same
> in previous version)
OK.

[snip]
> > 
> >  #ifdef CONFIG_SPI_FLASH_MACRONIX
> >  static int macronix_quad_enable(struct spi_flash *flash)
> > @@ -1033,6 +1189,15 @@ int spi_flash_scan(struct spi_flash *flash)
> > }
> >  #endif
> > 
> > +/* sst26wf series block protection implementation differs from other 
> > series */
> > +#if defined(CONFIG_SPI_FLASH_SST)
> > +   if (JEDEC_MFR(info) == SPI_FLASH_CFI_MFR_SST && info->id[1] == 
> > 0x26) {
> > +   flash->flash_lock = sst26_lock;
> > +   flash->flash_unlock = sst26_unlock;
> > +   flash->flash_is_locked = sst26_is_locked;
> > +   }
> > +#endif
> 
> Previous version comment need to fix here? (about switch case with
> existing lock ops)?

I guess switch case isn't suitable here:
we need check several parameters (JEDEC_MFR and Device Type) and we need to 
check
CONFIG_SPI_FLASH_*** ifdefs.

Also we have only two lock ops: "stm_*" and "sst26_*" (which I add by this 
patch).

So I guess using switch here is unnecessarily.

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


Re: [U-Boot] [BUG] snow: mmc: SD card access broken: unable to select a mode

2018-04-09 Thread Jean-Jacques Hiblot



On 09/04/2018 14:02, Guillaume Gardet wrote:

Hi Jaehoon,

There are problems with SD card access on Samsung Chromebook (snow) 
with latest master (and also 2018.05-rc1 and 2018.03).


eMMC is ok, but SD card access leads to 'unable to select a mode' 
problem. If I disable HS mode, I can access the SD card without problem:
 


diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980bf..28f4fa0f213 100644
--- a/drivers/mmc/dw_mmc.c
+++ b/drivers/mmc/dw_mmc.c
@@ -508,7 +508,8 @@ void dwmci_setup_cfg(struct mmc_config *cfg, 
struct dwmci_host *host,

     cfg->host_caps |= MMC_MODE_4BIT;
     cfg->host_caps &= ~MMC_MODE_8BIT;
 }
-    cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;
+    /* Temp workaround for Chromebook snow to avoid the 'unable to 
select a mode' error */

+//     cfg->host_caps |= MMC_MODE_HS | MMC_MODE_HS_52MHz;

 cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }
 



Once we try to select HS mode, all access to SD card result in 
failure, even when trying to setup a lower frequency mode, including 
SD legacy at 25 MHz.


Any idea what is going? Maybe you have fixes pending?


Can try with MMC_MODE_HS | MMC_MODE_HS_52MHz but with a lower 
max-frequency (<25MHz) ? It would be interesting to know if it could 
come from a frequency limitation.

Is there some pad configuration to do when using higher frequency?

JJ




Guillaume





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