[U-Boot] [PATCH] efi_loader: Exit in efi_set_bootdev() upon invalid "desc"

[Stefan Roese]

When trying to load an image from a non-existent USB key, U-Boot v2017.11
crashes on my x86 platform:

=> load usb 0:1 0300 abc
General Protection
EIP: 0010:[<7b59030d>] EFLAGS: 00010286
Original EIP :[]
...

This used to work in v2017.09. Testing has shown, that this bug was
introduced with patch 95c5553e [efi_loader: refactor boot device and
loaded_image handling].

This patch now checks if a valid "desc" is returned from blk_get_dev()
and only continues when "desc" is available. Resulting in this cmd
output (again):

=> load usb 0:1 0300 abc
** Bad device usb 0 **

Signed-off-by: Stefan Roese 
Cc: Rob Clark 
Cc: Heinrich Schuchardt 
Cc: Alexander Graf 
Cc: Marek Vasut 
Cc: Bin Meng 
---
 cmd/bootefi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 478bc116e2..b468a20d82 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -390,6 +390,8 @@ void efi_set_bootdev(const char *dev, const char *devnr, 
const char *path)
int part;
 
desc = blk_get_dev(dev, simple_strtol(devnr, NULL, 10));
+   if (!desc)
+   return;
part = parse_partnum(devnr);
 
bootefi_device_path = efi_dp_from_part(desc, part);
-- 
2.15.0

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

[U-Boot] [PATCH 1/2] ARM: at91: add sama5d2 smc header

[Wenyou Yang]

From: Ludovic Desroches 

Add a header for SAMA5D2 SMC since it's not compatible with
SAMA5D3 one.

Signed-off-by: Ludovic Desroches 
[wenyou: fix the wrong base address of the SMC register]
Signed-off-by: Wenyou Yang 
---

 arch/arm/mach-at91/include/mach/sama5d2_smc.h | 76 +++
 1 file changed, 76 insertions(+)
 create mode 100644 arch/arm/mach-at91/include/mach/sama5d2_smc.h

diff --git a/arch/arm/mach-at91/include/mach/sama5d2_smc.h 
b/arch/arm/mach-at91/include/mach/sama5d2_smc.h
new file mode 100644
index 00..7ddb728cf3
--- /dev/null
+++ b/arch/arm/mach-at91/include/mach/sama5d2_smc.h
@@ -0,0 +1,76 @@
+/*
+ * Copyright (C) 2017 Microchip Corporation.
+ *
+ * Static Memory Controllers (SMC) - System peripherals registers.
+ * Based on SAMA5D2 datasheet.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef SAMA5D2_SMC_H
+#define SAMA5D2_SMC_H
+
+#ifdef __ASSEMBLY__
+#define AT91_ASM_SMC_SETUP0(ATMEL_BASE_SMC + 0x700)
+#define AT91_ASM_SMC_PULSE0(ATMEL_BASE_SMC + 0x704)
+#define AT91_ASM_SMC_CYCLE0(ATMEL_BASE_SMC + 0x708)
+#define AT91_ASM_SMC_TIMINGS0  (ATMEL_BASE_SMC + 0x70c)
+#define AT91_ASM_SMC_MODE0 (ATMEL_BASE_SMC + 0x710)
+#else
+struct at91_cs {
+   u32 setup;  /* 0x600 SMC Setup Register */
+   u32 pulse;  /* 0x604 SMC Pulse Register */
+   u32 cycle;  /* 0x608 SMC Cycle Register */
+   u32 timings;/* 0x60C SMC Cycle Register */
+   u32 mode;   /* 0x610 SMC Mode Register */
+};
+
+struct at91_smc {
+   struct at91_cs cs[4];
+};
+#endif /*  __ASSEMBLY__ */
+
+#define AT91_SMC_SETUP_NWE(x)  (x & 0x3f)
+#define AT91_SMC_SETUP_NCS_WR(x)   ((x & 0x3f) << 8)
+#define AT91_SMC_SETUP_NRD(x)  ((x & 0x3f) << 16)
+#define AT91_SMC_SETUP_NCS_RD(x)   ((x & 0x3f) << 24)
+
+#define AT91_SMC_PULSE_NWE(x)  (x & 0x7f)
+#define AT91_SMC_PULSE_NCS_WR(x)   ((x & 0x7f) << 8)
+#define AT91_SMC_PULSE_NRD(x)  ((x & 0x7f) << 16)
+#define AT91_SMC_PULSE_NCS_RD(x)   ((x & 0x7f) << 24)
+
+#define AT91_SMC_CYCLE_NWE(x)  (x & 0x1ff)
+#define AT91_SMC_CYCLE_NRD(x)  ((x & 0x1ff) << 16)
+
+#define AT91_SMC_TIMINGS_TCLR(x)   (x & 0xf)
+#define AT91_SMC_TIMINGS_TADL(x)   ((x & 0xf) << 4)
+#define AT91_SMC_TIMINGS_TAR(x)((x & 0xf) << 8)
+#define AT91_SMC_TIMINGS_OCMS(x)   ((x & 0x1) << 12)
+#define AT91_SMC_TIMINGS_TRR(x)((x & 0xf) << 16)
+#define AT91_SMC_TIMINGS_TWB(x)((x & 0xf) << 24)
+#define AT91_SMC_TIMINGS_RBNSEL(x) ((x & 0xf) << 28)
+#define AT91_SMC_TIMINGS_NFSEL(x)  ((x & 0x1) << 31)
+
+#define AT91_SMC_MODE_RM_NCS   0x
+#define AT91_SMC_MODE_RM_NRD   0x0001
+#define AT91_SMC_MODE_WM_NCS   0x
+#define AT91_SMC_MODE_WM_NWE   0x0002
+
+#define AT91_SMC_MODE_EXNW_DISABLE 0x
+#define AT91_SMC_MODE_EXNW_FROZEN  0x0020
+#define AT91_SMC_MODE_EXNW_READY   0x0030
+
+#define AT91_SMC_MODE_BAT  0x0100
+#define AT91_SMC_MODE_DBW_80x
+#define AT91_SMC_MODE_DBW_16   0x1000
+#define AT91_SMC_MODE_DBW_32   0x2000
+#define AT91_SMC_MODE_TDF_CYCLE(x) ((x & 0xf) << 16)
+#define AT91_SMC_MODE_TDF  0x0010
+#define AT91_SMC_MODE_PMEN 0x0100
+#define AT91_SMC_MODE_PS_4 0x
+#define AT91_SMC_MODE_PS_8 0x1000
+#define AT91_SMC_MODE_PS_160x2000
+#define AT91_SMC_MODE_PS_320x3000
+
+#endif
-- 
2.13.0

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

[U-Boot] [PATCH 2/2] board: atmel: add sama5d2_ptc_ek board

[Wenyou Yang]

From: Ludovic Desroches 

Add the SAMA5D2 PTC EK board and remove the SAMA5D2 PTC ENGI board
which was a prototype.

Signed-off-by: Ludovic Desroches 
Signed-off-by: Wenyou Yang 
---

 arch/arm/dts/Makefile  |   3 +
 arch/arm/dts/at91-sama5d2_ptc_ek.dts   | 215 
 arch/arm/dts/sama5d2.dtsi  |  18 ++
 arch/arm/mach-at91/Kconfig |   7 +-
 board/atmel/sama5d2_ptc/MAINTAINERS|   7 -
 board/atmel/sama5d2_ptc/Makefile   |   8 -
 board/atmel/sama5d2_ptc/sama5d2_ptc.c  | 285 -
 .../atmel/{sama5d2_ptc => sama5d2_ptc_ek}/Kconfig  |   6 +-
 board/atmel/sama5d2_ptc_ek/MAINTAINERS |   8 +
 board/atmel/sama5d2_ptc_ek/Makefile|   8 +
 board/atmel/sama5d2_ptc_ek/sama5d2_ptc_ek.c| 130 ++
 configs/sama5d2_ptc_ek_mmc_defconfig   |  60 +
 configs/sama5d2_ptc_ek_nandflash_defconfig |  60 +
 configs/sama5d2_ptc_nandflash_defconfig|  33 ---
 configs/sama5d2_ptc_spiflash_defconfig |  34 ---
 include/configs/sama5d2_ptc.h  | 114 -
 include/configs/sama5d2_ptc_ek.h   |  46 
 17 files changed, 554 insertions(+), 488 deletions(-)
 create mode 100644 arch/arm/dts/at91-sama5d2_ptc_ek.dts
 delete mode 100644 board/atmel/sama5d2_ptc/MAINTAINERS
 delete mode 100644 board/atmel/sama5d2_ptc/Makefile
 delete mode 100644 board/atmel/sama5d2_ptc/sama5d2_ptc.c
 rename board/atmel/{sama5d2_ptc => sama5d2_ptc_ek}/Kconfig (60%)
 create mode 100644 board/atmel/sama5d2_ptc_ek/MAINTAINERS
 create mode 100644 board/atmel/sama5d2_ptc_ek/Makefile
 create mode 100644 board/atmel/sama5d2_ptc_ek/sama5d2_ptc_ek.c
 create mode 100644 configs/sama5d2_ptc_ek_mmc_defconfig
 create mode 100644 configs/sama5d2_ptc_ek_nandflash_defconfig
 delete mode 100644 configs/sama5d2_ptc_nandflash_defconfig
 delete mode 100644 configs/sama5d2_ptc_spiflash_defconfig
 delete mode 100644 include/configs/sama5d2_ptc.h
 create mode 100644 include/configs/sama5d2_ptc_ek.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 6db64f9101..4e2eac0938 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -421,6 +421,9 @@ dtb-$(CONFIG_TARGET_OMAP3_LOGIC) += \
logicpd-torpedo-37xx-devkit.dtb \
logicpd-som-lv-37xx-devkit.dtb
 
+dtb-$(CONFIG_TARGET_SAMA5D2_PTC_EK) += \
+   at91-sama5d2_ptc_ek.dtb
+
 dtb-$(CONFIG_TARGET_SAMA5D2_XPLAINED) += \
at91-sama5d2_xplained.dtb
 
diff --git a/arch/arm/dts/at91-sama5d2_ptc_ek.dts 
b/arch/arm/dts/at91-sama5d2_ptc_ek.dts
new file mode 100644
index 00..ab5ab21895
--- /dev/null
+++ b/arch/arm/dts/at91-sama5d2_ptc_ek.dts
@@ -0,0 +1,215 @@
+/*
+ * at91-sama5d2_ptc_ek.dts - Device Tree file for SAMA5D2 PTC EK board
+ *
+ *  Copyright (C) 2017 Microchip Technology Inc,
+ *Ludovic Desroches 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION 

[U-Boot] [PATCH 0/2] board: atmel: Add new board SAMA5D2 PTC EK

[Wenyou Yang]

Add the new board SAMA5D2 PTC EK and remove the SAMA5D2 PTC ENGI
board which was a prototype.


Ludovic Desroches (2):
  ARM: at91: add sama5d2 smc header
  board: atmel: add sama5d2_ptc_ek board

 arch/arm/dts/Makefile  |   3 +
 arch/arm/dts/at91-sama5d2_ptc_ek.dts   | 215 
 arch/arm/dts/sama5d2.dtsi  |  18 ++
 arch/arm/mach-at91/Kconfig |   7 +-
 arch/arm/mach-at91/include/mach/sama5d2_smc.h  |  76 ++
 board/atmel/sama5d2_ptc/MAINTAINERS|   7 -
 board/atmel/sama5d2_ptc/Makefile   |   8 -
 board/atmel/sama5d2_ptc/sama5d2_ptc.c  | 285 -
 .../atmel/{sama5d2_ptc => sama5d2_ptc_ek}/Kconfig  |   6 +-
 board/atmel/sama5d2_ptc_ek/MAINTAINERS |   8 +
 board/atmel/sama5d2_ptc_ek/Makefile|   8 +
 board/atmel/sama5d2_ptc_ek/sama5d2_ptc_ek.c| 130 ++
 configs/sama5d2_ptc_ek_mmc_defconfig   |  60 +
 configs/sama5d2_ptc_ek_nandflash_defconfig |  60 +
 configs/sama5d2_ptc_nandflash_defconfig|  33 ---
 configs/sama5d2_ptc_spiflash_defconfig |  34 ---
 include/configs/sama5d2_ptc.h  | 114 -
 include/configs/sama5d2_ptc_ek.h   |  46 
 18 files changed, 630 insertions(+), 488 deletions(-)
 create mode 100644 arch/arm/dts/at91-sama5d2_ptc_ek.dts
 create mode 100644 arch/arm/mach-at91/include/mach/sama5d2_smc.h
 delete mode 100644 board/atmel/sama5d2_ptc/MAINTAINERS
 delete mode 100644 board/atmel/sama5d2_ptc/Makefile
 delete mode 100644 board/atmel/sama5d2_ptc/sama5d2_ptc.c
 rename board/atmel/{sama5d2_ptc => sama5d2_ptc_ek}/Kconfig (60%)
 create mode 100644 board/atmel/sama5d2_ptc_ek/MAINTAINERS
 create mode 100644 board/atmel/sama5d2_ptc_ek/Makefile
 create mode 100644 board/atmel/sama5d2_ptc_ek/sama5d2_ptc_ek.c
 create mode 100644 configs/sama5d2_ptc_ek_mmc_defconfig
 create mode 100644 configs/sama5d2_ptc_ek_nandflash_defconfig
 delete mode 100644 configs/sama5d2_ptc_nandflash_defconfig
 delete mode 100644 configs/sama5d2_ptc_spiflash_defconfig
 delete mode 100644 include/configs/sama5d2_ptc.h
 create mode 100644 include/configs/sama5d2_ptc_ek.h

-- 
2.13.0

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

[U-Boot] [PATCH] mmc: atmel_sdhci: not on capabilities to set gck rate

[Wenyou Yang]

From: Ludovic Desroches 

The capabilities have default values which doesn't reflect the reality
when it concerns the base clock and the mul value. Use a fixe rate
for the gck. 240 MHz is an arbitrary choice, it is a multiple of the
maximum SD clock frequency handle by the controller and it allows to
get a 400 kHz clock for the card initialisation.

Signed-off-by: Ludovic Desroches 
Signed-off-by: Wenyou Yang 
---

 drivers/mmc/atmel_sdhci.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
index c19a1f36b6..9b37e32c8d 100644
--- a/drivers/mmc/atmel_sdhci.c
+++ b/drivers/mmc/atmel_sdhci.c
@@ -13,6 +13,7 @@
 #include 
 
 #define ATMEL_SDHC_MIN_FREQ40
+#define ATMEL_SDHC_GCK_RATE24000
 
 #ifndef CONFIG_DM_MMC
 int atmel_sdhci_init(void *regbase, u32 id)
@@ -57,9 +58,6 @@ static int atmel_sdhci_probe(struct udevice *dev)
struct atmel_sdhci_plat *plat = dev_get_platdata(dev);
struct sdhci_host *host = dev_get_priv(dev);
u32 max_clk;
-   u32 caps, caps_1;
-   u32 clk_base, clk_mul;
-   ulong gck_rate;
struct clk clk;
int ret;
 
@@ -78,17 +76,11 @@ static int atmel_sdhci_probe(struct udevice *dev)
host->bus_width = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev),
 "bus-width", 4);
 
-   caps = sdhci_readl(host, SDHCI_CAPABILITIES);
-   clk_base = (caps & SDHCI_CLOCK_V3_BASE_MASK) >> SDHCI_CLOCK_BASE_SHIFT;
-   caps_1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
-   clk_mul = (caps_1 & SDHCI_CLOCK_MUL_MASK) >> SDHCI_CLOCK_MUL_SHIFT;
-   gck_rate = clk_base * 100 * (clk_mul + 1);
-
ret = clk_get_by_index(dev, 1, );
if (ret)
return ret;
 
-   ret = clk_set_rate(, gck_rate);
+   ret = clk_set_rate(, ATMEL_SDHC_GCK_RATE);
if (ret)
return ret;
 
-- 
2.13.0

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

[U-Boot] [PATCH 1/2] clk: at91: clk-generated: select absolute closest rate

[Wenyou Yang]

From: Ludovic Desroches 

To get the same behavior as the Linux driver, instead of selecting
the closest inferior rate, select the closest inferior or superior
rate

Signed-off-by: Ludovic Desroches 
Signed-off-by: Wenyou Yang 
---

 drivers/clk/at91/clk-generated.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/clk/at91/clk-generated.c b/drivers/clk/at91/clk-generated.c
index 8c9a3cb053..461b5b2c9a 100644
--- a/drivers/clk/at91/clk-generated.c
+++ b/drivers/clk/at91/clk-generated.c
@@ -98,9 +98,7 @@ static ulong generic_clk_set_rate(struct clk *clk, ulong rate)
 
for (div = 1; div < GENERATED_MAX_DIV + 2; div++) {
tmp_rate = DIV_ROUND_CLOSEST(parent_rate, div);
-   if (rate < tmp_rate)
-   continue;
-   tmp_diff = rate - tmp_rate;
+   tmp_diff = abs(rate - tmp_rate);
 
if (best_diff < 0 || best_diff > tmp_diff) {
best_rate = tmp_rate;
-- 
2.13.0

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

[U-Boot] [PATCH 2/2] clk: at91: clk-generated: fix incorrect index of clk source

[Wenyou Yang]

Differentiate the generic clock source selection value from the parent
clock index to fix the incorrect assignment of the generic clock
source selection.

Signed-off-by: Wenyou Yang 
---

 drivers/clk/at91/clk-generated.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/at91/clk-generated.c b/drivers/clk/at91/clk-generated.c
index 461b5b2c9a..2aacbaef0c 100644
--- a/drivers/clk/at91/clk-generated.c
+++ b/drivers/clk/at91/clk-generated.c
@@ -53,16 +53,17 @@ static ulong generic_clk_get_rate(struct clk *clk)
struct clk parent;
ulong clk_rate;
u32 tmp, gckdiv;
-   u8 parent_id;
+   u8 clock_source, parent_index;
int ret;
 
writel(clk->id & AT91_PMC_PCR_PID_MASK, >pcr);
tmp = readl(>pcr);
-   parent_id = (tmp >> AT91_PMC_PCR_GCKCSS_OFFSET) &
+   clock_source = (tmp >> AT91_PMC_PCR_GCKCSS_OFFSET) &
AT91_PMC_PCR_GCKCSS_MASK;
gckdiv = (tmp >> AT91_PMC_PCR_GCKDIV_OFFSET) & AT91_PMC_PCR_GCKDIV_MASK;
 
-   ret = clk_get_by_index(dev_get_parent(clk->dev), parent_id, );
+   parent_index = clock_source - 1;
+   ret = clk_get_by_index(dev_get_parent(clk->dev), parent_index, );
if (ret)
return 0;
 
@@ -82,7 +83,7 @@ static ulong generic_clk_set_rate(struct clk *clk, ulong rate)
ulong tmp_rate, best_rate = rate, parent_rate;
int tmp_diff, best_diff = -1;
u32 div, best_div = 0;
-   u8 best_parent_id = 0;
+   u8 best_parent_index, best_clock_source = 0;
u8 i;
u32 tmp;
int ret;
@@ -106,7 +107,8 @@ static ulong generic_clk_set_rate(struct clk *clk, ulong 
rate)
 
best_div = div - 1;
best_parent = parent;
-   best_parent_id = i;
+   best_parent_index = i;
+   best_clock_source = best_parent_index + 1;
}
 
if (!best_diff || tmp_rate < rate)
@@ -127,7 +129,7 @@ static ulong generic_clk_set_rate(struct clk *clk, ulong 
rate)
writel(clk->id & AT91_PMC_PCR_PID_MASK, >pcr);
tmp = readl(>pcr);
tmp &= ~(AT91_PMC_PCR_GCKDIV | AT91_PMC_PCR_GCKCSS);
-   tmp |= AT91_PMC_PCR_GCKCSS_(best_parent_id) |
+   tmp |= AT91_PMC_PCR_GCKCSS_(best_clock_source) |
   AT91_PMC_PCR_CMD_WRITE |
   AT91_PMC_PCR_GCKDIV_(best_div) |
   AT91_PMC_PCR_GCKEN;
-- 
2.13.0

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

[U-Boot] [PATCH 0/2] clk: at91: clk-generated: Improvement

[Wenyou Yang]

The purpose of the patch set is to fix the the incorrect assignment
of the generic clock  source selection, and to align to the Linux
kernel driver, instead of selecting the closest inferior rate, select
the absolute closest rate.


Ludovic Desroches (1):
  clk: at91: clk-generated: select absolute closest rate

Wenyou Yang (1):
  clk: at91: clk-generated: fix incorrect index of clk source

 drivers/clk/at91/clk-generated.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

-- 
2.13.0

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

[U-Boot] [PATCH v2] Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible"

[Goldschmidt Simon]

This reverts commit b63b46313ed29e9b0c36b3d6b9407f6eade40c8f.

This commit changed cadence_qspi_apb to use bouncebuf.c, which invalidates
the data cache after reading. This is meant for dma transfers only and
breaks the cadence_qspi driver which copies via cpu only: data that is
copied by the cpu is in cache only and the cache invalidation at the end
throws away this data.

Signed-off-by: Simon Goldschmidt 
---

Changes for v2:
   - Rebased on top of Jason's patchset v4 "Sync DT bindings with Linux"

 drivers/spi/cadence_qspi_apb.c | 22 ++
 1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index 8309ab8794..c7cb33aa8f 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -627,8 +627,6 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
 {
unsigned int remaining = n_rx;
unsigned int bytes_to_read = 0;
-   struct bounce_buffer bb;
-   u8 *bb_rxbuf;
int ret;
 
writel(n_rx, plat->regbase + CQSPI_REG_INDIRECTRDBYTES);
@@ -637,11 +635,6 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
writel(CQSPI_REG_INDIRECTRD_START,
   plat->regbase + CQSPI_REG_INDIRECTRD);
 
-   ret = bounce_buffer_start(, (void *)rxbuf, n_rx, GEN_BB_WRITE);
-   if (ret)
-   return ret;
-   bb_rxbuf = bb.bounce_buffer;
-
while (remaining > 0) {
ret = cadence_qspi_wait_for_data(plat);
if (ret < 0) {
@@ -655,13 +648,12 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
bytes_to_read *= plat->fifo_width;
bytes_to_read = bytes_to_read > remaining ?
remaining : bytes_to_read;
-   readsl(plat->ahbbase, bb_rxbuf, bytes_to_read >> 2);
-   if (bytes_to_read % 4)
-   readsb(plat->ahbbase,
-  bb_rxbuf + rounddown(bytes_to_read, 4),
-  bytes_to_read % 4);
-
-   bb_rxbuf += bytes_to_read;
+   /* Handle non-4-byte aligned access to avoid data 
abort. */
+   if (((uintptr_t)rxbuf % 4) || (bytes_to_read % 4))
+   readsb(plat->ahbbase, rxbuf, bytes_to_read);
+   else
+   readsl(plat->ahbbase, rxbuf, bytes_to_read >> 
2);
+   rxbuf += bytes_to_read;
remaining -= bytes_to_read;
bytes_to_read = cadence_qspi_get_rd_sram_level(plat);
}
@@ -678,7 +670,6 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
/* Clear indirect completion status */
writel(CQSPI_REG_INDIRECTRD_DONE,
   plat->regbase + CQSPI_REG_INDIRECTRD);
-   bounce_buffer_stop();
 
return 0;
 
@@ -686,7 +677,6 @@ failrd:
/* Cancel the indirect read */
writel(CQSPI_REG_INDIRECTRD_CANCEL,
   plat->regbase + CQSPI_REG_INDIRECTRD);
-   bounce_buffer_stop();
return ret;
 }
 
-- 
2.12.2.windows.2

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

[U-Boot] [PATCH] clk: at91: Kconfig: fix the dependency of AT91_UTMI

[Wenyou Yang]

What the AT91_UTMI depends on SPL_DM isn't right. AT91_UTMI is not
only used in SPL, also in other place, even if SPL_DM isn't enabled.

Signed-off-by: Wenyou Yang 
---

 drivers/clk/at91/Kconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/at91/Kconfig b/drivers/clk/at91/Kconfig
index c6c57618c1..fd56f200b9 100644
--- a/drivers/clk/at91/Kconfig
+++ b/drivers/clk/at91/Kconfig
@@ -14,11 +14,11 @@ config CLK_AT91
 
 config AT91_UTMI
bool "Support UTMI PLL Clock"
-   depends on CLK_AT91 && SPL_DM
+   depends on CLK_AT91
select REGMAP
-   select SPL_REGMAP
+   select SPL_REGMAP if SPL_DM
select SYSCON
-   select SPL_SYSCON
+   select SPL_SYSCON if SPL_DM
help
  This option is used to enable the AT91 UTMI PLL clock
  driver. It is the clock provider of USB, and UPLLCK is the
-- 
2.13.0

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

Re: [U-Boot] [PATCH v4 3/5] config: cadence_spi: Remove defines read from DT

[Goldschmidt Simon]

> Jason Rush wrote:
> Cleanup unused #define values that are read from the DT.
> ---
> Changes for v4:
>- Rebased

Reviewed-by: Simon Goldschmidt 

Tested on a socfpga-cyclonev board:
Tested-by: Simon Goldschmidt 

Best regards,
Simon

> 
>  include/configs/k2g_evm.h| 1 -
>  include/configs/socfpga_common.h | 1 -
>  include/configs/stv0991.h| 1 -
>  3 files changed, 3 deletions(-)
> 
> diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
> index df81c09..535e712 100644
> --- a/include/configs/k2g_evm.h
> +++ b/include/configs/k2g_evm.h
> @@ -93,7 +93,6 @@
>  #ifndef CONFIG_SPL_BUILD
>  #define CONFIG_CADENCE_QSPI
>  #define CONFIG_CQSPI_REF_CLK 38400
> -#define CONFIG_CQSPI_DECODER 0x0
>  #define CONFIG_BOUNCE_BUFFER
>  #endif
> 
> diff --git a/include/configs/socfpga_common.h
> b/include/configs/socfpga_common.h
> index 8a7debb..e5e2f83 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -185,7 +185,6 @@ unsigned int cm_get_l4_sp_clk_hz(void);
>  unsigned int cm_get_qspi_controller_clk_hz(void);
>  #define CONFIG_CQSPI_REF_CLK cm_get_qspi_controller_clk_hz()
>  #endif
> -#define CONFIG_CQSPI_DECODER 0
>  #define CONFIG_BOUNCE_BUFFER
> 
>  /*
> diff --git a/include/configs/stv0991.h b/include/configs/stv0991.h
> index c99fb67..fd96979 100644
> --- a/include/configs/stv0991.h
> +++ b/include/configs/stv0991.h
> @@ -63,7 +63,6 @@
>  + * QSPI support
>  + */
>  #ifdef CONFIG_OF_CONTROL /* QSPI is controlled via DT */
> -#define CONFIG_CQSPI_DECODER 0
>  #define CONFIG_CQSPI_REF_CLK ((30/4)/2)*1000*1000
>  #define CONFIG_BOUNCE_BUFFER
> 
> --
> 2.1.4

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

Re: [U-Boot] [PATCH v4 2/5] dts: cadence_spi: Sync DT bindings with Linux

[Goldschmidt Simon]

> Jason Rush wrote:
> Adopt the Linux DT bindings and clean-up duplicate
> and unused values.
> ---
> Changes for v4:
>- Rebased

Reviewed-by: Simon Goldschmidt 

> 
>  arch/arm/dts/keystone-k2g-evm.dts |  8 
>  arch/arm/dts/keystone-k2g.dtsi|  5 +++--
>  arch/arm/dts/socfpga.dtsi |  5 +++--
>  arch/arm/dts/socfpga_arria10.dtsi |  4 ++--
>  arch/arm/dts/socfpga_arria5_socdk.dts |  9 -
>  arch/arm/dts/socfpga_cyclone5_is1.dts |  9 -
>  arch/arm/dts/socfpga_cyclone5_socdk.dts   |  9 -
>  arch/arm/dts/socfpga_cyclone5_sockit.dts  |  9 -
>  arch/arm/dts/socfpga_cyclone5_socrates.dts|  9 -
>  arch/arm/dts/socfpga_cyclone5_sr1500.dts  |  9 -
>  arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 18 --
>  arch/arm/dts/stv0991.dts  | 12 +++-
>  12 files changed, 51 insertions(+), 55 deletions(-)
> 
> diff --git a/arch/arm/dts/keystone-k2g-evm.dts b/arch/arm/dts/keystone-k2g-
> evm.dts
> index de208b3..ba566a4 100644
> --- a/arch/arm/dts/keystone-k2g-evm.dts
> +++ b/arch/arm/dts/keystone-k2g-evm.dts
> @@ -76,10 +76,10 @@
>  spi-max-frequency = <9600>;
>  #address-cells = <1>;
>  #size-cells = <1>;
> -tshsl-ns = <392>;
> -tsd2d-ns = <392>;
> -tchsh-ns = <100>;
> -tslch-ns = <100>;
> +cdns,tshsl-ns = <392>;
> +cdns,tsd2d-ns = <392>;
> +cdns,tchsh-ns = <100>;
> +cdns,tslch-ns = <100>;
>   block-size = <18>;
> 
> 
> diff --git a/arch/arm/dts/keystone-k2g.dtsi b/arch/arm/dts/keystone-k2g.dtsi
> index 7b2fae6..9bcfea6 100644
> --- a/arch/arm/dts/keystone-k2g.dtsi
> +++ b/arch/arm/dts/keystone-k2g.dtsi
> @@ -92,8 +92,9 @@
> <0x2400 0x400>;
>   interrupts = ;
>   num-cs = <4>;
> - fifo-depth = <256>;
> - sram-size = <256>;
> + cdns,fifo-depth = <256>;
> + cdns,fifo-width = <4>;
> + cdns,trigger-address = <0x2400>;
>   status = "disabled";
>   };
> 
> diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
> index 8588221..7557aa0 100644
> --- a/arch/arm/dts/socfpga.dtsi
> +++ b/arch/arm/dts/socfpga.dtsi
> @@ -644,8 +644,9 @@
>   clocks = <_clk>;
>   ext-decoder = <0>;  /* external decoder */
>   num-cs = <4>;
> - fifo-depth = <128>;
> - sram-size = <128>;
> + cdns,fifo-depth = <128>;
> + cdns,fifo-width = <4>;
> + cdns,trigger-address = <0x>;
>   bus-num = <2>;
>   status = "disabled";
>   };
> diff --git a/arch/arm/dts/socfpga_arria10.dtsi 
> b/arch/arm/dts/socfpga_arria10.dtsi
> index 377700d..abfd0bc 100644
> --- a/arch/arm/dts/socfpga_arria10.dtsi
> +++ b/arch/arm/dts/socfpga_arria10.dtsi
> @@ -734,8 +734,8 @@
>   clocks = <_main_clk>;
>   ext-decoder = <0>;  /* external decoder */
>   num-chipselect = <4>;
> - fifo-depth = <128>;
> - sram-size = <512>;
> + cdns,fifo-depth = <128>;
> + cdns,fifo-width = <4>;
>   bus-num = <2>;
>   status = "disabled";
>   };
> diff --git a/arch/arm/dts/socfpga_arria5_socdk.dts
> b/arch/arm/dts/socfpga_arria5_socdk.dts
> index 7265058..1e91a65 100644
> --- a/arch/arm/dts/socfpga_arria5_socdk.dts
> +++ b/arch/arm/dts/socfpga_arria5_socdk.dts
> @@ -94,10 +94,9 @@
>   m25p,fast-read;
>   page-size = <256>;
>   block-size = <16>; /* 2^16, 64KB */
> - read-delay = <4>;  /* delay value in read data capture register 
> */
> - tshsl-ns = <50>;
> - tsd2d-ns = <50>;
> - tchsh-ns = <4>;
> - tslch-ns = <4>;
> + cdns,tshsl-ns = <50>;
> + cdns,tsd2d-ns = <50>;
> + cdns,tchsh-ns = <4>;
> + cdns,tslch-ns = <4>;
>   };
>  };
> diff --git a/arch/arm/dts/socfpga_cyclone5_is1.dts
> b/arch/arm/dts/socfpga_cyclone5_is1.dts
> index 16a3283..2e2b71f 100644
> --- a/arch/arm/dts/socfpga_cyclone5_is1.dts
> +++ b/arch/arm/dts/socfpga_cyclone5_is1.dts
> @@ -93,11 +93,10 @@
>   m25p,fast-read;
>   page-size = <256>;
>   block-size = <16>; /* 2^16, 64KB */
> - read-delay = <4>;  /* delay value in read data capture register 
> */
> - tshsl-ns = <50>;
> - tsd2d-ns = 

Re: [U-Boot] [PATCH v4 1/5] spi: cadence_spi: Sync DT bindings with Linux

[Goldschmidt Simon]

> Jason Rush wrote:
> Adopt the Linux DT bindings. This also fixes an issue
> with the indaddrtrig register on the Cadence QSPI
> device being programmed with the wrong value for the
> socfpga arch.
> ---
> Changes for v4:
>- Rebased
> 

Reviewed-by: Simon Goldschmidt 

Tested on a socfpga-cyclonev board:
Tested-by: Simon Goldschmidt 

Best regards,
Simon

>  drivers/spi/cadence_qspi.c | 20 
>  drivers/spi/cadence_qspi.h |  6 +-
>  drivers/spi/cadence_qspi_apb.c | 15 ---
>  3 files changed, 21 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> index 9a6e41f..991a716 100644
> --- a/drivers/spi/cadence_qspi.c
> +++ b/drivers/spi/cadence_qspi.c
> @@ -212,7 +212,7 @@ static int cadence_spi_xfer(struct udevice *dev, unsigned
> int bitlen,
> 
>   /* Set Chip select */
>   cadence_qspi_apb_chipselect(base, spi_chip_select(dev),
> - CONFIG_CQSPI_DECODER);
> + plat->is_decoded_cs);
> 
>   if ((flags & SPI_XFER_END) || (flags == 0)) {
>   if (priv->cmd_len == 0) {
> @@ -296,7 +296,11 @@ static int cadence_spi_ofdata_to_platdata(struct udevice
> *bus)
> 
>   plat->regbase = (void *)data[0];
>   plat->ahbbase = (void *)data[2];
> - plat->sram_size = fdtdec_get_int(blob, node, "sram-size", 128);
> + plat->is_decoded_cs = fdtdec_get_bool(blob, node, "cdns,is-decoded-
> cs");
> + plat->fifo_depth = fdtdec_get_uint(blob, node, "cdns,fifo-depth", 128);
> + plat->fifo_width = fdtdec_get_uint(blob, node, "cdns,fifo-width", 4);
> + plat->trigger_address = fdtdec_get_uint(blob, node,
> + "cdns,trigger-address", 0);
> 
>   /* All other paramters are embedded in the child node */
>   subnode = fdt_first_subnode(blob, node);
> @@ -310,12 +314,12 @@ static int cadence_spi_ofdata_to_platdata(struct
> udevice *bus)
>  50);
> 
>   /* Read other parameters from DT */
> - plat->page_size = fdtdec_get_int(blob, subnode, "page-size", 256);
> - plat->block_size = fdtdec_get_int(blob, subnode, "block-size", 16);
> - plat->tshsl_ns = fdtdec_get_int(blob, subnode, "tshsl-ns", 200);
> - plat->tsd2d_ns = fdtdec_get_int(blob, subnode, "tsd2d-ns", 255);
> - plat->tchsh_ns = fdtdec_get_int(blob, subnode, "tchsh-ns", 20);
> - plat->tslch_ns = fdtdec_get_int(blob, subnode, "tslch-ns", 20);
> + plat->page_size = fdtdec_get_uint(blob, subnode, "page-size", 256);
> + plat->block_size = fdtdec_get_uint(blob, subnode, "block-size", 16);
> + plat->tshsl_ns = fdtdec_get_uint(blob, subnode, "cdns,tshsl-ns", 200);
> + plat->tsd2d_ns = fdtdec_get_uint(blob, subnode, "cdns,tsd2d-ns", 255);
> + plat->tchsh_ns = fdtdec_get_uint(blob, subnode, "cdns,tchsh-ns", 20);
> + plat->tslch_ns = fdtdec_get_uint(blob, subnode, "cdns,tslch-ns", 20);
> 
>   debug("%s: regbase=%p ahbbase=%p max-frequency=%d page-
> size=%d\n",
> __func__, plat->regbase, plat->ahbbase, plat->max_hz,
> diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
> index d1927a4..8315421 100644
> --- a/drivers/spi/cadence_qspi.h
> +++ b/drivers/spi/cadence_qspi.h
> @@ -18,14 +18,18 @@ struct cadence_spi_platdata {
>   unsigned intmax_hz;
>   void*regbase;
>   void*ahbbase;
> + boolis_decoded_cs;
> + u32 fifo_depth;
> + u32 fifo_width;
> + u32 trigger_address;
> 
> + // Flash parameters
>   u32 page_size;
>   u32 block_size;
>   u32 tshsl_ns;
>   u32 tsd2d_ns;
>   u32 tchsh_ns;
>   u32 tslch_ns;
> - u32 sram_size;
>  };
> 
>  struct cadence_spi_priv {
> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
> index e02f221..8309ab8 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -37,10 +37,6 @@
>  #define CQSPI_REG_RETRY  1
>  #define CQSPI_POLL_IDLE_RETRY3
> 
> -#define CQSPI_FIFO_WIDTH 4
> -
> -#define CQSPI_REG_SRAM_THRESHOLD_WORDS   50
> -
>  /* Transfer mode */
>  #define CQSPI_INST_TYPE_SINGLE   0
>  #define CQSPI_INST_TYPE_DUAL 1
> @@ -51,9 +47,6 @@
>  #define CQSPI_DUMMY_CLKS_PER_BYTE8
>  #define CQSPI_DUMMY_BYTES_MAX4
> 
> -#define CQSPI_REG_SRAM_FILL_THRESHOLD\
> - ((CQSPI_REG_SRAM_SIZE_WORD / 2) * CQSPI_FIFO_WIDTH)
> -
>  /
>   * Controller's configuration and status register (offset from QSPI_BASE)
>   
> 

[U-Boot] [PATCH v2] x86: lib: Implement standalone __udivdi3 etc instead of libgcc ones

[Stefan Roese]

This patch removes the inclusion of the libgcc math functions and
replaces them by functions coded in C, taken from the coreboot
project. This makes U-Boot building more independent from the toolchain
installed / available on the build system.

The code taken from coreboot is authored from Vadim Bendebury
 on 2014-11-28 and committed with commit
ID e63990ef [libpayload: provide basic 64bit division implementation]
(coreboot git repository located here [1]).

I modified the code so that its checkpatch clean without any
functional changes.

[1] git://github.com/coreboot/coreboot.git

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Bin Meng 
---
v2:
- Added coreboot git repository link to commit message

 arch/x86/config.mk|   3 --
 arch/x86/lib/Makefile |   2 +-
 arch/x86/lib/div64.c  | 113 ++
 arch/x86/lib/gcc.c|  29 -
 4 files changed, 114 insertions(+), 33 deletions(-)
 create mode 100644 arch/x86/lib/div64.c
 delete mode 100644 arch/x86/lib/gcc.c

diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 8835dcf36f..472ada5490 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -34,9 +34,6 @@ PLATFORM_RELFLAGS += -ffunction-sections -fvisibility=hidden
 PLATFORM_LDFLAGS += -Bsymbolic -Bsymbolic-functions
 PLATFORM_LDFLAGS += -m $(if $(IS_32BIT),elf_i386,elf_x86_64)
 
-LDFLAGS_FINAL += --wrap=__divdi3 --wrap=__udivdi3
-LDFLAGS_FINAL += --wrap=__moddi3 --wrap=__umoddi3
-
 # This is used in the top-level Makefile which does not include
 # PLATFORM_LDFLAGS
 LDFLAGS_EFI_PAYLOAD := -Bsymbolic -Bsymbolic-functions -shared --no-undefined
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index fe00d7573f..d9b23f5cc4 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_SEABIOS) += coreboot_table.o
 obj-y  += early_cmos.o
 obj-$(CONFIG_EFI) += efi/
 obj-y  += e820.o
-obj-y  += gcc.o
+obj-y  += div64.o
 obj-y  += init_helpers.o
 obj-y  += interrupts.o
 obj-y  += lpc-uclass.o
diff --git a/arch/x86/lib/div64.c b/arch/x86/lib/div64.c
new file mode 100644
index 00..4efed74037
--- /dev/null
+++ b/arch/x86/lib/div64.c
@@ -0,0 +1,113 @@
+/*
+ * This file is copied from the coreboot repository as part of
+ * the libpayload project:
+ *
+ * Copyright 2014 Google Inc.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+
+union overlay64 {
+   u64 longw;
+   struct {
+   u32 lower;
+   u32 higher;
+   } words;
+};
+
+u64 __ashldi3(u64 num, unsigned int shift)
+{
+   union overlay64 output;
+
+   output.longw = num;
+   if (shift >= 32) {
+   output.words.higher = output.words.lower << (shift - 32);
+   output.words.lower = 0;
+   } else {
+   if (!shift)
+   return num;
+   output.words.higher = (output.words.higher << shift) |
+   (output.words.lower >> (32 - shift));
+   output.words.lower = output.words.lower << shift;
+   }
+   return output.longw;
+}
+
+u64 __lshrdi3(u64 num, unsigned int shift)
+{
+   union overlay64 output;
+
+   output.longw = num;
+   if (shift >= 32) {
+   output.words.lower = output.words.higher >> (shift - 32);
+   output.words.higher = 0;
+   } else {
+   if (!shift)
+   return num;
+   output.words.lower = output.words.lower >> shift |
+   (output.words.higher << (32 - shift));
+   output.words.higher = output.words.higher >> shift;
+   }
+   return output.longw;
+}
+
+#define MAX_32BIT_UINT u64)1) << 32) - 1)
+
+static u64 _64bit_divide(u64 dividend, u64 divider, u64 *rem_p)
+{
+   u64 result = 0;
+
+   /*
+* If divider is zero - let the rest of the system care about the
+* exception.
+*/
+   if (!divider)
+   return 1 / (u32)divider;
+
+   /* As an optimization, let's not use 64 bit division unless we must. */
+   if (dividend <= MAX_32BIT_UINT) {
+   if (divider > MAX_32BIT_UINT) {
+   result = 0;
+   if (rem_p)
+   *rem_p = divider;
+   } else {
+   result = (u32)dividend / (u32)divider;
+   if (rem_p)
+   *rem_p = (u32)dividend % (u32)divider;
+   }
+   return result;
+   }
+
+   while (divider <= dividend) {
+   u64 locald = divider;
+   u64 limit = __lshrdi3(dividend, 1);
+   int shifts = 0;
+
+   while (locald <= limit) {
+   shifts++;
+   locald = locald + locald;
+   }
+   result |= __ashldi3(1, shifts);
+   

Re: [U-Boot] [PATCH] x86: conga-qeval20-qa3-e3845: Adjust VGA rom address

[Stefan Roese]

On 17.11.2017 02:29, Anatolij Gustschin wrote:

Adjust VGA rom address to 0xfffb so that u-boot.rom image
can be built again.

Signed-off-by: Anatolij Gustschin 
---
  configs/conga-qeval20-qa3-e3845-internal-uart_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig 
b/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
index 59bde05c80..535bfe411d 100644
--- a/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
+++ b/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
@@ -6,6 +6,7 @@ CONFIG_INTERNAL_UART=y
  CONFIG_DEBUG_UART=y
  CONFIG_SMP=y
  CONFIG_HAVE_VGA_BIOS=y
+CONFIG_VGA_BIOS_ADDR=0xfffb
  CONFIG_GENERATE_PIRQ_TABLE=y
  CONFIG_GENERATE_MP_TABLE=y
  CONFIG_GENERATE_ACPI_TABLE=y



Reviewed-by: Stefan Roese 

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

Re: [U-Boot] Please pull u-boot-marvell/master

[Tom Rini]

On Thu, Nov 16, 2017 at 02:09:40PM +0100, Stefan Roese wrote:

> Hi Tom,
> 
> please pull the following pending patches for MVEBU.
> 
> Thanks,
> Stefan
> 
> 
> The following changes since commit c253573f3e269fd9a24ee6684d87dd91106018a5:
> 
>   Prepare v2017.11 (2017-11-13 20:08:06 -0500)
> 
> are available in the Git repository at:
> 
>   git://www.denx.de/git/u-boot-marvell.git 
> 
> for you to fetch changes up to 8c1ce928f498774a3e2c3aa03534b6e6ca6d4759:
> 
>   arm: mvebu: clearfog: update SPI flash DT description (2017-11-16 11:45:20 
> +0100)
> 

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] Please pull fsl-qoriq master

[Tom Rini]

On Wed, Nov 15, 2017 at 10:29:37PM +, York Sun wrote:

> Tom,
> 
> Passed compiling on travis,
> https://travis-ci.org/yorksun/u-boot/builds/302640283, the following
> changes since commit c253573f3e269fd9a24ee6684d87dd91106018a5:
> 
>   Prepare v2017.11 (2017-11-13 20:08:06 -0500)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-fsl-qoriq.git
> 
> for you to fetch changes up to bc085549afb227c2623fac406f958985718fe4c0:
> 
>   armv8: ls2080ardb: Add sd_bootcmd for distro fallback in case of
> sdboot (2017-11-15 10:56:35 -0800)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH] x86: conga-qeval20-qa3-e3845: Adjust VGA rom address

[Anatolij Gustschin]

Adjust VGA rom address to 0xfffb so that u-boot.rom image
can be built again.

Signed-off-by: Anatolij Gustschin 
---
 configs/conga-qeval20-qa3-e3845-internal-uart_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig 
b/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
index 59bde05c80..535bfe411d 100644
--- a/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
+++ b/configs/conga-qeval20-qa3-e3845-internal-uart_defconfig
@@ -6,6 +6,7 @@ CONFIG_INTERNAL_UART=y
 CONFIG_DEBUG_UART=y
 CONFIG_SMP=y
 CONFIG_HAVE_VGA_BIOS=y
+CONFIG_VGA_BIOS_ADDR=0xfffb
 CONFIG_GENERATE_PIRQ_TABLE=y
 CONFIG_GENERATE_MP_TABLE=y
 CONFIG_GENERATE_ACPI_TABLE=y
-- 
2.11.0

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

[U-Boot] [PATCH v3 5/6] binman: add ROM image signing for Bay Trail SoC

[Anatolij Gustschin]

Generate u-boot-verified.rom image containing Secure Boot Manifest
when secure boot option is enabled.

Signed-off-by: Anatolij Gustschin 
---
NOTE: This patch applies on top of binman changes in binman-working
branch in git://git.denx.de/u-boot-dm.git

Changes in v3:
 - New patch. Moved signing script functionality (secure_boot_helper.py
   in first series) to binman. The signing is enabled automatically
   via u-boot.dtsi when secure boot option is enabled
 - Clean up all temporary files generated by signing script

 arch/x86/dts/u-boot.dtsi |   7 +
 tools/binman/signing/baytrail.py | 313 +++
 tools/binman/signing/signer.py   |   3 +
 3 files changed, 323 insertions(+)
 create mode 100644 tools/binman/signing/baytrail.py

diff --git a/arch/x86/dts/u-boot.dtsi b/arch/x86/dts/u-boot.dtsi
index 7e37d4f394..98e2309108 100644
--- a/arch/x86/dts/u-boot.dtsi
+++ b/arch/x86/dts/u-boot.dtsi
@@ -15,6 +15,13 @@
sort-by-pos;
pad-byte = <0xff>;
size = ;
+#ifdef CONFIG_BAYTRAIL_SECURE_BOOT
+   sign;
+#ifdef CONFIG_SYS_SOC
+   socname = CONFIG_SYS_SOC;
+#endif
+#endif
+
 #ifdef CONFIG_HAVE_INTEL_ME
intel-descriptor {
filename = CONFIG_FLASH_DESCRIPTOR_FILE;
diff --git a/tools/binman/signing/baytrail.py b/tools/binman/signing/baytrail.py
new file mode 100644
index 00..3bfbbedb5d
--- /dev/null
+++ b/tools/binman/signing/baytrail.py
@@ -0,0 +1,313 @@
+# Copyright (c) 2017 DENX Software Engineering
+# Written by Markus Valentin 
+# Adapted for binman integration: Anatolij Gustschin 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Functions for signing the binman output image for Bay Trail SoC
+#
+
+import binascii
+import logging, sys
+import os
+
+from hashlib import sha256
+from os.path import basename, isfile, splitext
+from os.path import join as pjoin
+from struct import pack
+
+import OpenSSL
+from OpenSSL import crypto
+from cryptography import x509
+from cryptography.hazmat.backends import default_backend
+
+FSP_FILE_NAME = "fsp-sb.bin"
+FSP_STAGE2_FILE_NAME = "fsp_stage2.bin"
+U_BOOT_ROM_FILE_NAME = 'u-boot.rom'
+OUTPUT_FILE_NAME = 'u-boot-verified.rom'
+U_BOOT_TO_SIGN_FILE_NAME = 'u-boot-to-sign.bin'
+IBB_FILE_NAME = 'ibb.bin'
+FPF_CONFIG_FILE_NAME = 'fpf_config.txt'
+SIGNED_MANIFEST_FILE_NAME = 'signed_manifest.bin'
+UNSIGNED_MANIFEST_FILE_NAME = 'un'+SIGNED_MANIFEST_FILE_NAME
+OEM_FILE_NAME = 'oemdata.bin'
+
+OEM_PRIV_KEY_FILE_NAME = 'oemkey.pem'
+OEM_PUB_KEY_FILE_NAME = 'pub_oemkey.pem'
+OEM_PUBKEY_BIN_FILE_NAME = 'pub_oemkey.bin'
+OEM_PUBKEY_AND_SIG_FILE_NAME = 'oem_pub_sig.bin'
+
+FIT_PUB_KEY_FILE_NAME = "dev.crt"
+
+# FSP Stage2 size is 0x1f400. For debug FSP it is 0x2f400,
+# you must change it here wenn building with debug FSP image!
+FSP_STAGE_2_SIZE = 0x1f400
+FSP_UPD_SIZE = 0xc00
+IBB_SIZE = 0x1fc00
+MANIFEST_SIZE = 0x400
+OEM_BLOCK_MAX_SIZE = 0x190
+U_BOOT_ROM_SIZE = 0x80
+ROMFILE_SYS_TEXT_BASE = 0x0070
+
+MANIFEST_IDENTIFIER = b'$VBM'
+VERSION = 1
+SECURE_VERSION_NUMBER = 2
+OEM_DATA_PREAMBLE = '01000200'
+
+oem_data_hash_files = []
+
+
+def append_binary_files(first_file, second_file, new_file):
+with open(new_file, 'wb') as f:
+f.write(bytearray(open(first_file, 'rb').read()))
+f.write(bytearray(open(second_file, 'rb').read()))
+
+
+# This function creates the OEM-Data block which must be inserted
+# into the Bay Trail Secure Boot Manifest.
+def assemble_oem_data(file_path):
+file_size = 0
+with open(file_path, 'wb') as f:
+f.write(binascii.unhexlify(OEM_DATA_PREAMBLE))
+file_size += 4
+for hash_file in oem_data_hash_files:
+f.write(open(hash_file, 'rb').read())
+file_size += 32
+pad_file_with_zeros(f, OEM_BLOCK_MAX_SIZE-file_size)
+
+
+# This function creates the final U-Boot ROM image from
+# the original u-boot.rom and the signed Initial Boot Block
+# which contains the Secure Boot Manifest
+def assemble_secure_boot_image(u_boot_rom, signed_ibb):
+data = bytearray(open(u_boot_rom, 'rb').read())
+ibb = bytearray(open(signed_ibb, 'rb').read())
+data[-(MANIFEST_SIZE+IBB_SIZE):] = ibb
+open(OUTPUT_FILE_NAME, 'wb').write(data)
+
+
+# Constructs a complete Secure Boot Manifest which is just missing
+# the OEM publickey and the manifest signature
+def create_unsigned_secure_boot_manifest(unsigned_manifest,
+ oem_file='oemdata.bin',
+ ibb='ibb.bin'):
+with open(unsigned_manifest, 'wb') as f:
+f.write(MANIFEST_IDENTIFIER)
+f.write(pack('i', VERSION))
+f.write(pack('i', MANIFEST_SIZE))
+f.write(pack('i', SECURE_VERSION_NUMBER))
+pad_file_with_zeros(f, 4)
+hash_function = sha256()
+hash_function.update(bytearray(open(ibb, 'rb').read()))
+

[U-Boot] [PATCH v3 6/6] doc: x86: Add section about secure boot on Bay Trail

[Anatolij Gustschin]

From: Markus Valentin 

Add short summary describing preparations for enabling secure boot
feature on Bay Trail SoC.

Signed-off-by: Markus Valentin 
Signed-off-by: Anatolij Gustschin 
---
Changes in v3:
 - add commit message
 - use 'U-Boot' consistently
 - reword and improve text since binman is now used for image signing

 doc/README.x86 | 49 +
 1 file changed, 49 insertions(+)

diff --git a/doc/README.x86 b/doc/README.x86
index 772e8d2a86..b64158816b 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -1141,6 +1141,53 @@ provides the same EFI run-time services) is not 
currently supported on x86.
 
 See README.efi for details of EFI support in U-Boot.
 
+Secure Boot for Bay Trail
+-
+U-Boot for Bay Trail based platforms supports booting in a verified manner 
using
+the Trusted Execution Enginge (TXE). To enable secure boot you need to enable
+the Kconfig option CONFIG_BAYTRAIL_SECURE_BOOT.
+
+The verification of U-Boot happens by a public key appended to the so called
+Secure Boot Manifest. The manifest will be created by binman after building
+the u-boot.rom image (by tools/binman/signing/baytrail.py script). binman
+will generate "u-boot-verified.rom" image containing the manifest. This
+image can be installed in SPI-NOR flash.
+
+To be able to perform a verified boot with U-Boot you need:
+ * A secure-boot-enabled FSP[18] which we can assemble with the BCT Tool[19]
+   (the secure-boot-enabled FSP should be placed as fsp-sb.bin in the
+   board directory)
+ * A OEM-keypair which we use to sign U-Boot. Create this yourself in the
+   build output directory like below:
+   mkdir keydir && \
+   openssl req -batch -x509 -nodes -newkey rsa:2048 \
+-keyout 'keydir/oemkey.pem' -out 'keydir/pub_oemkey.pem'
+   When secure boot option is enabled, the signing script expects
+   the keys to be in the 'keydir' subdir in the build output directory.
+ * fpf_config.txt file in the build output directory.
+   Copy the original FpfConfigFile.txt file from the TXE Firmware Kit to
+   fpf_config.txt. When fpf_config.txt file is present, the binman will
+   update its fuse file entry with the actual hash of the public part of
+   the OEM signing key (FUSE_FILE_OEM_KEY_HASH_1:). The secure-boot-enable
+   fuse file entry (FUSE_FILE_SECURE_BOOT_EN:) will also be enabled.
+   The modified fuse register configuration file can be used by the Intel
+   FPT tool to write fuses (the FPT tool is provided in the TXE Firmware
+   Kit. To burn fuses run "FPT -writebatch fpf_config.txt" on the target).
+
+If these prerequisites are met, you can enable CONFIG_BAYTRAIL_SECURE_BOOT
+option and build U-Boot. The following commands give an example flow for the
+Congatec conga-QA3 SoM on QEVAL 2.0 evalboard:
+   make conga-qeval20-qa3-e3845-internal-uart-secure-boot_defconfig
+   make all
+   make u-boot.rom
+
+This creates "u-boot-verified.rom" image. It can be used as the normal
+u-boot.rom. For enabling the verification you need to configure the OTP fuses
+either by burning them by FPT tool or by using the FPF-Mirroring feature
+for testing while development (see TXE Firmware Kit documentation for more
+details). Further authentication (Kernel/DTB) can be done with the FIT image
+mechanism.
+
 64-bit Support
 --
 U-Boot supports booting a 64-bit kernel directly and is able to change to
@@ -1183,3 +1230,5 @@ References
 [15] doc/device-tree-bindings/misc/intel,irq-router.txt
 [16] http://www.acpi.info
 [17] https://www.acpica.org/downloads
+[18] https://github.com/IntelFsp/FSP.git
+[19] https://github.com/IntelFsp/BCT.git
-- 
2.11.0

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

[U-Boot] [PATCH v3 4/6] binman: add optional support for U-Boot image signing

[Anatolij Gustschin]

Prepare binman for adding image signing support after final image
build stage. Custom image signing functionality for SoCs supporting
verified boot can be added, e.g. like in the subsequent patch with
signing functionality for Bay Trail SoC images.

Read 'sign' and 'socname' properties in /binman node of the DTS file
and setup the SoC specific signing method, if these properties are
present. The directory with signing keys can be specified by '--keydir'
option. The keys are supposed to be in the 'keydir' directory if no
keydir option was given.

Signed-off-by: Anatolij Gustschin 
---
NOTE: This patch applies on top of binman changes in binman-working
branch in git://git.denx.de/u-boot-dm.git

Changes in v3:
 - None, new patch in this series

 tools/binman/binman.py |  3 +++
 tools/binman/cmdline.py|  2 ++
 tools/binman/control.py|  1 +
 tools/binman/image.py  | 23 +++
 tools/binman/signing/signer.py | 22 ++
 5 files changed, 51 insertions(+)
 create mode 100644 tools/binman/signing/signer.py

diff --git a/tools/binman/binman.py b/tools/binman/binman.py
index 1c8e8dbff6..ad5f351261 100755
--- a/tools/binman/binman.py
+++ b/tools/binman/binman.py
@@ -27,6 +27,9 @@ sys.path.insert(0, 'scripts/dtc/pylibfdt')
 # Also allow entry-type modules to be brought in from the etype directory.
 sys.path.insert(0, os.path.join(our_path, 'etype'))
 
+# Bring in the module for image signing
+sys.path.insert(0, os.path.join(our_path, 'signing'))
+
 import cmdline
 import command
 import control
diff --git a/tools/binman/cmdline.py b/tools/binman/cmdline.py
index 233d5e1d1a..bc47949e40 100644
--- a/tools/binman/cmdline.py
+++ b/tools/binman/cmdline.py
@@ -29,6 +29,8 @@ def ParseArgs(argv):
 help='Enabling debugging (provides a full traceback on error)')
 parser.add_option('-I', '--indir', action='append',
 help='Add a path to a directory to use for input files')
+parser.add_option('-K', '--keydir', type='string', action='store', 
default="keydir",
+help='Path to the directory with image signing keys')
 parser.add_option('-H', '--full-help', action='store_true',
 default=False, help='Display the README file')
 parser.add_option('-O', '--outdir', type='string',
diff --git a/tools/binman/control.py b/tools/binman/control.py
index ffa2bbd80f..2ad1ebf3fb 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -113,6 +113,7 @@ def Binman(options, args):
 image.ProcessEntryContents()
 image.WriteSymbols()
 image.BuildImage()
+image.SignImage(options)
 finally:
 tools.FinaliseOutputDir()
 finally:
diff --git a/tools/binman/image.py b/tools/binman/image.py
index 741630f091..2dfa00ae57 100644
--- a/tools/binman/image.py
+++ b/tools/binman/image.py
@@ -15,6 +15,7 @@ import sys
 
 import fdt_util
 import tools
+from signer import GetImageSigner
 
 class Image:
 """A Image, representing an output from binman
@@ -48,6 +49,9 @@ class Image:
  This causes _skip_at_start to be set to the starting memory
  address.
 _entries: OrderedDict() of entries
+_sign: Flag to indicate whether image signing is requested
+_socname: Name of the SoC used to obtain the signer object
+_signer: Signer object implementing SoC specific signing function
 """
 def __init__(self, name, node, test=False):
 global entry
@@ -67,6 +71,9 @@ class Image:
 self._skip_at_start = 0
 self._end_4gb = False
 self._entries = OrderedDict()
+self._sign = False
+self._signer = None
+self._socname = None
 
 if not test:
 self._ReadNode()
@@ -92,6 +99,15 @@ class Image:
 if self._end_4gb:
 self._skip_at_start = 0x1 - self._size
 
+self._sign = fdt_util.GetBool(self._node, 'sign')
+if self._sign:
+self._socname = fdt_util.GetString(self._node, 'socname')
+if not self._socname:
+self._Raise("SoC name must be provided when signing is 
enabled")
+self._signer = GetImageSigner(self._socname)
+if not self._signer:
+self._Raise("No image signer found for SoC '%s'" % 
self._socname)
+
 def CheckSize(self):
 """Check that the image contents does not exceed its size, etc."""
 contents_size = 0
@@ -249,6 +265,13 @@ class Image:
 fd.seek(self._pad_before + entry.pos - self._skip_at_start)
 fd.write(data)
 
+def SignImage(self, options):
+"""Sign the image if verified boot is enabled"""
+if not self._sign:
+return
+fname = tools.GetOutputFilename(self._filename)
+self._signer.sign(fname, options.keydir, options.indir, options.outdir)
+
 def LookupSymbol(self, sym_name, optional, msg):
 

[U-Boot] [PATCH v3 3/6] x86: congatec: add secureboot enabled defconfig for conga-qeval20-qa3-e3845

[Anatolij Gustschin]

From: Markus Valentin 

Add board config file for conga-qeval20-qa3-e3845 target with enabled
secure boot option.

Signed-off-by: Markus Valentin 
Signed-off-by: Anatolij Gustschin 
Reviewed-by: Simon Glass 
---
Changes in v3:
 - add commit description
 - re-order in the patch series to add after patch adding new Kconfig option

Changes in v2:
 - add Reviewed-by tag

 ...0-qa3-e3845-internal-uart-secure-boot_defconfig | 60 ++
 1 file changed, 60 insertions(+)
 create mode 100644 
configs/conga-qeval20-qa3-e3845-internal-uart-secure-boot_defconfig

diff --git 
a/configs/conga-qeval20-qa3-e3845-internal-uart-secure-boot_defconfig 
b/configs/conga-qeval20-qa3-e3845-internal-uart-secure-boot_defconfig
new file mode 100644
index 00..5fcfa64983
--- /dev/null
+++ b/configs/conga-qeval20-qa3-e3845-internal-uart-secure-boot_defconfig
@@ -0,0 +1,60 @@
+CONFIG_X86=y
+CONFIG_VENDOR_CONGATEC=y
+CONFIG_TARGET_CONGA_QEVAL20_QA3_E3845=y
+CONFIG_DEFAULT_DEVICE_TREE="conga-qeval20-qa3-e3845"
+CONFIG_INTERNAL_UART=y
+CONFIG_DEBUG_UART=y
+CONFIG_BAYTRAIL_SECURE_BOOT=y
+CONFIG_SMP=y
+CONFIG_HAVE_VGA_BIOS=y
+CONFIG_VGA_BIOS_ADDR=0xfffb
+CONFIG_GENERATE_PIRQ_TABLE=y
+CONFIG_GENERATE_MP_TABLE=y
+CONFIG_GENERATE_ACPI_TABLE=y
+CONFIG_HAVE_ACPI_RESUME=y
+CONFIG_SEABIOS=y
+CONFIG_FIT=y
+CONFIG_FIT_SIGNATURE=y
+CONFIG_BOOTSTAGE=y
+CONFIG_BOOTSTAGE_REPORT=y
+CONFIG_USE_BOOTARGS=y
+CONFIG_BOOTARGS="root=/dev/sda2 ro quiet"
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_CPU=y
+# CONFIG_CMD_FLASH is not set
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_PART=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_PING=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_BOOTSTAGE=y
+CONFIG_CMD_EXT2=y
+CONFIG_CMD_EXT4=y
+CONFIG_CMD_EXT4_WRITE=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_MAC_PARTITION=y
+CONFIG_ISO_PARTITION=y
+CONFIG_EFI_PARTITION=y
+CONFIG_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_CPU=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_INTEL=y
+CONFIG_WINBOND_W83627=y
+CONFIG_E1000=y
+CONFIG_DEBUG_UART_BASE=0x3f8
+CONFIG_DEBUG_UART_CLOCK=1843200
+CONFIG_USB_STORAGE=y
+CONFIG_USB_KEYBOARD=y
+CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
+CONFIG_FRAMEBUFFER_VESA_MODE_114=y
+CONFIG_CONSOLE_SCROLL_LINES=5
-- 
2.11.0

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

[U-Boot] [PATCH v3 1/6] x86: baytrail: Add fsp-header verification for secure boot FSP

[Anatolij Gustschin]

From: Markus Valentin 

Introduce a new Kconfig variable for secure boot on Bay Trail based
platforms. If this variable is set, the build process tries to use
fsp-sb.bin instead of fsp.bin (-sb is the secure boot enabled FSP).

Also check the two FSP headers against each other and print if secure
boot is enabled or not.

Signed-off-by: Markus Valentin 
Signed-off-by: Anatolij Gustschin 
---
Changes in v3:
 - move BAYTRAIL_SECURE_BOOT to arch/x86/cpu/baytrail/Kconfig
 - Kconfig help text improvements
 - fix crownbay build breakage

Changes in v2:
 - use if (IS_ENABLED(CONFIG_*)) instead of #ifdef
 - s/SB/Secure Boot/
 - minor Kconfig help cleanup

 arch/x86/Kconfig   |  3 ++-
 arch/x86/cpu/baytrail/Kconfig  | 10 ++
 arch/x86/include/asm/fsp/fsp_support.h |  2 ++
 arch/x86/lib/fsp/fsp_support.c | 24 
 4 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 98c56ad7dc..6755e92748 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -350,7 +350,8 @@ config HAVE_FSP
 config FSP_FILE
string "Firmware Support Package binary filename"
depends on HAVE_FSP
-   default "fsp.bin"
+   default "fsp.bin" if !BAYTRAIL_SECURE_BOOT
+   default "fsp-sb.bin" if BAYTRAIL_SECURE_BOOT
help
  The filename of the file to use as Firmware Support Package binary
  in the board directory.
diff --git a/arch/x86/cpu/baytrail/Kconfig b/arch/x86/cpu/baytrail/Kconfig
index 1d876b1927..ff244fcd68 100644
--- a/arch/x86/cpu/baytrail/Kconfig
+++ b/arch/x86/cpu/baytrail/Kconfig
@@ -39,4 +39,14 @@ config DEBUG_UART
bool
select DEBUG_UART_BOARD_INIT
 
+config BAYTRAIL_SECURE_BOOT
+   bool "Enable Secure Boot on Bay Trail"
+   depends on HAVE_FSP
+   default n
+   help
+ Use the secure boot feature of the Bay Trail platform. This switch
+ enables the usage of the secure-boot enabled fsp.bin (fsp-sb.bin).
+ For your board you need to provide this yourself. You can reconfigure
+ your FSP with the Intel BCT tool to enable secure boot.
+
 endif
diff --git a/arch/x86/include/asm/fsp/fsp_support.h 
b/arch/x86/include/asm/fsp/fsp_support.h
index df3add008c..124a4148a0 100644
--- a/arch/x86/include/asm/fsp/fsp_support.h
+++ b/arch/x86/include/asm/fsp/fsp_support.h
@@ -22,6 +22,8 @@
 #define FSP_LOWMEM_BASE0x10UL
 #define FSP_HIGHMEM_BASE   0x1ULL
 #define UPD_TERMINATOR 0x55AA
+#define FSP_FIRST_HEADER_OFFSET0x94
+#define FSP_SECOND_HEADER_OFFSET   0x20494
 
 
 /**
diff --git a/arch/x86/lib/fsp/fsp_support.c b/arch/x86/lib/fsp/fsp_support.c
index e0c49be635..d79a6e900a 100644
--- a/arch/x86/lib/fsp/fsp_support.c
+++ b/arch/x86/lib/fsp/fsp_support.c
@@ -97,6 +97,8 @@ void fsp_continue(u32 status, void *hob_list)
fsp_init_done(hob_list);
 }
 
+#define SB_PRFX"Secure Boot:"
+
 void fsp_init(u32 stack_top, u32 boot_mode, void *nvs_buf)
 {
struct fsp_config_data config_data;
@@ -116,6 +118,14 @@ void fsp_init(u32 stack_top, u32 boot_mode, void *nvs_buf)
panic("Invalid FSP header");
}
 
+   if (IS_ENABLED(CONFIG_BAYTRAIL_SECURE_BOOT)) {
+   /* Compare primary and secondary header */
+   if (memcmp((void *)(CONFIG_FSP_ADDR + FSP_FIRST_HEADER_OFFSET),
+  (void *)(CONFIG_FSP_ADDR + FSP_SECOND_HEADER_OFFSET),
+  fsp_hdr->hdr_len))
+   panic("%s 1st & 2nd FSP headers don't match", SB_PRFX);
+   }
+
config_data.common.fsp_hdr = fsp_hdr;
config_data.common.stack_top = stack_top;
config_data.common.boot_mode = boot_mode;
@@ -130,6 +140,20 @@ void fsp_init(u32 stack_top, u32 boot_mode, void *nvs_buf)
 
fsp_upd = _data.fsp_upd;
 
+   /*
+* On some platforms there is no 'enable_secure_boot' field
+* in VPD region struct, so we have to use ifdef here.
+*/
+   #ifdef CONFIG_BAYTRAIL_SECURE_BOOT
+   /*
+* If the enable secure boot flag is not 1, secure boot has not
+* been activated in the FSP which results in the TXE-Engine not
+* getting loaded
+*/
+   printf("FSP: Secure Boot %sabled\n",
+  fsp_vpd->enable_secure_boot == 1 ? "en" : "dis");
+   #endif
+
/* Copy default data from Flash */
memcpy(fsp_upd, (void *)(fsp_hdr->img_base + fsp_vpd->upd_offset),
   sizeof(struct upd_region));
-- 
2.11.0

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

[U-Boot] [PATCH v3 2/6] x86: baytrail: secureboot: Add functions for verification of U-Boot

[Anatolij Gustschin]

From: Markus Valentin 

Introduce functions that check the integrity of U-Boot by utilising
the hashes stored in the OEM-data block in Secure Boot Manifest.

The verification functions get called in fsp_init()

Signed-off-by: Markus Valentin 
Signed-off-by: Anatolij Gustschin 
---
Changes in v3:
 - lower case in hex numbers 
 - fix RAM stage payload hash calculation and add comments
   for associated macros
 - add comments explaining used stage indexes, s/*_ID/*_IDX
 - fixed two spaces in comment
 - s/devicetree/device tree
 - extend the output messages to give more hints when FIT key
   verification fails
 -

Changes in v2:
 - use 'const void *' for fdt property ptr, drop cast
 - s/u-boot/U-Boot/
 - fix function comment style and move comments to header with
   prototypes. Use fsp_ prefix
 - fix multiline comment style
 - s/SB:/Secure Boot/ for non-debug messages

 arch/x86/cpu/baytrail/Makefile |   1 +
 arch/x86/cpu/baytrail/secure_boot.c| 117 +
 .../include/asm/arch-baytrail/fsp/fsp_configs.h|  24 +
 arch/x86/lib/fsp/fsp_support.c |  18 
 4 files changed, 160 insertions(+)
 create mode 100644 arch/x86/cpu/baytrail/secure_boot.c

diff --git a/arch/x86/cpu/baytrail/Makefile b/arch/x86/cpu/baytrail/Makefile
index a0216f3059..dbf9a82c39 100644
--- a/arch/x86/cpu/baytrail/Makefile
+++ b/arch/x86/cpu/baytrail/Makefile
@@ -8,4 +8,5 @@ obj-y += cpu.o
 obj-y += early_uart.o
 obj-y += fsp_configs.o
 obj-y += valleyview.o
+obj-$(CONFIG_BAYTRAIL_SECURE_BOOT) += secure_boot.o
 obj-$(CONFIG_GENERATE_ACPI_TABLE) += acpi.o
diff --git a/arch/x86/cpu/baytrail/secure_boot.c 
b/arch/x86/cpu/baytrail/secure_boot.c
new file mode 100644
index 00..eaf35c6e24
--- /dev/null
+++ b/arch/x86/cpu/baytrail/secure_boot.c
@@ -0,0 +1,117 @@
+/*
+ * Copyright (C) 2017 Markus Valentin 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+
+#define SB_MANIFEST_BASE   0xfffe
+#define SB_MANIFEST_SIZE   0x400
+#define SB_MANIFEST_OEM_DATA_OFFSET0x58
+#define SB_MANIFEST_OEM_HASH_OFFSET(SB_MANIFEST_OEM_DATA_OFFSET + 4)
+#define SB_MANIFEST_OEM_HASH_BASE  (SB_MANIFEST_BASE + \
+SB_MANIFEST_OEM_HASH_OFFSET)
+#define SB_MANIFEST_END(SB_MANIFEST_BASE + 
SB_MANIFEST_SIZE)
+
+#define FIT_KEY_NAME   "dev"
+#define PUB_KEY_MODULUS_SIZE   0x100
+
+/*
+ * U-Boot in RAM stage payload from reset vector to FSP Stage2:
+ * 0xfff to 0xfffc
+ */
+#define U_BOOT_STAGE_START CONFIG_SYS_TEXT_BASE
+#define U_BOOT_STAGE_SIZE  0xc
+
+/*
+ * Indexes of 32-byte blocks in the OEM-data area containing sha256 hashes
+ * of RAM stage payload, FSP Stage2 and other OEM specific data. The order
+ * of RAM stage payload and FSP Stage2 blocks is fixed (idx 0 and 1),
+ * do not change it. We do not verify FSP Stage2 here, it will be verified
+ * in FSP (FSP Stage2 idx 1 is not used). So, the first index of OEM specific
+ * data block hash must start from 2.
+ */
+#define SHA256_U_BOOT_STAGE_IDX0
+#define SHA256_FIT_PUB_KEY_IDX 2
+
+/**
+ * verify_oem_sha256() - oem data block verification
+ *
+ * This function compares a hash which gets retrieved from the oem data block
+ * with the runtime calculated hash of start_address+size. If they match,
+ * this function returns true. If not, it returns false.
+ *
+ * @hash_idx:  index of oem-data block with hash to compare
+ * @start_address: address where the hash calculation should start
+ * @size:  length of the region for hash calculation
+ *
+ * @retval:true on success, false on error
+ */
+static bool verify_oem_sha256(unsigned int hash_idx,
+ const void *start_address,
+ size_t size)
+{
+   uint8_t value[SHA256_SUM_LEN];
+   int value_len;
+
+   /* Calculate address of hash to compare in the oemdata block */
+   void *hash_to_verify = (void *)SB_MANIFEST_OEM_HASH_BASE +
+  (SHA256_SUM_LEN * hash_idx);
+#ifdef DEBUG
+   unsigned int i = 0;
+   uint8_t oem_value[SHA256_SUM_LEN];
+
+   memcpy(oem_value, hash_to_verify, SHA256_SUM_LEN);
+   printf("SB: hash to verify:\t");
+   for (i = 0; i < SHA256_SUM_LEN; i++)
+   printf("%02X", oem_value[i]);
+   printf("\n");
+#endif
+
+   /* Calculate the hash of the binary */
+   calculate_hash(start_address, size, "sha256", value, _len);
+
+#ifdef DEBUG
+   printf("SB: calculated hash:\t");
+   for (i = 0; i < SHA256_SUM_LEN; i++)
+   printf("%02X", value[i]);
+   printf("\n");
+#endif
+   /* Compare the two hash values */
+   if (memcmp(hash_to_verify, value, SHA256_SUM_LEN))
+   return false;
+   return true;
+}
+

[U-Boot] [PATCH v3 0/6] Introduce secure boot for Bay Trail

[Anatolij Gustschin]

This patch series makes the hardware mechanisms for verified boot on
Bay Trail based platforms usable in/for U-Boot. The series brings in
binman extension which allows to easily create and assemble a Secure
Boot Manifest in the U-Boot ROM image. The manifest gets utilized by
the Trusted Execution Engine on the SoC.

Anatolij Gustschin (2):
  binman: add optional support for U-Boot image signing
  binman: add ROM image signing for Bay Trail SoC

Markus Valentin (4):
  x86: baytrail: Add fsp-header verification for secure boot FSP
  x86: baytrail: secureboot: Add functions for verification of U-Boot
  x86: congatec: add secureboot enabled defconfig for
conga-qeval20-qa3-e3845
  doc: x86: Add section about secure boot on Bay Trail

 arch/x86/Kconfig   |   3 +-
 arch/x86/cpu/baytrail/Kconfig  |  10 +
 arch/x86/cpu/baytrail/Makefile |   1 +
 arch/x86/cpu/baytrail/secure_boot.c| 117 
 arch/x86/dts/u-boot.dtsi   |   7 +
 .../include/asm/arch-baytrail/fsp/fsp_configs.h|  24 ++
 arch/x86/include/asm/fsp/fsp_support.h |   2 +
 arch/x86/lib/fsp/fsp_support.c |  42 +++
 ...0-qa3-e3845-internal-uart-secure-boot_defconfig |  60 
 doc/README.x86 |  49 
 tools/binman/binman.py |   3 +
 tools/binman/cmdline.py|   2 +
 tools/binman/control.py|   1 +
 tools/binman/image.py  |  23 ++
 tools/binman/signing/baytrail.py   | 313 +
 tools/binman/signing/signer.py |  24 ++
 16 files changed, 680 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/cpu/baytrail/secure_boot.c
 create mode 100644 
configs/conga-qeval20-qa3-e3845-internal-uart-secure-boot_defconfig
 create mode 100644 tools/binman/signing/baytrail.py
 create mode 100644 tools/binman/signing/signer.py

-- 
2.11.0

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

Re: [U-Boot] [OE-core] [PATCH] u-boot: Upgrade to 2017.11 release

[Jeroen Hofstee]

Hello Ledislav,


While I see no reason U-Boot list was cc'ed on this patch, your attitude
is almost perfect example how _not_ to do opensource development.



As an occasional reader, it seems that this is a rather harsh, I am sure 
Marex

and Otavio can handle it themselves..

Regards,
Jeroen


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

Re: [U-Boot] [OE-core] [PATCH] u-boot: Upgrade to 2017.11 release

[Ladislav Michl]

On Thu, Nov 16, 2017 at 04:34:51PM -0200, Otavio Salvador wrote:
> On Thu, Nov 16, 2017 at 4:21 PM, Marek Vasut  wrote:
> > On 11/16/2017 01:02 PM, Otavio Salvador wrote:
> >> On Thu, Nov 16, 2017 at 6:12 AM, Marek Vasut  wrote:
> >>> On 11/15/2017 05:47 PM, Stefan Agner wrote:
>  On 2017-11-14 19:32, Otavio Salvador wrote:
> > This upgrades the U-Boot from 2017.09 to 2017.11 release.
> 
>  You might encounter this when building fw_printenv/setenv tools alone:
> 
>  https://lists.denx.de/pipermail/u-boot/2017-November/311505.html
> >>>
> >>> [...]
> >>>
> >  SRC_URI = "git://git.denx.de/u-boot.git \
> >  file://MPC8315ERDB-enable-DHCP.patch \
> >>> I also see that the number of out-of-tree patches didn't change since
> >>> last time, even though I complained about it ... why are these patches
> >>> still here ?
> >>
> >> Because you are the maintainer and didn't do your duty.
> >
> > And what duty is that exactly ? I at least inquired about the status of
> > these patches and reviewed them [1] (the other was not submitted to ML
> > yet and submitter is not responding), so do you have anything else in mind ?
> >
> > [1] https://marc.info/?l=u-boot=150533817907015=2
> 
> Good, so I don't see the reason for the question.
> 
> I did upgrade the recipe and tested. It didn't have patches merged so
> there is nothing I can do. 

Sure there is. Merging patches does not happen automagically, so it is
your (or whoevers, but definitely not maintainers) responsibility to check
upstream status and eventually resubmit.

> You being the maintainer can keep an eye here.

No. Maintainer's job is mostly rejecting poor quality patches and merging
those properly submited, tested and described. What you are asking for
is ussually called babysitting.

> >>> I also see that the number of out-of-tree patches didn't change since
> >>> last time, even though I complained about it ... why are these patches
> >>> still here ?
> 
> Your question was pointless. So instead of "complain" as you said,
> make sure those are merged.

While I see no reason U-Boot list was cc'ed on this patch, your attitude
is almost perfect example how _not_ to do opensource development.

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

Re: [U-Boot] [OE-core] [PATCH] u-boot: Upgrade to 2017.11 release

[Otavio Salvador]

On Thu, Nov 16, 2017 at 4:21 PM, Marek Vasut  wrote:
> On 11/16/2017 01:02 PM, Otavio Salvador wrote:
>> On Thu, Nov 16, 2017 at 6:12 AM, Marek Vasut  wrote:
>>> On 11/15/2017 05:47 PM, Stefan Agner wrote:
 On 2017-11-14 19:32, Otavio Salvador wrote:
> This upgrades the U-Boot from 2017.09 to 2017.11 release.

 You might encounter this when building fw_printenv/setenv tools alone:

 https://lists.denx.de/pipermail/u-boot/2017-November/311505.html
>>>
>>> [...]
>>>
>  SRC_URI = "git://git.denx.de/u-boot.git \
>  file://MPC8315ERDB-enable-DHCP.patch \
>>> I also see that the number of out-of-tree patches didn't change since
>>> last time, even though I complained about it ... why are these patches
>>> still here ?
>>
>> Because you are the maintainer and didn't do your duty.
>
> And what duty is that exactly ? I at least inquired about the status of
> these patches and reviewed them [1] (the other was not submitted to ML
> yet and submitter is not responding), so do you have anything else in mind ?
>
> [1] https://marc.info/?l=u-boot=150533817907015=2

Good, so I don't see the reason for the question.

I did upgrade the recipe and tested. It didn't have patches merged so
there is nothing I can do. You being the maintainer can keep an eye
here.

>>> I also see that the number of out-of-tree patches didn't change since
>>> last time, even though I complained about it ... why are these patches
>>> still here ?

Your question was pointless. So instead of "complain" as you said,
make sure those are merged.

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

Re: [U-Boot] [OE-core] [PATCH] u-boot: Upgrade to 2017.11 release

[Marek Vasut]

On 11/16/2017 01:02 PM, Otavio Salvador wrote:
> On Thu, Nov 16, 2017 at 6:12 AM, Marek Vasut  wrote:
>> On 11/15/2017 05:47 PM, Stefan Agner wrote:
>>> On 2017-11-14 19:32, Otavio Salvador wrote:
 This upgrades the U-Boot from 2017.09 to 2017.11 release.
>>>
>>> You might encounter this when building fw_printenv/setenv tools alone:
>>>
>>> https://lists.denx.de/pipermail/u-boot/2017-November/311505.html
>>
>> [...]
>>
  SRC_URI = "git://git.denx.de/u-boot.git \
  file://MPC8315ERDB-enable-DHCP.patch \
>> I also see that the number of out-of-tree patches didn't change since
>> last time, even though I complained about it ... why are these patches
>> still here ?
> 
> Because you are the maintainer and didn't do your duty.

And what duty is that exactly ? I at least inquired about the status of
these patches and reviewed them [1] (the other was not submitted to ML
yet and submitter is not responding), so do you have anything else in mind ?

[1] https://marc.info/?l=u-boot=150533817907015=2

> Stop complaining and go help please.

I'll just ignore this comment, see above.

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

Re: [U-Boot] [PATCH] mach-stm32: Factorize MPU's region config for STM32 SoCs

[Vikas Manocha]

looks good,

On 11/15/2017 11:59 PM, patrice.chot...@st.com wrote:
> From: Patrice Chotard 
> 
> MPU's region setup can be factorized between STM32F4/F7/H7 SoCs family
> and used a common MPU's region config.
> 
> Only one exception for STM32H7 which doesn't have device area
> located at 0xA000 .
> 
> For STM32F4, configure_clocks() need to be moved from arch_cpu_init()
> to board_early_init_f().
> 
> Signed-off-by: Patrice Chotard 

Reviewed-by: Vikas Manocha 

Cheers,
Vikas

> ---
>  arch/arm/mach-stm32/Makefile   |  3 +-
>  arch/arm/mach-stm32/{stm32h7 => }/soc.c| 25 +--
>  arch/arm/mach-stm32/stm32f4/Makefile   |  2 +-
>  arch/arm/mach-stm32/stm32f4/soc.c  | 41 --
>  arch/arm/mach-stm32/stm32f7/Makefile   |  2 +-
>  arch/arm/mach-stm32/stm32f7/soc.c  | 49 
> --
>  arch/arm/mach-stm32/stm32h7/Makefile   |  8 
>  board/st/stm32f429-discovery/stm32f429-discovery.c |  2 +
>  8 files changed, 16 insertions(+), 116 deletions(-)
>  rename arch/arm/mach-stm32/{stm32h7 => }/soc.c (75%)
>  delete mode 100644 arch/arm/mach-stm32/stm32f4/soc.c
>  delete mode 100644 arch/arm/mach-stm32/stm32f7/soc.c
>  delete mode 100644 arch/arm/mach-stm32/stm32h7/Makefile
> 
> diff --git a/arch/arm/mach-stm32/Makefile b/arch/arm/mach-stm32/Makefile
> index 0f5ac37..c2806af 100644
> --- a/arch/arm/mach-stm32/Makefile
> +++ b/arch/arm/mach-stm32/Makefile
> @@ -4,7 +4,6 @@
>  #
>  # SPDX-License-Identifier:   GPL-2.0+
>  #
> -
> +obj-y += soc.o
>  obj-$(CONFIG_STM32F4) += stm32f4/
>  obj-$(CONFIG_STM32F7) += stm32f7/
> -obj-$(CONFIG_STM32H7) += stm32h7/
> diff --git a/arch/arm/mach-stm32/stm32h7/soc.c b/arch/arm/mach-stm32/soc.c
> similarity index 75%
> rename from arch/arm/mach-stm32/stm32h7/soc.c
> rename to arch/arm/mach-stm32/soc.c
> index 692dbcc..df20d54 100644
> --- a/arch/arm/mach-stm32/stm32h7/soc.c
> +++ b/arch/arm/mach-stm32/soc.c
> @@ -9,11 +9,6 @@
>  #include 
>  #include 
>  
> -u32 get_cpu_rev(void)
> -{
> - return 0;
> -}
> -
>  int arch_cpu_init(void)
>  {
>   int i;
> @@ -30,11 +25,11 @@ int arch_cpu_init(void)
>   { 0x, REGION_0, XN_DIS, PRIV_RW_USR_RW,
>   O_I_WB_RD_WR_ALLOC, REGION_4GB },
>  
> - /* Code area, executable & strongly ordered */
> - { 0xD000, REGION_1, XN_EN, PRIV_RW_USR_RW,
> - STRONG_ORDER, REGION_8MB },
> + /* armv7m code area */
> + { 0x, REGION_1, XN_DIS, PRIV_RW_USR_RW,
> + STRONG_ORDER, REGION_512MB },
>  
> - /* Device area in all H7 : Not executable */
> + /* Device area : Not executable */
>   { 0x4000, REGION_2, XN_EN, PRIV_RW_USR_RW,
>   DEVICE_NON_SHARED, REGION_512MB },
>  
> @@ -42,8 +37,14 @@ int arch_cpu_init(void)
>* Armv7m fixed configuration: strongly ordered & not
>* executable, not cacheable
>*/
> - { 0xE000, REGION_4, XN_EN, PRIV_RW_USR_RW,
> + { 0xE000, REGION_3, XN_EN, PRIV_RW_USR_RW,
>   STRONG_ORDER, REGION_512MB },
> +
> +#if !defined(CONFIG_STM32H7)
> + /* Device area : Not executable */
> + { 0xA000, REGION_4, XN_EN, PRIV_RW_USR_RW,
> + DEVICE_NON_SHARED, REGION_512MB },
> +#endif
>   };
>  
>   disable_mpu();
> @@ -53,7 +54,3 @@ int arch_cpu_init(void)
>  
>   return 0;
>  }
> -
> -void s_init(void)
> -{
> -}
> diff --git a/arch/arm/mach-stm32/stm32f4/Makefile 
> b/arch/arm/mach-stm32/stm32f4/Makefile
> index 020e783..63db820 100644
> --- a/arch/arm/mach-stm32/stm32f4/Makefile
> +++ b/arch/arm/mach-stm32/stm32f4/Makefile
> @@ -8,4 +8,4 @@
>  # SPDX-License-Identifier:   GPL-2.0+
>  #
>  
> -obj-y += soc.o clock.o timer.o
> +obj-y += clock.o timer.o
> diff --git a/arch/arm/mach-stm32/stm32f4/soc.c 
> b/arch/arm/mach-stm32/stm32f4/soc.c
> deleted file mode 100644
> index 9eb655a..000
> --- a/arch/arm/mach-stm32/stm32f4/soc.c
> +++ /dev/null
> @@ -1,41 +0,0 @@
> -/*
> - * (C) Copyright 2015
> - * Kamil Lulko, 
> - *
> - * SPDX-License-Identifier:  GPL-2.0+
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -u32 get_cpu_rev(void)
> -{
> - return 0;
> -}
> -
> -int arch_cpu_init(void)
> -{
> - struct mpu_region_config stm32_region_config[] = {
> - { 0x, REGION_0, XN_DIS, PRIV_RW_USR_RW,
> - STRONG_ORDER, REGION_4GB },
> - };
> - int i;
> -
> - configure_clocks();
> - /*
> -  * Configure the memory protection unit (MPU) to allow full access to
> -  * the whole 4GB address space.
> -  */
> - disable_mpu();
> - for (i = 0; i < ARRAY_SIZE(stm32_region_config); i++)
> - mpu_config(_region_config[i]);
> - 

Re: [U-Boot] [PATCH v2 4/6] pico-imx6ul: Define partition layout in the environment

[Fabio Estevam]

On Thu, Nov 16, 2017 at 9:59 AM, Otavio Salvador
 wrote:
> From: Fabio Berton 
>
> Create layout with a boot 16MiB partition and rootfs with remain
> space.
>
> Signed-off-by: Fabio Berton 
> Signed-off-by: Otavio Salvador 

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

Re: [U-Boot] [PATCH v2 2/6] pico-imx6ul: Use PARTUUID to specify the rootfs location

[Fabio Estevam]

On Thu, Nov 16, 2017 at 9:59 AM, Otavio Salvador
 wrote:
> From: Fabio Berton 
>
> Currently the rootfs location is passed via mmcblk number and using
> the UUID method to specify the rootfs location is a better approach
> working even if mmcblk number for the eMMC changes depending on the
> kernel versions.
>
> Signed-off-by: Fabio Berton 
> Signed-off-by: Otavio Salvador 

Reviewed-by: Fabio Estevam 

(You should have kept my Reviewed-by tag on the other patches that you
resent without changes)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Tom Rini]

On Thu, Nov 16, 2017 at 11:41:57AM +, Andre Przywara wrote:
> Hi,
> 
> On 16/11/17 11:21, Maxime Ripard wrote:
> > On Thu, Nov 16, 2017 at 10:30:38AM +, Andre Przywara wrote:
> >> Hi,
> >>
> >> On 15/11/17 21:03, Alexander Graf wrote:
> >>>
> >>>
> >>> On 15.11.17 11:11, Maxime Ripard wrote:
>  The partitions variable is especially useful to create a partition table
>  from U-Boot, either directly from the U-Boot shell, or through flashing
>  tools like fastboot and its oem format command.
> 
>  This is especially useful on devices with an eMMC you can't take out to
>  flash from another system, and booting a Linux system first to flash our
>  system then is not really practical.
> 
>  Signed-off-by: Maxime Ripard 
>  ---
>   include/configs/sunxi-common.h | 7 +++
>   1 file changed, 7 insertions(+)
> 
>  diff --git a/include/configs/sunxi-common.h 
>  b/include/configs/sunxi-common.h
>  index 4391a8cbc824..11da6ccfbf54 100644
>  --- a/include/configs/sunxi-common.h
>  +++ b/include/configs/sunxi-common.h
>  @@ -493,6 +493,12 @@ extern int soft_i2c_gpio_scl;
>   #define SUNXI_MTDPARTS_DEFAULT
>   #endif
>   
>  +#define PARTS_DEFAULT \
>  +"name=loader1,start=8k,size=32k;" \
>  +"name=loader2,size=984k;" \
>  +"name=boot,size=128M,bootable;" \
>  +"name=system,size=-;"
> >>>
> >>> Is there a particular reason you're creating a boot and system
> >>> partition? In a normal distro world, the distro installer will take care
> >>> of creating ESP + root + swap + whatever for you - and they (or the user
> >>> driving the installation) usually know best what they need :)

So, from another part of this thread, yes, this should not be called
boot but be called esp so it's clearer.

> >> But do we actually care about this?
> > 
> > I do.
> 
> I know, this was a misunderstanding, sorry. By "we" I meant Alex and
> Karsten's generic distribution point of view. I was arguing that this
> patch is of no big importance for them.
> 
> I think we agree that there are quite different use cases, and I don't
> fight the usefulness of both.

Yes, "we" care about the use case here.  No one wants to re-invent the
wheel on "how do I find and boot the OS" and the generic distro
framework is fairly easy for most cases to tap into.

And then on the "we" side of things, the problem here that everyone
needs to care about it how do we setup a partition table so that we can
have SPL where it's required by firmware to be.  How is this particular
hurdle handled today in fedora/debian/opensuse?

> >> If I understand this correctly, these are default settings for
> >> U-Boot's "mtdparts default" command, which honestly I didn't even
> >> know existed so far.
> > 
> > No, this has nothing to do with MTD. It's a default GPT partitioning
> > scheme. And only when you want to create the table from U-Boot, it
> > will not mangle with any pre-existing partition table if there is any
> > (unless you tell U-Boot to overwrite it, of course).
> 
> This is what I tried to say: It only affects you if you use U-Boot's
> partitioning command, which you probably won't do if you are running an
> off-the-shelf distribution installer. Is that understanding correct?
> 
> >> So in a distribution scenario I wouldn't expect somebody to actually use
> >> this. Instead you boot from a (possibly unpartitioned) SD card with just
> >> U-Boot on it or from SPI flash, then launch an installer from somewhere
> >> (PXE, USB drive) and let it do its job. No U-Boot partition involved.
> >> And even if you use mtdpart, you can always override these default
> >> settings on the command line.
> > 
> > Like I was telling Alexander, that makes a number of assumptions, the
> > two most obvious one being that you have an installer and that you
> > want to use it, both with reasonable reasons on why they wouldn't be
> > true.
> > 
> > More tailored fit distros like ELBE, yocto or Buildroot will not have
> > an installer in the first place but an image.
> > 
> > And even if you have an installer for the distro you want to use, if
> > you ever go to production, you will not use it since the time spent to
> > flash a pre-filled image compared to running the installer is
> > significantly lower. And time is money :)
> > 
> > Just like plugging / unplugging microSD card isn't really realistic in
> > that scenario.
> 
> I don't argue this (see above) and surely understand that generic
> installers don't fly when it comes to bootstrapping devices.

My recollection from having installed Debian the other week is that you
can say "I have things partitioned, please use this".  And what we're
talking about here is that there's cases where we might want to have a
layout suggested to the user / distribution.

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot 

[U-Boot] Fw: u-boot soft and hard ethernet addresses

[Duncan Hare]

Dear Duncan,

In message <1814106598.1047276.1510787951...@mail.yahoo.com> you wrote:
>
> Many board manufacturers "assign" this unique MAC address by printing it on a 
> sticker and sticking that on the board somewhere. It's pretty darn hard to 
> read a printed sticker in software, so we have to revert to solutions that 
> actually work.

Such solutions usually include a barcode reader attached to some PC
which is used when you commission the board.  And yes, in this case
it is mandatory that the MAC address(es) stored in the environment
(which gets initialized as part of the aforementioned commissioning
procedure) takes precedence over any MAC address(es) that might be
stored somewhere in the hardware.

> In the "clever things" department, protocols like IPv6 merrily broadcast your 
> MAC address across gateways on the big bad internet, so if you value your 
> privacy, you'll appreciate the possibility to change your MAC address at will.

Right, this is another of a list of reasons why changing the MAC
address makes a lot of sense.

Best regards,

Wolfgang Denk

-- 

Wolfgang
I agree. Some Ethernet adapters/chip/cell libraries have burnt in Ethernet 
addresses.
Some do not.
I'm not saying anything is good or bad, I am,  stating , if one wants to use 
the burnt in address, 
if it exists, there is a mechanism in U-Boot to do so.

I carefully did not state an opinion. Having a soft coded mac address makes 
replication of software 
on units complex. Having a burnt in hardware address makes software replication 
simple, but addscomplexity to hardware manufacturing.

Having stated that, there has to be a unique address for the device somewhere, 
either in the 
hardware or software. If in hardware the manufacturer provides the address, If 
in u-boot the 
unique address has to be managed by the customer, and passed to the OS launched 
by u-boot.

IP is the second network architecture which I've used on which expanded its 
address space,  the first wasIBM's SNA. The expansion in both architectures was 
curtailed, or delayed, by having gateways, in IP's case NAT gateways, 
in IBM's SNA it was SNI - SNA Network Interconnect.

Because of the extensive use of gateways, the risk of a device's mac address 
being braodcast to, is hopefully,limited by the gateway. If it is not then one 
need to buy a better gateway which protect one's privacy.

Regards
 Duncan Hare

714 931 7952


   

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

Re: [U-Boot] [PATCH 3/3] x86: baytrail: secureboot: Add functions for verification of U-Boot

[Anatolij Gustschin]

Hi Bin,

Sorry for long delay, I finally got to prepare v3 series.

On Tue, 16 May 2017 22:40:29 +0800
Bin Meng bmeng...@gmail.com wrote:
...
> > +#define SB_MANIFEST_BASE   0xFFFE  
> 
> nits: please use lower case hex and fix this globally in this file

OK, done in v3.

...
> > +#define PUB_KEY_MODULUS_SIZE   0x100
> > +#define U_BOOT_STAGE_SIZE  0xDD360  
> 
> What is this?
> 
> > +#define U_BOOT_OFFSET  0x2CA0  
> 
> and this?

I don't know where these values are comming from, but I think they
are both wrong. A big U-Boot RAM stage part from reset vector remains
unprotected with these. I'll fix U_BOOT_STAGE_SIZE, drop U_BOOT_OFFSET
and will add a comment in v3. Will also adapt the image signing script
as needed.

> > +#define U_BOOT_STAGE_START (CONFIG_SYS_TEXT_BASE + 
> > U_BOOT_OFFSET)
> > +#define U_BOOT_STAGE_END   (U_BOOT_STAGE_START + 
> > U_BOOT_STAGE_SIZE)
> > +
> > +#define SHA256_U_BOOT_STAGE_ID 0
> > +#define SHA256_FSP_STAGE2_ID   1
> > +#define SHA256_FIT_PUB_KEY_ID  2
> > +  
> 
> I believe a comment block is needed for explaining things like number
> 0/1/2, at least where are they coming?

These are indexes of 32-byte blocks in the manifest containing SHA256 hashes,
the stage order is fixed. Will add some comments here in v3.

...
> > +   /* compare the two hash  values */  
> 
> nits: two spaces after 'hash'

OK, fixed.

...
> > +/**
> > + * fsp_verify_u_boot_bin() - U-Boot binary verification
> > + *
> > + * This function verifies the integrity for U-Boot, its devicetree and the 
> > ucode
> > + * appended or inserted to the devicetree.
> > + *
> > + * @retval:true on success, false on error
> > + */
> > +bool fsp_verify_u_boot_bin(void);
> > +
> > +/**
> > + * fsp_verify_public_key() - integrity of public key for fit image 
> > verification
> > + *
> > + * This function verifies the integrity for the modulus of the public key 
> > which
> > + * is stored in the U-Boot devicetree for fit image verification. It tries 
> > to  
> 
> nits: device tree

OK, fixed.

> > + * find the "rsa,modulus" property in the dtb and then verifies it with the
> > + * checksum stored in the oem-data block
> > + *
> > + * @retval:true on success, false on error
> > + */
> > +bool fsp_verify_public_key(void);  
> 
> Again, are these two APIs common for all FSP based platforms?

No, these are used only for Bay Trail secure boot, so the prototypes
are in baytrail specific fsp_configs.h.

...
> > +   /*
> > +* Verification of the public key happens with verification 
> > of
> > +* the devicetree binary (that's where it's stored), this 
> > check  
> 
> nits: device tree

OK, fixed.

> > +* is not necessary, but nice to see it's integer
> > +*/
> > +   if (!fsp_verify_public_key())
> > +   puts("Secure Boot: Failed to verify public key for 
> > fit-image\n");  
> 
> As the comments say it's not necessary, which means it will never
> fail, right? But in case it fails, that means either hardware is doing
> wrong, or software is doing wrong? Can we adjust the output message to
> indicate some hints?

It can fail if the key is missing in the device tree or if the key
hash in the verified boot manifest doesn't match the hash of the key
in the device tree. I'll slightly rework it here to give more hints.

... 
> BTW: I don't see device tree update for the secure boot enabled board,
> like a device tree that has the "rsa,modulus" stuff.

The device tree will be updated by users, they have to supply their
own keys to the mkimage tool and it will insert the signature node
with custom "rsa,modulus" and other properties.

Thanks,

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

Re: [U-Boot] [RESEND PATCH] mtd: nand: zynq: Add support for the NAND lock/unlock operation

[Michal Simek]

On 7.11.2017 03:16, Wilson Lee wrote:
> From: Joe Hershberger 
> 
> Zynq NAND driver is not support for NAND lock or unlock operation.
> Hence, accidentally write into the critical NAND region might cause
> data corruption to occur.
> 
> This commit is to add NAND lock/unlock command into NAND SMC register
> set for NAND lock/unlock operaion.
> 
> Signed-off-by: Joe Hershberger 
> Signed-off-by: Keng Soon Cheah 
> Cc: Chen Yee Chew 
> Cc: Siva Durga Prasad Paladugu 
> Cc: Michal Simek 
> Cc: Scott Wood 
> ---
>  drivers/mtd/nand/zynq_nand.c | 12 
>  1 file changed, 12 insertions(+)

Applied.

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

Re: [U-Boot] [PATCH v2] mtd: zynq: nand: Move board_nand_init() function to board.c

[Michal Simek]

On 15.11.2017 10:14, Wilson Lee wrote:
> Putting board_nand_init() function inside NAND driver was not appropriate
> due to it doesn't allow board vendor to customise their NAND
> initialization code such as adding NAND lock/unlock code.
> 
> This commit was to move the board_nand_init() function from NAND driver
> to board.c file. This allow customization of board_nand_init() function.
> 
> Signed-off-by: Wilson Lee 
> Cc: Joe Hershberger 
> Cc: Keng Soon Cheah 
> Cc: Chen Yee Chew 
> Cc: Albert Aribaud 
> Cc: Michal Simek 
> Cc: Siva Durga Prasad Paladugu 
> Cc: Scott Wood 
> ---
>  arch/arm/mach-zynq/include/mach/nand.h | 9 +
>  drivers/mtd/nand/zynq_nand.c   | 6 --
>  2 files changed, 13 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/mach-zynq/include/mach/nand.h
> 
> diff --git a/arch/arm/mach-zynq/include/mach/nand.h 
> b/arch/arm/mach-zynq/include/mach/nand.h
> new file mode 100644
> index 000..61ef45f
> --- /dev/null
> +++ b/arch/arm/mach-zynq/include/mach/nand.h
> @@ -0,0 +1,9 @@
> +/*
> + * Copyright (C) 2017 National Instruments Corp.
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +
> +void zynq_nand_init(void);
> diff --git a/drivers/mtd/nand/zynq_nand.c b/drivers/mtd/nand/zynq_nand.c
> index dec2c41..076b878 100644
> --- a/drivers/mtd/nand/zynq_nand.c
> +++ b/drivers/mtd/nand/zynq_nand.c
> @@ -1006,7 +1006,7 @@ static int zynq_nand_device_ready(struct mtd_info *mtd)
>   return 0;
>  }
>  
> -static int zynq_nand_init(struct nand_chip *nand_chip, int devnum)
> +int zynq_nand_init(struct nand_chip *nand_chip, int devnum)
>  {
>   struct zynq_nand_info *xnand;
>   struct mtd_info *mtd;
> @@ -1192,12 +1192,14 @@ fail:
>   return err;
>  }
>  
> +#ifdef CONFIG_SYS_NAND_SELF_INIT
>  static struct nand_chip nand_chip[CONFIG_SYS_MAX_NAND_DEVICE];
>  
> -void board_nand_init(void)
> +void __weak board_nand_init(void)
>  {
>   struct nand_chip *nand = _chip[0];
>  
>   if (zynq_nand_init(nand, 0))
>   puts("ZYNQ NAND init failed\n");
>  }
> +#endif
> 

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

[U-Boot] [PATCH] Revert "spi: cadence_qspi_apb: Use 32 bit indirect read transaction when possible"

[Goldschmidt Simon]

This reverts commit b63b46313ed29e9b0c36b3d6b9407f6eade40c8f.

This commit changed cadence_qspi_apb to use bouncebuf.c, which invalidates
the data cache after reading. This is meant for dma transfers only and
breaks the cadence_qspi driver which copies via cpu only: data that is
copied by the cpu is in cache only and the cache invalidation at the end
throws away this data.

Signed-off-by: Simon Goldschmidt 
---
 drivers/spi/cadence_qspi_apb.c | 22 ++
 1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index e02f2217f4..5d5b6f0d35 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -634,8 +634,6 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
 {
unsigned int remaining = n_rx;
unsigned int bytes_to_read = 0;
-   struct bounce_buffer bb;
-   u8 *bb_rxbuf;
int ret;
 
writel(n_rx, plat->regbase + CQSPI_REG_INDIRECTRDBYTES);
@@ -644,11 +642,6 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
writel(CQSPI_REG_INDIRECTRD_START,
   plat->regbase + CQSPI_REG_INDIRECTRD);
 
-   ret = bounce_buffer_start(, (void *)rxbuf, n_rx, GEN_BB_WRITE);
-   if (ret)
-   return ret;
-   bb_rxbuf = bb.bounce_buffer;
-
while (remaining > 0) {
ret = cadence_qspi_wait_for_data(plat);
if (ret < 0) {
@@ -662,13 +655,12 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
bytes_to_read *= CQSPI_FIFO_WIDTH;
bytes_to_read = bytes_to_read > remaining ?
remaining : bytes_to_read;
-   readsl(plat->ahbbase, bb_rxbuf, bytes_to_read >> 2);
-   if (bytes_to_read % 4)
-   readsb(plat->ahbbase,
-  bb_rxbuf + rounddown(bytes_to_read, 4),
-  bytes_to_read % 4);
-
-   bb_rxbuf += bytes_to_read;
+   /* Handle non-4-byte aligned access to avoid data 
abort. */
+   if (((uintptr_t)rxbuf % 4) || (bytes_to_read % 4))
+   readsb(plat->ahbbase, rxbuf, bytes_to_read);
+   else
+   readsl(plat->ahbbase, rxbuf, bytes_to_read >> 
2);
+   rxbuf += bytes_to_read;
remaining -= bytes_to_read;
bytes_to_read = cadence_qspi_get_rd_sram_level(plat);
}
@@ -685,7 +677,6 @@ int cadence_qspi_apb_indirect_read_execute(struct 
cadence_spi_platdata *plat,
/* Clear indirect completion status */
writel(CQSPI_REG_INDIRECTRD_DONE,
   plat->regbase + CQSPI_REG_INDIRECTRD);
-   bounce_buffer_stop();
 
return 0;
 
@@ -693,7 +684,6 @@ failrd:
/* Cancel the indirect read */
writel(CQSPI_REG_INDIRECTRD_CANCEL,
   plat->regbase + CQSPI_REG_INDIRECTRD);
-   bounce_buffer_stop();
return ret;
 }
 
-- 
2.12.2.windows.2

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

[U-Boot] [PATCH v4 2/5] dts: cadence_spi: Sync DT bindings with Linux

[Jason Rush]

Adopt the Linux DT bindings and clean-up duplicate
and unused values.
---
Changes for v4:
   - Rebased

 arch/arm/dts/keystone-k2g-evm.dts |  8 
 arch/arm/dts/keystone-k2g.dtsi|  5 +++--
 arch/arm/dts/socfpga.dtsi |  5 +++--
 arch/arm/dts/socfpga_arria10.dtsi |  4 ++--
 arch/arm/dts/socfpga_arria5_socdk.dts |  9 -
 arch/arm/dts/socfpga_cyclone5_is1.dts |  9 -
 arch/arm/dts/socfpga_cyclone5_socdk.dts   |  9 -
 arch/arm/dts/socfpga_cyclone5_sockit.dts  |  9 -
 arch/arm/dts/socfpga_cyclone5_socrates.dts|  9 -
 arch/arm/dts/socfpga_cyclone5_sr1500.dts  |  9 -
 arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 18 --
 arch/arm/dts/stv0991.dts  | 12 +++-
 12 files changed, 51 insertions(+), 55 deletions(-)

diff --git a/arch/arm/dts/keystone-k2g-evm.dts 
b/arch/arm/dts/keystone-k2g-evm.dts
index de208b3..ba566a4 100644
--- a/arch/arm/dts/keystone-k2g-evm.dts
+++ b/arch/arm/dts/keystone-k2g-evm.dts
@@ -76,10 +76,10 @@
 spi-max-frequency = <9600>;
 #address-cells = <1>;
 #size-cells = <1>;
-tshsl-ns = <392>;
-tsd2d-ns = <392>;
-tchsh-ns = <100>;
-tslch-ns = <100>;
+cdns,tshsl-ns = <392>;
+cdns,tsd2d-ns = <392>;
+cdns,tchsh-ns = <100>;
+cdns,tslch-ns = <100>;
block-size = <18>;
 
 
diff --git a/arch/arm/dts/keystone-k2g.dtsi b/arch/arm/dts/keystone-k2g.dtsi
index 7b2fae6..9bcfea6 100644
--- a/arch/arm/dts/keystone-k2g.dtsi
+++ b/arch/arm/dts/keystone-k2g.dtsi
@@ -92,8 +92,9 @@
  <0x2400 0x400>;
interrupts = ;
num-cs = <4>;
-   fifo-depth = <256>;
-   sram-size = <256>;
+   cdns,fifo-depth = <256>;
+   cdns,fifo-width = <4>;
+   cdns,trigger-address = <0x2400>;
status = "disabled";
};
 
diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
index 8588221..7557aa0 100644
--- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -644,8 +644,9 @@
clocks = <_clk>;
ext-decoder = <0>;  /* external decoder */
num-cs = <4>;
-   fifo-depth = <128>;
-   sram-size = <128>;
+   cdns,fifo-depth = <128>;
+   cdns,fifo-width = <4>;
+   cdns,trigger-address = <0x>;
bus-num = <2>;
status = "disabled";
};
diff --git a/arch/arm/dts/socfpga_arria10.dtsi 
b/arch/arm/dts/socfpga_arria10.dtsi
index 377700d..abfd0bc 100644
--- a/arch/arm/dts/socfpga_arria10.dtsi
+++ b/arch/arm/dts/socfpga_arria10.dtsi
@@ -734,8 +734,8 @@
clocks = <_main_clk>;
ext-decoder = <0>;  /* external decoder */
num-chipselect = <4>;
-   fifo-depth = <128>;
-   sram-size = <512>;
+   cdns,fifo-depth = <128>;
+   cdns,fifo-width = <4>;
bus-num = <2>;
status = "disabled";
};
diff --git a/arch/arm/dts/socfpga_arria5_socdk.dts 
b/arch/arm/dts/socfpga_arria5_socdk.dts
index 7265058..1e91a65 100644
--- a/arch/arm/dts/socfpga_arria5_socdk.dts
+++ b/arch/arm/dts/socfpga_arria5_socdk.dts
@@ -94,10 +94,9 @@
m25p,fast-read;
page-size = <256>;
block-size = <16>; /* 2^16, 64KB */
-   read-delay = <4>;  /* delay value in read data capture register 
*/
-   tshsl-ns = <50>;
-   tsd2d-ns = <50>;
-   tchsh-ns = <4>;
-   tslch-ns = <4>;
+   cdns,tshsl-ns = <50>;
+   cdns,tsd2d-ns = <50>;
+   cdns,tchsh-ns = <4>;
+   cdns,tslch-ns = <4>;
};
 };
diff --git a/arch/arm/dts/socfpga_cyclone5_is1.dts 
b/arch/arm/dts/socfpga_cyclone5_is1.dts
index 16a3283..2e2b71f 100644
--- a/arch/arm/dts/socfpga_cyclone5_is1.dts
+++ b/arch/arm/dts/socfpga_cyclone5_is1.dts
@@ -93,11 +93,10 @@
m25p,fast-read;
page-size = <256>;
block-size = <16>; /* 2^16, 64KB */
-   read-delay = <4>;  /* delay value in read data capture register 
*/
-   tshsl-ns = <50>;
-   tsd2d-ns = <50>;
-   tchsh-ns = <4>;
-   tslch-ns = <4>;
+   cdns,tshsl-ns = <50>;
+   cdns,tsd2d-ns = <50>;
+   cdns,tchsh-ns = <4>;
+   cdns,tslch-ns = <4>;

[U-Boot] [PATCH v4 4/5] dts: k2g: Clean-up indentation

[Jason Rush]

Fix indentation of the QSPI node.
---
Changes for v4:
   - Rebased

 arch/arm/dts/keystone-k2g-evm.dts | 75 +++
 1 file changed, 37 insertions(+), 38 deletions(-)

diff --git a/arch/arm/dts/keystone-k2g-evm.dts 
b/arch/arm/dts/keystone-k2g-evm.dts
index ba566a4..ad746c7 100644
--- a/arch/arm/dts/keystone-k2g-evm.dts
+++ b/arch/arm/dts/keystone-k2g-evm.dts
@@ -68,46 +68,45 @@
  {
status = "okay";
 
-flash0: m25p80@0 {
-compatible = "s25fl512s","spi-flash";
-reg = <0>;
-spi-tx-bus-width = <1>;
-spi-rx-bus-width = <4>;
-spi-max-frequency = <9600>;
-#address-cells = <1>;
-#size-cells = <1>;
-cdns,tshsl-ns = <392>;
-cdns,tsd2d-ns = <392>;
-cdns,tchsh-ns = <100>;
-cdns,tslch-ns = <100>;
+   flash0: m25p80@0 {
+   compatible = "s25fl512s","spi-flash";
+   reg = <0>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <4>;
+   spi-max-frequency = <9600>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   cdns,tshsl-ns = <392>;
+   cdns,tsd2d-ns = <392>;
+   cdns,tchsh-ns = <100>;
+   cdns,tslch-ns = <100>;
block-size = <18>;
 
-
-partition@0 {
-label = "QSPI.u-boot-spl-os";
-reg = <0x 0x0010>;
-};
-partition@1 {
-label = "QSPI.u-boot-env";
-reg = <0x0010 0x0004>;
-};
-partition@2 {
-label = "QSPI.skern";
-reg = <0x0014 0x004>;
-};
-partition@3 {
-label = "QSPI.pmmc-firmware";
-reg = <0x0018 0x004>;
-};
-partition@4 {
-label = "QSPI.kernel";
-reg = <0x001C 0x080>;
-};
-partition@5 {
-label = "QSPI.file-system";
-reg = <0x009C 0x364>;
-};
-};
+   partition@0 {
+   label = "QSPI.u-boot-spl-os";
+   reg = <0x 0x0010>;
+   };
+   partition@1 {
+   label = "QSPI.u-boot-env";
+   reg = <0x0010 0x0004>;
+   };
+   partition@2 {
+   label = "QSPI.skern";
+   reg = <0x0014 0x004>;
+   };
+   partition@3 {
+   label = "QSPI.pmmc-firmware";
+   reg = <0x0018 0x004>;
+   };
+   partition@4 {
+   label = "QSPI.kernel";
+   reg = <0x001C 0x080>;
+   };
+   partition@5 {
+   label = "QSPI.file-system";
+   reg = <0x009C 0x364>;
+   };
+   };
 };
 
  {
-- 
2.1.4

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

[U-Boot] [PATCH v4 3/5] config: cadence_spi: Remove defines read from DT

[Jason Rush]

Cleanup unused #define values that are read from the DT.
---
Changes for v4:
   - Rebased

 include/configs/k2g_evm.h| 1 -
 include/configs/socfpga_common.h | 1 -
 include/configs/stv0991.h| 1 -
 3 files changed, 3 deletions(-)

diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h
index df81c09..535e712 100644
--- a/include/configs/k2g_evm.h
+++ b/include/configs/k2g_evm.h
@@ -93,7 +93,6 @@
 #ifndef CONFIG_SPL_BUILD
 #define CONFIG_CADENCE_QSPI
 #define CONFIG_CQSPI_REF_CLK 38400
-#define CONFIG_CQSPI_DECODER 0x0
 #define CONFIG_BOUNCE_BUFFER
 #endif
 
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index 8a7debb..e5e2f83 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -185,7 +185,6 @@ unsigned int cm_get_l4_sp_clk_hz(void);
 unsigned int cm_get_qspi_controller_clk_hz(void);
 #define CONFIG_CQSPI_REF_CLK   cm_get_qspi_controller_clk_hz()
 #endif
-#define CONFIG_CQSPI_DECODER   0
 #define CONFIG_BOUNCE_BUFFER
 
 /*
diff --git a/include/configs/stv0991.h b/include/configs/stv0991.h
index c99fb67..fd96979 100644
--- a/include/configs/stv0991.h
+++ b/include/configs/stv0991.h
@@ -63,7 +63,6 @@
 + * QSPI support
 + */
 #ifdef CONFIG_OF_CONTROL   /* QSPI is controlled via DT */
-#define CONFIG_CQSPI_DECODER   0
 #define CONFIG_CQSPI_REF_CLK   ((30/4)/2)*1000*1000
 #define CONFIG_BOUNCE_BUFFER
 
-- 
2.1.4

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

[U-Boot] [PATCH v4 1/5] spi: cadence_spi: Sync DT bindings with Linux

[Jason Rush]

Adopt the Linux DT bindings. This also fixes an issue
with the indaddrtrig register on the Cadence QSPI
device being programmed with the wrong value for the
socfpga arch.
---
Changes for v4:
   - Rebased

 drivers/spi/cadence_qspi.c | 20 
 drivers/spi/cadence_qspi.h |  6 +-
 drivers/spi/cadence_qspi_apb.c | 15 ---
 3 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 9a6e41f..991a716 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -212,7 +212,7 @@ static int cadence_spi_xfer(struct udevice *dev, unsigned 
int bitlen,
 
/* Set Chip select */
cadence_qspi_apb_chipselect(base, spi_chip_select(dev),
-   CONFIG_CQSPI_DECODER);
+   plat->is_decoded_cs);
 
if ((flags & SPI_XFER_END) || (flags == 0)) {
if (priv->cmd_len == 0) {
@@ -296,7 +296,11 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
*bus)
 
plat->regbase = (void *)data[0];
plat->ahbbase = (void *)data[2];
-   plat->sram_size = fdtdec_get_int(blob, node, "sram-size", 128);
+   plat->is_decoded_cs = fdtdec_get_bool(blob, node, "cdns,is-decoded-cs");
+   plat->fifo_depth = fdtdec_get_uint(blob, node, "cdns,fifo-depth", 128);
+   plat->fifo_width = fdtdec_get_uint(blob, node, "cdns,fifo-width", 4);
+   plat->trigger_address = fdtdec_get_uint(blob, node,
+   "cdns,trigger-address", 0);
 
/* All other paramters are embedded in the child node */
subnode = fdt_first_subnode(blob, node);
@@ -310,12 +314,12 @@ static int cadence_spi_ofdata_to_platdata(struct udevice 
*bus)
   50);
 
/* Read other parameters from DT */
-   plat->page_size = fdtdec_get_int(blob, subnode, "page-size", 256);
-   plat->block_size = fdtdec_get_int(blob, subnode, "block-size", 16);
-   plat->tshsl_ns = fdtdec_get_int(blob, subnode, "tshsl-ns", 200);
-   plat->tsd2d_ns = fdtdec_get_int(blob, subnode, "tsd2d-ns", 255);
-   plat->tchsh_ns = fdtdec_get_int(blob, subnode, "tchsh-ns", 20);
-   plat->tslch_ns = fdtdec_get_int(blob, subnode, "tslch-ns", 20);
+   plat->page_size = fdtdec_get_uint(blob, subnode, "page-size", 256);
+   plat->block_size = fdtdec_get_uint(blob, subnode, "block-size", 16);
+   plat->tshsl_ns = fdtdec_get_uint(blob, subnode, "cdns,tshsl-ns", 200);
+   plat->tsd2d_ns = fdtdec_get_uint(blob, subnode, "cdns,tsd2d-ns", 255);
+   plat->tchsh_ns = fdtdec_get_uint(blob, subnode, "cdns,tchsh-ns", 20);
+   plat->tslch_ns = fdtdec_get_uint(blob, subnode, "cdns,tslch-ns", 20);
 
debug("%s: regbase=%p ahbbase=%p max-frequency=%d page-size=%d\n",
  __func__, plat->regbase, plat->ahbbase, plat->max_hz,
diff --git a/drivers/spi/cadence_qspi.h b/drivers/spi/cadence_qspi.h
index d1927a4..8315421 100644
--- a/drivers/spi/cadence_qspi.h
+++ b/drivers/spi/cadence_qspi.h
@@ -18,14 +18,18 @@ struct cadence_spi_platdata {
unsigned intmax_hz;
void*regbase;
void*ahbbase;
+   boolis_decoded_cs;
+   u32 fifo_depth;
+   u32 fifo_width;
+   u32 trigger_address;
 
+   // Flash parameters
u32 page_size;
u32 block_size;
u32 tshsl_ns;
u32 tsd2d_ns;
u32 tchsh_ns;
u32 tslch_ns;
-   u32 sram_size;
 };
 
 struct cadence_spi_priv {
diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
index e02f221..8309ab8 100644
--- a/drivers/spi/cadence_qspi_apb.c
+++ b/drivers/spi/cadence_qspi_apb.c
@@ -37,10 +37,6 @@
 #define CQSPI_REG_RETRY1
 #define CQSPI_POLL_IDLE_RETRY  3
 
-#define CQSPI_FIFO_WIDTH   4
-
-#define CQSPI_REG_SRAM_THRESHOLD_WORDS 50
-
 /* Transfer mode */
 #define CQSPI_INST_TYPE_SINGLE 0
 #define CQSPI_INST_TYPE_DUAL   1
@@ -51,9 +47,6 @@
 #define CQSPI_DUMMY_CLKS_PER_BYTE  8
 #define CQSPI_DUMMY_BYTES_MAX  4
 
-#define CQSPI_REG_SRAM_FILL_THRESHOLD  \
-   ((CQSPI_REG_SRAM_SIZE_WORD / 2) * CQSPI_FIFO_WIDTH)
-
 /
  * Controller's configuration and status register (offset from QSPI_BASE)
  /
@@ -400,7 +393,7 @@ void cadence_qspi_apb_controller_init(struct 
cadence_spi_platdata *plat)
writel(0, plat->regbase + CQSPI_REG_REMAP);
 
/* Indirect mode configurations */
-   writel((plat->sram_size/2), plat->regbase + CQSPI_REG_SRAMPARTITION);
+   writel((plat->fifo_depth/2), 

[U-Boot] [PATCH v4 5/5] dts: cadence_spi: Update documentation for DT bindings

[Jason Rush]

Update documentation to reflect adopting the Linux DT bindings.
---
Changes for v4:
   - Updated documentation

 doc/device-tree-bindings/spi/spi-cadence.txt | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/doc/device-tree-bindings/spi/spi-cadence.txt 
b/doc/device-tree-bindings/spi/spi-cadence.txt
index c1e2233..74c8208 100644
--- a/doc/device-tree-bindings/spi/spi-cadence.txt
+++ b/doc/device-tree-bindings/spi/spi-cadence.txt
@@ -6,7 +6,10 @@ Required properties:
 - reg  : 1.Physical base address and size of SPI registers map.
  2. Physical base address & size of NOR Flash.
 - clocks   : Clock phandles (see clock bindings for details).
-- sram-size: spi controller sram size.
+- cdns,fifo-depth  : Size of the data FIFO in words.
+- cdns,fifo-width  : Bus width of the data FIFO in bytes.
+- cdns,trigger-address : 32-bit indirect AHB trigger address.
+- cdns,is-decoded-cs   : Flag to indicate whether decoder is used or not.
 - status   : enable in requried dts.
 
 connected flash properties
@@ -15,14 +18,14 @@ connected flash properties
 - spi-max-frequency: Max supported spi frequency.
 - page-size: Flash page size.
 - block-size   : Flash memory block size.
-- tshsl-ns : Added delay in master reference clocks (ref_clk) for
+- cdns,tshsl-ns: Added delay in master reference clocks 
(ref_clk) for
  the length that the master mode chip select outputs
  are de-asserted between transactions.
-- tsd2d-ns : Delay in master reference clocks (ref_clk) between one
+- cdns,tsd2d-ns: Delay in master reference clocks (ref_clk) 
between one
  chip select being de-activated and the activation of
  another.
-- tchsh-ns : Delay in master reference clocks between last bit of
+- cdns,tchsh-ns: Delay in master reference clocks between last 
bit of
  current transaction and de-asserting the device chip
  select (n_ss_out).
-- tslch-ns : Delay in master reference clocks between setting
+- cdns,tslch-ns: Delay in master reference clocks between 
setting
  n_ss_out low and first bit transfer
-- 
2.1.4

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

[U-Boot] [PATCH v4 0/5] spi: cadence_spi: Adopt Linux DT bindings

[Jason Rush]

Adopt the Linux DT bindings. This also fixes an issue
with the indaddrtrig register on the Cadence QSPI
device being programmed with the wrong value for the
socfpga arch.

Tested on Terasic SoCKit dev board (Altera Cyclone V)

Jason Rush (5):
  spi: cadence_spi: Sync DT bindings with Linux
  dts: cadence_spi: Sync DT bindings with Linux
  config: cadence_spi: Remove defines read from DT
  dts: k2g: Clean-up indentation
  dts: cadence_spi: Update documentation for DT bindings

 arch/arm/dts/keystone-k2g-evm.dts | 75 +--
 arch/arm/dts/keystone-k2g.dtsi|  5 +-
 arch/arm/dts/socfpga.dtsi |  5 +-
 arch/arm/dts/socfpga_arria10.dtsi |  4 +-
 arch/arm/dts/socfpga_arria5_socdk.dts |  9 ++--
 arch/arm/dts/socfpga_cyclone5_is1.dts |  9 ++--
 arch/arm/dts/socfpga_cyclone5_socdk.dts   |  9 ++--
 arch/arm/dts/socfpga_cyclone5_sockit.dts  |  9 ++--
 arch/arm/dts/socfpga_cyclone5_socrates.dts|  9 ++--
 arch/arm/dts/socfpga_cyclone5_sr1500.dts  |  9 ++--
 arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 18 +++
 arch/arm/dts/stv0991.dts  | 12 +++--
 doc/device-tree-bindings/spi/spi-cadence.txt  | 13 +++--
 drivers/spi/cadence_qspi.c| 20 ---
 drivers/spi/cadence_qspi.h|  6 ++-
 drivers/spi/cadence_qspi_apb.c| 15 ++
 include/configs/k2g_evm.h |  1 -
 include/configs/socfpga_common.h  |  1 -
 include/configs/stv0991.h |  1 -
 19 files changed, 113 insertions(+), 117 deletions(-)

-- 
2.1.4

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

Re: [U-Boot] [PATCH] sunxi: add support for Orange Pi R1 board

[Maxime Ripard]

On Mon, Nov 13, 2017 at 08:42:34PM +0800, Icenowy Zheng wrote:
> 在 2017-11-13 20:38，Maxime Ripard 写道：
> > Hi,
> > 
> > On Mon, Nov 13, 2017 at 07:34:46PM +0800, Icenowy Zheng wrote:
> > > +++ b/configs/orangepi_r1_defconfig
> > > @@ -0,0 +1,19 @@
> > > +CONFIG_ARM=y
> > > +CONFIG_ARCH_SUNXI=y
> > > +CONFIG_MACH_SUN8I_H3=y
> > > +CONFIG_DRAM_CLK=624
> > > +CONFIG_DRAM_ZQ=3881979
> > > +CONFIG_DRAM_ODT_EN=y
> > > +# CONFIG_VIDEO_DE2 is not set
> > > +CONFIG_DEFAULT_DEVICE_TREE="sun8i-h2-plus-orangepi-r1"
> > > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > > +CONFIG_CONSOLE_MUX=y
> > 
> > Why?
> 
> This option is also present on the original Orange Pi Zero
> defconfig. If you like I will delete it.

If there's no justifications, then yes, please do.

Thanks!
Maxime

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


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

[U-Boot] Please pull u-boot-marvell/master

[Stefan Roese]

Hi Tom,

please pull the following pending patches for MVEBU.

Thanks,
Stefan


The following changes since commit c253573f3e269fd9a24ee6684d87dd91106018a5:

  Prepare v2017.11 (2017-11-13 20:08:06 -0500)

are available in the Git repository at:

  git://www.denx.de/git/u-boot-marvell.git 

for you to fetch changes up to 8c1ce928f498774a3e2c3aa03534b6e6ca6d4759:

  arm: mvebu: clearfog: update SPI flash DT description (2017-11-16 11:45:20 
+0100)


Baruch Siach (1):
  arm: mvebu: clearfog: update SPI flash DT description

Heinrich Schuchardt (1):
  arm: mvebu: configs: Enable DISTRO_DEFAULTS for MACCHIATObin

Jon Nettleton (4):
  mvebu: usb: xhci: a38x support
  arm: mvebu: Add board_setup for xhci hardware
  arm: mvebu: clearfog: enable XHCI USB
  arm: mvebu: clearfog: Fix SPI-NOR flash access

Stefan Roese (1):
  arm: mvebu: theadorable_debug_defconfig: Enable setexpr command

VlaoMao (1):
  pci: mvebu: Increase size of PCIe default mapping

 arch/arm/dts/armada-388-clearfog.dts| 10 
 arch/arm/mach-mvebu/cpu.c   | 41 +
 board/Marvell/mvebu_armada-37xx/board.c |  2 +-
 board/Marvell/mvebu_armada-8k/board.c   |  2 +-
 configs/clearfog_defconfig  |  6 -
 configs/mvebu_db_armada8k_defconfig |  1 +
 configs/mvebu_mcbin-88f8040_defconfig   |  1 +
 configs/theadorable_debug_defconfig |  1 -
 drivers/pci/pci_mvebu.c |  4 ++--
 drivers/usb/host/xhci-mvebu.c   |  5 ++--
 include/configs/clearfog.h  |  4 +---
 11 files changed, 60 insertions(+), 17 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH RESEND v2 2/2] arm: mvebu: clearfog: update SPI flash DT description

[Stefan Roese]

On 13.11.2017 06:04, Baruch Siach wrote:

All current ClearFog SOMs have the SPI flash populated. Enable SPI flash in
the device tree.

Add an alias to the SPI bus so that the 'sf' command can probe the flash on
bus 1.

Add the "spi-flash" compatible string to make the standard SPI flash driver
probe the device.

Reviewed-by: Jagan Teki 
Signed-off-by: Baruch Siach 
---
v2: Add Jagan's ack


Applied to u-boot-marvell/master.

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

Re: [U-Boot] [PATCH RESEND v2 1/2] arm: mvebu: clearfog: Fix SPI-NOR flash access

[Stefan Roese]

On 13.11.2017 06:04, Baruch Siach wrote:

From: Jon Nettleton 

The production variant of the SPI flash used by the clearfog
devices are based on winbond chips.  Additionally enable
SPI_FLASH_BAR since some variants will have 16MB of flash
that requires this to be enabled.

Remove the default speed and mode; these values are taken from the
device tree when CONFIG_DM_SPI_FLASH is enabled.

Add default bus, so that 'sf' detects the SPI flash by default.

Signed-off-by: Jon Nettleton 
[baruch: remove speed/mode; add bus; move winbond to defconfig]
Signed-off-by: Baruch Siach 
---
v2: Move CONFIG_SPI_FLASH_WINBOND to defconfig (Jagan)


Applied to u-boot-marvell/master.

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

Re: [U-Boot] [PATCH 3/3] arm: mvebu: clearfog: enable XHCI USB

[Stefan Roese]

On 06.11.2017 09:33, Baruch Siach wrote:

From: Jon Nettleton 

Enable the driver by default for the clearfog boards since the external
port is configured for XHCI.

Signed-off-by: Jon Nettleton 
[baruch: split from the SoC setup patch]
Signed-off-by: Baruch Siach 


Applied to u-boot-marvell/master.

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

Re: [U-Boot] [PATCH 1/3] mvebu: usb: xhci: a38x support

[Stefan Roese]

On 06.11.2017 09:33, Baruch Siach wrote:

From: Jon Nettleton 

This makes the initial changes need to support the
a38x series of SOCs.  It adds the device-tree identifier
as well as changing the board_support function to take
the IO address designated by device-tree.

Signed-off-by: Jon Nettleton 
[baruch: use fdt_addr_t; update 37xx and 8K implementations]
Signed-off-by: Baruch Siach 


Applied to u-boot-marvell/master.

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

Re: [U-Boot] [PATCH 2/3] arm: mvebu: Add board_setup for xhci hardware

[Stefan Roese]

On 06.11.2017 09:33, Baruch Siach wrote:

From: Jon Nettleton 

This fixes the USB 3.0 support for the a38x SOC.

Signed-off-by: Jon Nettleton 
[baruch: use fdt_addr_t]
Signed-off-by: Baruch Siach 


Applied to u-boot-marvell/master.

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

Re: [U-Boot] [PATCH 1/1] configs: DISTRO_DEFAULTS for MACCHIATObin

[Stefan Roese]

On 15.10.2017 07:03, Heinrich Schuchardt wrote:

Enable DISTRO_DEFAULTS for
mvebu_db_armada8k_defconfig
mvebu_mcbin-88f8040_defconfig

Signed-off-by: Heinrich Schuchardt 


Applied to u-boot-marvell/master (with slightly modified subject).

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

Re: [U-Boot] [PATCH] arm: mvebu: theadorable_debug_defconfig: Enable setexpr command

[Stefan Roese]

On 06.10.2017 09:11, Stefan Roese wrote:

The setexpr command is useful for scripting, lets enable it for this
platform.

Signed-off-by: Stefan Roese 


Applied to u-boot-marvell/master.

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

Re: [U-Boot] [PATCH] ARM: MV_EBU: Increase size of PCIe default mapping

[Stefan Roese]

Applied to u-boot-marvell/master (with some change to the commit message)

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

Re: [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Emmanuel Vadot]

On Thu, 16 Nov 2017 12:54:13 +0100
Alexander Graf  wrote:

> On 11/16/2017 12:41 PM, Andre Przywara wrote:
> > Hi,
> >
> > On 16/11/17 11:21, Maxime Ripard wrote:
> >> On Thu, Nov 16, 2017 at 10:30:38AM +, Andre Przywara wrote:
> >>> Hi,
> >>>
> >>> On 15/11/17 21:03, Alexander Graf wrote:
> 
>  On 15.11.17 11:11, Maxime Ripard wrote:
> > The partitions variable is especially useful to create a partition table
> > from U-Boot, either directly from the U-Boot shell, or through flashing
> > tools like fastboot and its oem format command.
> >
> > This is especially useful on devices with an eMMC you can't take out to
> > flash from another system, and booting a Linux system first to flash our
> > system then is not really practical.
> >
> > Signed-off-by: Maxime Ripard 
> > ---
> >   include/configs/sunxi-common.h | 7 +++
> >   1 file changed, 7 insertions(+)
> >
> > diff --git a/include/configs/sunxi-common.h 
> > b/include/configs/sunxi-common.h
> > index 4391a8cbc824..11da6ccfbf54 100644
> > --- a/include/configs/sunxi-common.h
> > +++ b/include/configs/sunxi-common.h
> > @@ -493,6 +493,12 @@ extern int soft_i2c_gpio_scl;
> >   #define SUNXI_MTDPARTS_DEFAULT
> >   #endif
> >   
> > +#define PARTS_DEFAULT \
> > +   "name=loader1,start=8k,size=32k;" \
> > +   "name=loader2,size=984k;" \
> > +   "name=boot,size=128M,bootable;" \
> > +   "name=system,size=-;"
>  Is there a particular reason you're creating a boot and system
>  partition? In a normal distro world, the distro installer will take care
>  of creating ESP + root + swap + whatever for you - and they (or the user
>  driving the installation) usually know best what they need :)
> >>> But do we actually care about this?
> >> I do.
> > I know, this was a misunderstanding, sorry. By "we" I meant Alex and
> > Karsten's generic distribution point of view. I was arguing that this
> > patch is of no big importance for them.
> >
> > I think we agree that there are quite different use cases, and I don't
> > fight the usefulness of both.
> >
> >>> If I understand this correctly, these are default settings for
> >>> U-Boot's "mtdparts default" command, which honestly I didn't even
> >>> know existed so far.
> >> No, this has nothing to do with MTD. It's a default GPT partitioning
> >> scheme. And only when you want to create the table from U-Boot, it
> >> will not mangle with any pre-existing partition table if there is any
> >> (unless you tell U-Boot to overwrite it, of course).
> > This is what I tried to say: It only affects you if you use U-Boot's
> > partitioning command, which you probably won't do if you are running an
> > off-the-shelf distribution installer. Is that understanding correct?
> 
> I'm not sure what the envisioned use of this is either. In general, it 
> makes sense to keep the env on a partition and to mark the firmware 
> residing on eMMC as off limits to an OS installer. So some sort of 
> partitioning scheme is very useful and good to have.
> 
> >
> >>> So in a distribution scenario I wouldn't expect somebody to actually use
> >>> this. Instead you boot from a (possibly unpartitioned) SD card with just
> >>> U-Boot on it or from SPI flash, then launch an installer from somewhere
> >>> (PXE, USB drive) and let it do its job. No U-Boot partition involved.
> >>> And even if you use mtdpart, you can always override these default
> >>> settings on the command line.
> >> Like I was telling Alexander, that makes a number of assumptions, the
> >> two most obvious one being that you have an installer and that you
> >> want to use it, both with reasonable reasons on why they wouldn't be
> >> true.
> >>
> >> More tailored fit distros like ELBE, yocto or Buildroot will not have
> >> an installer in the first place but an image.
> >>
> >> And even if you have an installer for the distro you want to use, if
> >> you ever go to production, you will not use it since the time spent to
> >> flash a pre-filled image compared to running the installer is
> >> significantly lower. And time is money :)
> >>
> >> Just like plugging / unplugging microSD card isn't really realistic in
> >> that scenario.
> > I don't argue this (see above) and surely understand that generic
> > installers don't fly when it comes to bootstrapping devices.
> >
> > But my understanding is that both Alex and Karsten don't really care
> > about this usage scenario, but instead are more looking into generic
> > distribution installers, which use U-Boot merely to launch grub.
> >
> > Actually I wanted to help you out here by pointing out that their
> > concerns don't really apply to this patch ;-)
> >
> >>> Does mtdparts even use partition tables (MBR/GPT)? mtd sounds quite
> >>> Android-y/embedded to me (passing partition information via command line).
> >>>
> >>> So apart from that 

Re: [U-Boot] [ANN] U-Boot v2017.11-rc4 released

[Jaehoon Chung]

Hi Tom,

On 2017년 11월 08일 07:48, Tom Rini wrote:
> On Tue, Nov 07, 2017 at 08:13:02AM +0100, Jorge Ramirez wrote:
>> On 11/07/2017 12:28 AM, Tom Rini wrote:
>>> Hey all,
>>>
>>> It's release day and v2017.11-rc4 is out.  It's a week until release
>>> day.  Please let me know if you know of any regressions, thanks!
>>
>> Hi Tom,
>>
>> emmc accesses are broken for dragonboard410c
>> I posted the fix [1] last week. will you merge it?
> 
> [1] is: https://patchwork.ozlabs.org/patch/833376/
> 
> Jaehoon, are you OK with this patch?  Thanks!

If you didn't apply this, i will pick after checking. 
And will send PR with other patches.

Thanks!

Best Regards,
Jaehoon Chung

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

Re: [U-Boot] mmc1 not working on Samsung snow chromebook

[Guillaume Gardet]

I found a workaround. If I disable MMC_MODE_HS_52MHz, then it is working fine.

I guess there is a better way to implement the following patch ?

**
diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
index 23f642980b..a6a0934eef 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;
+   /* MMC_MODE_HS_52MHz is broken (at least) on Samsung Snow, so disbale 
it for now */
+   cfg->host_caps |= MMC_MODE_HS;

    cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
 }
**


Guillaume



Le 15/11/2017 à 11:27, Guillaume Gardet a écrit :



Le 15/11/2017 à 11:22, Guillaume Gardet a écrit :

Forgot to Cc ML. Done now.


Le 15/11/2017 à 11:14, Guillaume Gardet a écrit :

Hello,

I tested U-Boot v2017.09 on a Samsung Snow (Chromebook ARM) and while mmc0 
(internal eMMC) is working fine, mmc1 (external SD slot) does not work.
I get the following error for 'mmc dev 1' command:
    mmc_init: -110, time 30


Please also note that on boot (or on 1st 'mmc dev 1' cmd if I stop auto-boot), 
I firstly get:
    mmc_init: -5, time 39

Then, all next attempts retruns:
    mmc_init: -110, time 30


Guillaume




Any idea what could be wrong?

Guillaume








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

[U-Boot] [PATCH v2 4/6] pico-imx6ul: Define partition layout in the environment

[Otavio Salvador]

From: Fabio Berton 

Create layout with a boot 16MiB partition and rootfs with remain
space.

Signed-off-by: Fabio Berton 
Signed-off-by: Otavio Salvador 
---

Changes in v2:
- fix typo (s/Mib/MiB/) - Fabio Estevam

 include/configs/pico-imx6ul.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/configs/pico-imx6ul.h b/include/configs/pico-imx6ul.h
index 6a19861da7..1ea79b9c18 100644
--- a/include/configs/pico-imx6ul.h
+++ b/include/configs/pico-imx6ul.h
@@ -68,6 +68,9 @@
"mmcautodetect=yes\0" \
CONFIG_DFU_ENV_SETTINGS \
"finduuid=part uuid mmc 0:2 uuid\0" \
+   "partitions=" \
+   "uuid_disk=${uuid_gpt_disk};" \
+   
"name=boot,size=16MiB;name=rootfs,size=0,uuid=${uuid_gpt_rootfs}\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=PARTUUID=${uuid} rootwait rw\0" \
"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
-- 
2.15.0

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

Re: [U-Boot] [OE-core] [PATCH] u-boot: Upgrade to 2017.11 release

[Otavio Salvador]

On Thu, Nov 16, 2017 at 6:12 AM, Marek Vasut  wrote:
> On 11/15/2017 05:47 PM, Stefan Agner wrote:
>> On 2017-11-14 19:32, Otavio Salvador wrote:
>>> This upgrades the U-Boot from 2017.09 to 2017.11 release.
>>
>> You might encounter this when building fw_printenv/setenv tools alone:
>>
>> https://lists.denx.de/pipermail/u-boot/2017-November/311505.html
>
> [...]
>
>>>  SRC_URI = "git://git.denx.de/u-boot.git \
>>>  file://MPC8315ERDB-enable-DHCP.patch \
> I also see that the number of out-of-tree patches didn't change since
> last time, even though I complained about it ... why are these patches
> still here ?

Because you are the maintainer and didn't do your duty. Stop
complaining and go help please.

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

[U-Boot] [PATCH v2 6/6] pico-imx6ul: Use FS_GENERIC load command

[Otavio Salvador]

From: Fabio Berton 

Signed-off-by: Fabio Berton 
Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 include/configs/pico-imx6ul.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/pico-imx6ul.h b/include/configs/pico-imx6ul.h
index 310fceb14b..f821b67c72 100644
--- a/include/configs/pico-imx6ul.h
+++ b/include/configs/pico-imx6ul.h
@@ -74,8 +74,8 @@
"setup_emmc=gpt write mmc 0 $partitions; reset;\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=PARTUUID=${uuid} rootwait rw\0" \
-   "loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
-   "loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
+   "loadimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
+   "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
"mmcboot=echo Booting from mmc ...; " \
"run finduuid; " \
"run mmcargs; " \
-- 
2.15.0

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

[U-Boot] [PATCH v2 5/6] pico-imx6ul: Add function to create gpt partitions

[Otavio Salvador]

From: Fabio Berton 

Command run setup_emmc will create gpt partitions for mmc 0 device
based on patitions variable.

Signed-off-by: Fabio Berton 
Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 configs/pico-imx6ul_defconfig | 1 +
 include/configs/pico-imx6ul.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/pico-imx6ul_defconfig b/configs/pico-imx6ul_defconfig
index e00f9f34a3..f28f9b7a4e 100644
--- a/configs/pico-imx6ul_defconfig
+++ b/configs/pico-imx6ul_defconfig
@@ -12,6 +12,7 @@ CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_PART=y
 CONFIG_CMD_USB=y
diff --git a/include/configs/pico-imx6ul.h b/include/configs/pico-imx6ul.h
index 1ea79b9c18..310fceb14b 100644
--- a/include/configs/pico-imx6ul.h
+++ b/include/configs/pico-imx6ul.h
@@ -71,6 +71,7 @@
"partitions=" \
"uuid_disk=${uuid_gpt_disk};" \

"name=boot,size=16MiB;name=rootfs,size=0,uuid=${uuid_gpt_rootfs}\0" \
+   "setup_emmc=gpt write mmc 0 $partitions; reset;\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=PARTUUID=${uuid} rootwait rw\0" \
"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
-- 
2.15.0

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

[U-Boot] [PATCH v2 2/6] pico-imx6ul: Use PARTUUID to specify the rootfs location

[Otavio Salvador]

From: Fabio Berton 

Currently the rootfs location is passed via mmcblk number and using
the UUID method to specify the rootfs location is a better approach
working even if mmcblk number for the eMMC changes depending on the
kernel versions.

Signed-off-by: Fabio Berton 
Signed-off-by: Otavio Salvador 
---

Changes in v2:
- fix typo (s/eMMM/eMMC/) - Fabio Estevam

 configs/pico-imx6ul_defconfig | 1 +
 include/configs/pico-imx6ul.h | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/configs/pico-imx6ul_defconfig b/configs/pico-imx6ul_defconfig
index 09b36ccb09..e00f9f34a3 100644
--- a/configs/pico-imx6ul_defconfig
+++ b/configs/pico-imx6ul_defconfig
@@ -13,6 +13,7 @@ CONFIG_CMD_DFU=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
+CONFIG_CMD_PART=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_DHCP=y
diff --git a/include/configs/pico-imx6ul.h b/include/configs/pico-imx6ul.h
index d4b29e3950..c775c32690 100644
--- a/include/configs/pico-imx6ul.h
+++ b/include/configs/pico-imx6ul.h
@@ -61,14 +61,15 @@
"fdt_addr=0x8300\0" \
"mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
"mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
-   "mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \
"mmcautodetect=yes\0" \
CONFIG_DFU_ENV_SETTINGS \
+   "finduuid=part uuid mmc 0:2 uuid\0" \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
-   "root=${mmcroot}\0" \
+   "root=PARTUUID=${uuid} rootwait rw\0" \
"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
"loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
"mmcboot=echo Booting from mmc ...; " \
+   "run finduuid; " \
"run mmcargs; " \
"if run loadfdt; then " \
"bootz ${loadaddr} - ${fdt_addr}; " \
@@ -147,6 +148,5 @@
 
 #define CONFIG_SYS_MMC_ENV_DEV 0
 #define CONFIG_SYS_MMC_ENV_PART0
-#define CONFIG_MMCROOT "/dev/mmcblk0p2"
 
 #endif /* __PICO_IMX6UL_CONFIG_H */
-- 
2.15.0

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

[U-Boot] [PATCH v2 3/6] pico-imx6ul: Add boot and rootfs dfu_alt_info

[Otavio Salvador]

From: Fabio Berton 

Change dfu_alt_info variable to use the following altsetting:

  uboot: To flash raw U-Boot
  /zImage: boot: To copy kernel image
  /imx6ul-pico-hobbit.dtb:   To copy dtb file
  rootfs:To copy rootfs

List the currently attached DFU capable USB devices running:
  sudo dfu-util -l

Flash U-Boot:
  sudo dfu-util -D u-boot.imx -a uboot

Copy boot files:
  sudo dfu-util -D zImage -a /zImage
  sudo dfu-util -D imx6ul-pico-hobbit.dtb -a /imx6ul-pico-hobbit.dtb

Flash rootfs:
  sudo dfu-util -D rootfs.ext4 -a rootfs

To copy boot files you need to have a formated mmc 0:1 partition. To
format with ext4 filesystem you can use ums.

Run on target:
  ums 0 mmc 0

and on host:
  sudo mkfs.ext4 /dev/sdx1

Signed-off-by: Fabio Berton 
Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 include/configs/pico-imx6ul.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/configs/pico-imx6ul.h b/include/configs/pico-imx6ul.h
index c775c32690..6a19861da7 100644
--- a/include/configs/pico-imx6ul.h
+++ b/include/configs/pico-imx6ul.h
@@ -48,7 +48,11 @@
 #define DFU_DEFAULT_POLL_TIMEOUT 300
 
 #define CONFIG_DFU_ENV_SETTINGS \
-   "dfu_alt_info=boot raw 0x2 0x400 mmcpart 1\0" \
+   "dfu_alt_info=uboot raw 0x2 0x400 mmcpart 1;" \
+   "boot part 0 1;" \
+   "/zImage ext4 0 1;" \
+   "/imx6ul-pico-hobbit.dtb ext4 0 1;" \
+   "rootfs part 0 2\0" \
 
 #define CONFIG_SYS_MMC_IMG_LOAD_PART   1
 
-- 
2.15.0

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

[U-Boot] [PATCH v2 1/6] pico-imx6ul: Move dfu_alt_info to CONFIG_DFU_ENV_SETTINGS variable

[Otavio Salvador]

From: Fabio Berton 

Create CONFIG_DFU_ENV_SETTINGS to set dfu environment settings to
improve human readable code.

Signed-off-by: Fabio Berton 
Signed-off-by: Otavio Salvador 
---

Changes in v2: None

 include/configs/pico-imx6ul.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/configs/pico-imx6ul.h b/include/configs/pico-imx6ul.h
index 75658fd489..d4b29e3950 100644
--- a/include/configs/pico-imx6ul.h
+++ b/include/configs/pico-imx6ul.h
@@ -47,6 +47,9 @@
 #define CONFIG_SYS_DFU_DATA_BUF_SIZE SZ_16M
 #define DFU_DEFAULT_POLL_TIMEOUT 300
 
+#define CONFIG_DFU_ENV_SETTINGS \
+   "dfu_alt_info=boot raw 0x2 0x400 mmcpart 1\0" \
+
 #define CONFIG_SYS_MMC_IMG_LOAD_PART   1
 
 #define CONFIG_EXTRA_ENV_SETTINGS \
@@ -60,7 +63,7 @@
"mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
"mmcroot=" CONFIG_MMCROOT " rootwait rw\0" \
"mmcautodetect=yes\0" \
-   "dfu_alt_info=boot raw 0x2 0x400 mmcpart 1\0" \
+   CONFIG_DFU_ENV_SETTINGS \
"mmcargs=setenv bootargs console=${console},${baudrate} " \
"root=${mmcroot}\0" \
"loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
-- 
2.15.0

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

Re: [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Alexander Graf]

On 11/16/2017 12:41 PM, Andre Przywara wrote:

Hi,

On 16/11/17 11:21, Maxime Ripard wrote:

On Thu, Nov 16, 2017 at 10:30:38AM +, Andre Przywara wrote:

Hi,

On 15/11/17 21:03, Alexander Graf wrote:


On 15.11.17 11:11, Maxime Ripard wrote:

The partitions variable is especially useful to create a partition table
from U-Boot, either directly from the U-Boot shell, or through flashing
tools like fastboot and its oem format command.

This is especially useful on devices with an eMMC you can't take out to
flash from another system, and booting a Linux system first to flash our
system then is not really practical.

Signed-off-by: Maxime Ripard 
---
  include/configs/sunxi-common.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 4391a8cbc824..11da6ccfbf54 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -493,6 +493,12 @@ extern int soft_i2c_gpio_scl;
  #define SUNXI_MTDPARTS_DEFAULT
  #endif
  
+#define PARTS_DEFAULT \

+   "name=loader1,start=8k,size=32k;" \
+   "name=loader2,size=984k;" \
+   "name=boot,size=128M,bootable;" \
+   "name=system,size=-;"

Is there a particular reason you're creating a boot and system
partition? In a normal distro world, the distro installer will take care
of creating ESP + root + swap + whatever for you - and they (or the user
driving the installation) usually know best what they need :)

But do we actually care about this?

I do.

I know, this was a misunderstanding, sorry. By "we" I meant Alex and
Karsten's generic distribution point of view. I was arguing that this
patch is of no big importance for them.

I think we agree that there are quite different use cases, and I don't
fight the usefulness of both.


If I understand this correctly, these are default settings for
U-Boot's "mtdparts default" command, which honestly I didn't even
know existed so far.

No, this has nothing to do with MTD. It's a default GPT partitioning
scheme. And only when you want to create the table from U-Boot, it
will not mangle with any pre-existing partition table if there is any
(unless you tell U-Boot to overwrite it, of course).

This is what I tried to say: It only affects you if you use U-Boot's
partitioning command, which you probably won't do if you are running an
off-the-shelf distribution installer. Is that understanding correct?


I'm not sure what the envisioned use of this is either. In general, it 
makes sense to keep the env on a partition and to mark the firmware 
residing on eMMC as off limits to an OS installer. So some sort of 
partitioning scheme is very useful and good to have.





So in a distribution scenario I wouldn't expect somebody to actually use
this. Instead you boot from a (possibly unpartitioned) SD card with just
U-Boot on it or from SPI flash, then launch an installer from somewhere
(PXE, USB drive) and let it do its job. No U-Boot partition involved.
And even if you use mtdpart, you can always override these default
settings on the command line.

Like I was telling Alexander, that makes a number of assumptions, the
two most obvious one being that you have an installer and that you
want to use it, both with reasonable reasons on why they wouldn't be
true.

More tailored fit distros like ELBE, yocto or Buildroot will not have
an installer in the first place but an image.

And even if you have an installer for the distro you want to use, if
you ever go to production, you will not use it since the time spent to
flash a pre-filled image compared to running the installer is
significantly lower. And time is money :)

Just like plugging / unplugging microSD card isn't really realistic in
that scenario.

I don't argue this (see above) and surely understand that generic
installers don't fly when it comes to bootstrapping devices.

But my understanding is that both Alex and Karsten don't really care
about this usage scenario, but instead are more looking into generic
distribution installers, which use U-Boot merely to launch grub.

Actually I wanted to help you out here by pointing out that their
concerns don't really apply to this patch ;-)


Does mtdparts even use partition tables (MBR/GPT)? mtd sounds quite
Android-y/embedded to me (passing partition information via command line).

So apart from that I think it's good to have a default FAT/ESP
partition, also for storing the environment.

What is the typical size of the files you usually put in there? My
actual question being is 128MB enough, way too big or too small? The
environment is just 128kB big at the moment, so it looks way to
big for me, but I have no idea what is usually stored in an ESP
partition.

128MB is actually quite fine. I tend to use 150MB or 100MB. The Ubuntu
arm64 kernel is around 20MB, and you may want to store more than one of
those on the ESP, along with an initrd. I understand that distributions
may not use the ESP for 

Re: [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Andre Przywara]

Hi,

On 16/11/17 11:21, Maxime Ripard wrote:
> On Thu, Nov 16, 2017 at 10:30:38AM +, Andre Przywara wrote:
>> Hi,
>>
>> On 15/11/17 21:03, Alexander Graf wrote:
>>>
>>>
>>> On 15.11.17 11:11, Maxime Ripard wrote:
 The partitions variable is especially useful to create a partition table
 from U-Boot, either directly from the U-Boot shell, or through flashing
 tools like fastboot and its oem format command.

 This is especially useful on devices with an eMMC you can't take out to
 flash from another system, and booting a Linux system first to flash our
 system then is not really practical.

 Signed-off-by: Maxime Ripard 
 ---
  include/configs/sunxi-common.h | 7 +++
  1 file changed, 7 insertions(+)

 diff --git a/include/configs/sunxi-common.h 
 b/include/configs/sunxi-common.h
 index 4391a8cbc824..11da6ccfbf54 100644
 --- a/include/configs/sunxi-common.h
 +++ b/include/configs/sunxi-common.h
 @@ -493,6 +493,12 @@ extern int soft_i2c_gpio_scl;
  #define SUNXI_MTDPARTS_DEFAULT
  #endif
  
 +#define PARTS_DEFAULT \
 +  "name=loader1,start=8k,size=32k;" \
 +  "name=loader2,size=984k;" \
 +  "name=boot,size=128M,bootable;" \
 +  "name=system,size=-;"
>>>
>>> Is there a particular reason you're creating a boot and system
>>> partition? In a normal distro world, the distro installer will take care
>>> of creating ESP + root + swap + whatever for you - and they (or the user
>>> driving the installation) usually know best what they need :)
>>
>> But do we actually care about this?
> 
> I do.

I know, this was a misunderstanding, sorry. By "we" I meant Alex and
Karsten's generic distribution point of view. I was arguing that this
patch is of no big importance for them.

I think we agree that there are quite different use cases, and I don't
fight the usefulness of both.

>> If I understand this correctly, these are default settings for
>> U-Boot's "mtdparts default" command, which honestly I didn't even
>> know existed so far.
> 
> No, this has nothing to do with MTD. It's a default GPT partitioning
> scheme. And only when you want to create the table from U-Boot, it
> will not mangle with any pre-existing partition table if there is any
> (unless you tell U-Boot to overwrite it, of course).

This is what I tried to say: It only affects you if you use U-Boot's
partitioning command, which you probably won't do if you are running an
off-the-shelf distribution installer. Is that understanding correct?

>> So in a distribution scenario I wouldn't expect somebody to actually use
>> this. Instead you boot from a (possibly unpartitioned) SD card with just
>> U-Boot on it or from SPI flash, then launch an installer from somewhere
>> (PXE, USB drive) and let it do its job. No U-Boot partition involved.
>> And even if you use mtdpart, you can always override these default
>> settings on the command line.
> 
> Like I was telling Alexander, that makes a number of assumptions, the
> two most obvious one being that you have an installer and that you
> want to use it, both with reasonable reasons on why they wouldn't be
> true.
> 
> More tailored fit distros like ELBE, yocto or Buildroot will not have
> an installer in the first place but an image.
> 
> And even if you have an installer for the distro you want to use, if
> you ever go to production, you will not use it since the time spent to
> flash a pre-filled image compared to running the installer is
> significantly lower. And time is money :)
> 
> Just like plugging / unplugging microSD card isn't really realistic in
> that scenario.

I don't argue this (see above) and surely understand that generic
installers don't fly when it comes to bootstrapping devices.

But my understanding is that both Alex and Karsten don't really care
about this usage scenario, but instead are more looking into generic
distribution installers, which use U-Boot merely to launch grub.

Actually I wanted to help you out here by pointing out that their
concerns don't really apply to this patch ;-)

>> Does mtdparts even use partition tables (MBR/GPT)? mtd sounds quite
>> Android-y/embedded to me (passing partition information via command line).
>>
>> So apart from that I think it's good to have a default FAT/ESP
>> partition, also for storing the environment.
> 
> What is the typical size of the files you usually put in there? My
> actual question being is 128MB enough, way too big or too small? The
> environment is just 128kB big at the moment, so it looks way to
> big for me, but I have no idea what is usually stored in an ESP
> partition.

128MB is actually quite fine. I tend to use 150MB or 100MB. The Ubuntu
arm64 kernel is around 20MB, and you may want to store more than one of
those on the ESP, along with an initrd. I understand that distributions
may not use the ESP for that, but their own /boot partition. But this is
their choice. Also other 

Re: [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Maxime Ripard]

On Thu, Nov 16, 2017 at 10:30:38AM +, Andre Przywara wrote:
> Hi,
> 
> On 15/11/17 21:03, Alexander Graf wrote:
> > 
> > 
> > On 15.11.17 11:11, Maxime Ripard wrote:
> >> The partitions variable is especially useful to create a partition table
> >> from U-Boot, either directly from the U-Boot shell, or through flashing
> >> tools like fastboot and its oem format command.
> >>
> >> This is especially useful on devices with an eMMC you can't take out to
> >> flash from another system, and booting a Linux system first to flash our
> >> system then is not really practical.
> >>
> >> Signed-off-by: Maxime Ripard 
> >> ---
> >>  include/configs/sunxi-common.h | 7 +++
> >>  1 file changed, 7 insertions(+)
> >>
> >> diff --git a/include/configs/sunxi-common.h 
> >> b/include/configs/sunxi-common.h
> >> index 4391a8cbc824..11da6ccfbf54 100644
> >> --- a/include/configs/sunxi-common.h
> >> +++ b/include/configs/sunxi-common.h
> >> @@ -493,6 +493,12 @@ extern int soft_i2c_gpio_scl;
> >>  #define SUNXI_MTDPARTS_DEFAULT
> >>  #endif
> >>  
> >> +#define PARTS_DEFAULT \
> >> +  "name=loader1,start=8k,size=32k;" \
> >> +  "name=loader2,size=984k;" \
> >> +  "name=boot,size=128M,bootable;" \
> >> +  "name=system,size=-;"
> > 
> > Is there a particular reason you're creating a boot and system
> > partition? In a normal distro world, the distro installer will take care
> > of creating ESP + root + swap + whatever for you - and they (or the user
> > driving the installation) usually know best what they need :)
> 
> But do we actually care about this?

I do.

> If I understand this correctly, these are default settings for
> U-Boot's "mtdparts default" command, which honestly I didn't even
> know existed so far.

No, this has nothing to do with MTD. It's a default GPT partitioning
scheme. And only when you want to create the table from U-Boot, it
will not mangle with any pre-existing partition table if there is any
(unless you tell U-Boot to overwrite it, of course).

> So in a distribution scenario I wouldn't expect somebody to actually use
> this. Instead you boot from a (possibly unpartitioned) SD card with just
> U-Boot on it or from SPI flash, then launch an installer from somewhere
> (PXE, USB drive) and let it do its job. No U-Boot partition involved.
> And even if you use mtdpart, you can always override these default
> settings on the command line.

Like I was telling Alexander, that makes a number of assumptions, the
two most obvious one being that you have an installer and that you
want to use it, both with reasonable reasons on why they wouldn't be
true.

More tailored fit distros like ELBE, yocto or Buildroot will not have
an installer in the first place but an image.

And even if you have an installer for the distro you want to use, if
you ever go to production, you will not use it since the time spent to
flash a pre-filled image compared to running the installer is
significantly lower. And time is money :)

Just like plugging / unplugging microSD card isn't really realistic in
that scenario.

> Does mtdparts even use partition tables (MBR/GPT)? mtd sounds quite
> Android-y/embedded to me (passing partition information via command line).
> 
> So apart from that I think it's good to have a default FAT/ESP
> partition, also for storing the environment.

What is the typical size of the files you usually put in there? My
actual question being is 128MB enough, way too big or too small? The
environment is just 128kB big at the moment, so it looks way to
big for me, but I have no idea what is usually stored in an ESP
partition.

> It's debatable whether we need a system partition defined at this stage.
> Can't this just left be unpartitioned, to be actually populated later?

This would break the cases I talked about earlier.

> In a MBR/GPT scenario I would expect a big partition covering the whole
> device causes headache later on.

What kind of headaches?

Thanks!
Maxime

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


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

Re: [U-Boot] [PATCH 1/2] common: make bouncebuf work for non-DMA transfers

[Vignesh R]

On Thursday 16 November 2017 04:21 PM, Goldschmidt Simon wrote:
> Hi Vignesh,
> 
> Vignesh R wrote:
>> [..]
>> Its not actually unaligned access, cadence QSPI IP on TI platforms do
>> not support non-byte accesses except for the last word. As per the TRM:
>> "The external master is only permitted to issue 32-bit data interface
>> writes until the last word of an indirect
>> transfer"
> 
> OK, I thought it was unaligned access because of reading your commit
> message talking about data aborts. But this was in the write part
> indeed.
> 
>>> So given my explanation above, what's the preferred way to fix this?
>>
>> Sorry, I overlooked the fact that bounce_buffer_stop() is calling
>> invalidate_dcache_range(). Somehow, this did not show problems on my
>> platform although its a writeback cache.
>>
>> I would suggest to revert commit b63b46313 ("spi: cadence_qspi_apb: Use
>> 32 bit indirect read transaction when possible"). I have seen that non
>> 32 bit accesses cause problems only while writing to flash but not
>> during read operations although the TRM states that both reads and
>> writes are affected.
>> But, since reverting b63b46313 as such does not break TI platforms, I
>> would prefer sending a revert.
>> Meanwhile, I will work on a better patch later.
> 
> I have not actually tested writing with dcache enabled, but from
> reading the code, it should not be a problem. I'll test that then.
> 
>> Lets not touch bouncebuf for now.
> 
> OK. I take it that bouncebuf should be only used for dma transfers.

Not bouncebuf in general. But, bouncebuf.c seems to written for DMA
transfers.

> In that case, shouldn't we revert the write patch, too, eventually?
> Even if it does not break data consistency like in the read direction,
> messing around with the cache while doing cpu transfers at the very
> least will drop performance. Plus it seems like a bad example.
> 

Yes, I will work on that.


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

Re: [U-Boot] [PATCH 1/2] common: make bouncebuf work for non-DMA transfers

[Goldschmidt Simon]

Hi Vignesh,

Vignesh R wrote:
> [..]
> Its not actually unaligned access, cadence QSPI IP on TI platforms do
> not support non-byte accesses except for the last word. As per the TRM:
> "The external master is only permitted to issue 32-bit data interface
> writes until the last word of an indirect
> transfer"

OK, I thought it was unaligned access because of reading your commit
message talking about data aborts. But this was in the write part
indeed.

>> So given my explanation above, what's the preferred way to fix this?
> 
> Sorry, I overlooked the fact that bounce_buffer_stop() is calling
> invalidate_dcache_range(). Somehow, this did not show problems on my
> platform although its a writeback cache.
>
> I would suggest to revert commit b63b46313 ("spi: cadence_qspi_apb: Use
> 32 bit indirect read transaction when possible"). I have seen that non
> 32 bit accesses cause problems only while writing to flash but not
> during read operations although the TRM states that both reads and
> writes are affected.
> But, since reverting b63b46313 as such does not break TI platforms, I
> would prefer sending a revert.
> Meanwhile, I will work on a better patch later.

I have not actually tested writing with dcache enabled, but from
reading the code, it should not be a problem. I'll test that then.

> Lets not touch bouncebuf for now.

OK. I take it that bouncebuf should be only used for dma transfers.
In that case, shouldn't we revert the write patch, too, eventually?
Even if it does not break data consistency like in the read direction,
messing around with the cache while doing cpu transfers at the very
least will drop performance. Plus it seems like a bad example.

We can do that later, of course, as it should work like it is now.

>> I need this driver fixed, so whatever way will be accepted is fine by
>> me, I guess. Just let me know.
>> 
>
> Sorry for the trouble. I am okay with reverting the patch affecting read
> path.

OK. I'll send a patch hat reverts the read path then.

Thank you for your help!

Regards,
Simon

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

Re: [U-Boot] [PATCH 1/2] common: make bouncebuf work for non-DMA transfers

[Vignesh R]

Hi Simon,

On Thursday 16 November 2017 03:39 PM, Goldschmidt Simon wrote:
[...]
> 
> This 32-bit spi transfer mode does not seem to be used too often, all
> other drivers I looked at are transferring byte by byte and thus can
> not be used as an example.
> 
> Additionally, the TI platform Vignesh used obviously does not support
> unaligned access (which is why he added using bouncebuf here although
> no dma is used) while mach-socfpga supports unaligned accesses by
> default.
> 

Its not actually unaligned access, cadence QSPI IP on TI platforms do
not support non-byte accesses except for the last word. As per the TRM:
"The external master is only permitted to issue 32-bit data interface
writes until the last word of an indirect
transfer"

> So given my explanation above, what's the preferred way to fix this?

Sorry, I overlooked the fact that bounce_buffer_stop() is calling
invalidate_dcache_range(). Somehow, this did not show problems on my
platform although its a writeback cache.

I would suggest to revert commit b63b46313 ("spi: cadence_qspi_apb: Use
32 bit indirect read transaction when possible"). I have seen that non
32 bit accesses cause problems only while writing to flash but not
during read operations although the TRM states that both reads and
writes are affected.
But, since reverting b63b46313 as such does not break TI platforms, I
would prefer sending a revert.
Meanwhile, I will work on a better patch later.

> 
> I thought a framework solution would be better, which is why I modified
> bouncebuf to work with this, but as cadence_qspi is the only driver
> using bouncebuf in this fashion for now, I'm open for suggestions.
>

Lets not touch bouncebuf for now.


> I need this driver fixed, so whatever way will be accepted is fine by
> me, I guess. Just let me know.
> 

Sorry for the trouble. I am okay with reverting the patch affecting read
path.

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

Re: [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Andre Przywara]

Hi,

On 15/11/17 21:03, Alexander Graf wrote:
> 
> 
> On 15.11.17 11:11, Maxime Ripard wrote:
>> The partitions variable is especially useful to create a partition table
>> from U-Boot, either directly from the U-Boot shell, or through flashing
>> tools like fastboot and its oem format command.
>>
>> This is especially useful on devices with an eMMC you can't take out to
>> flash from another system, and booting a Linux system first to flash our
>> system then is not really practical.
>>
>> Signed-off-by: Maxime Ripard 
>> ---
>>  include/configs/sunxi-common.h | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
>> index 4391a8cbc824..11da6ccfbf54 100644
>> --- a/include/configs/sunxi-common.h
>> +++ b/include/configs/sunxi-common.h
>> @@ -493,6 +493,12 @@ extern int soft_i2c_gpio_scl;
>>  #define SUNXI_MTDPARTS_DEFAULT
>>  #endif
>>  
>> +#define PARTS_DEFAULT \
>> +"name=loader1,start=8k,size=32k;" \
>> +"name=loader2,size=984k;" \
>> +"name=boot,size=128M,bootable;" \
>> +"name=system,size=-;"
> 
> Is there a particular reason you're creating a boot and system
> partition? In a normal distro world, the distro installer will take care
> of creating ESP + root + swap + whatever for you - and they (or the user
> driving the installation) usually know best what they need :)

But do we actually care about this? If I understand this correctly,
these are default settings for U-Boot's "mtdparts default" command,
which honestly I didn't even know existed so far.
So in a distribution scenario I wouldn't expect somebody to actually use
this. Instead you boot from a (possibly unpartitioned) SD card with just
U-Boot on it or from SPI flash, then launch an installer from somewhere
(PXE, USB drive) and let it do its job. No U-Boot partition involved.
And even if you use mtdpart, you can always override these default
settings on the command line.

Does mtdparts even use partition tables (MBR/GPT)? mtd sounds quite
Android-y/embedded to me (passing partition information via command line).

So apart from that I think it's good to have a default FAT/ESP
partition, also for storing the environment.

It's debatable whether we need a system partition defined at this stage.
Can't this just left be unpartitioned, to be actually populated later?
In a MBR/GPT scenario I would expect a big partition covering the whole
device causes headache later on.

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

[U-Boot] [PATCH] x86: lib: Implement standalone __udivdi3 etc instead of libgcc ones

[Stefan Roese]

This patch removes the inclusion of the libgcc math functions and
replaces them by functions coded in C, taken from the coreboot
project. This makes U-Boot building more independent from the toolchain
installed / available on the build system.

The code taken from coreboot is authored from Vadim Bendebury
 on 2014-11-28 and committed with commit
ID e63990ef [libpayload: provide basic 64bit division implementation].

I modified the code so that its checkpatch clean without any
functional changes.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
Cc: Bin Meng 
---
 arch/x86/config.mk|   3 --
 arch/x86/lib/Makefile |   2 +-
 arch/x86/lib/div64.c  | 113 ++
 arch/x86/lib/gcc.c|  29 -
 4 files changed, 114 insertions(+), 33 deletions(-)
 create mode 100644 arch/x86/lib/div64.c
 delete mode 100644 arch/x86/lib/gcc.c

diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 8835dcf36f..472ada5490 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -34,9 +34,6 @@ PLATFORM_RELFLAGS += -ffunction-sections -fvisibility=hidden
 PLATFORM_LDFLAGS += -Bsymbolic -Bsymbolic-functions
 PLATFORM_LDFLAGS += -m $(if $(IS_32BIT),elf_i386,elf_x86_64)
 
-LDFLAGS_FINAL += --wrap=__divdi3 --wrap=__udivdi3
-LDFLAGS_FINAL += --wrap=__moddi3 --wrap=__umoddi3
-
 # This is used in the top-level Makefile which does not include
 # PLATFORM_LDFLAGS
 LDFLAGS_EFI_PAYLOAD := -Bsymbolic -Bsymbolic-functions -shared --no-undefined
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index fe00d7573f..d9b23f5cc4 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -18,7 +18,7 @@ obj-$(CONFIG_SEABIOS) += coreboot_table.o
 obj-y  += early_cmos.o
 obj-$(CONFIG_EFI) += efi/
 obj-y  += e820.o
-obj-y  += gcc.o
+obj-y  += div64.o
 obj-y  += init_helpers.o
 obj-y  += interrupts.o
 obj-y  += lpc-uclass.o
diff --git a/arch/x86/lib/div64.c b/arch/x86/lib/div64.c
new file mode 100644
index 00..4efed74037
--- /dev/null
+++ b/arch/x86/lib/div64.c
@@ -0,0 +1,113 @@
+/*
+ * This file is copied from the coreboot repository as part of
+ * the libpayload project:
+ *
+ * Copyright 2014 Google Inc.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include 
+
+union overlay64 {
+   u64 longw;
+   struct {
+   u32 lower;
+   u32 higher;
+   } words;
+};
+
+u64 __ashldi3(u64 num, unsigned int shift)
+{
+   union overlay64 output;
+
+   output.longw = num;
+   if (shift >= 32) {
+   output.words.higher = output.words.lower << (shift - 32);
+   output.words.lower = 0;
+   } else {
+   if (!shift)
+   return num;
+   output.words.higher = (output.words.higher << shift) |
+   (output.words.lower >> (32 - shift));
+   output.words.lower = output.words.lower << shift;
+   }
+   return output.longw;
+}
+
+u64 __lshrdi3(u64 num, unsigned int shift)
+{
+   union overlay64 output;
+
+   output.longw = num;
+   if (shift >= 32) {
+   output.words.lower = output.words.higher >> (shift - 32);
+   output.words.higher = 0;
+   } else {
+   if (!shift)
+   return num;
+   output.words.lower = output.words.lower >> shift |
+   (output.words.higher << (32 - shift));
+   output.words.higher = output.words.higher >> shift;
+   }
+   return output.longw;
+}
+
+#define MAX_32BIT_UINT u64)1) << 32) - 1)
+
+static u64 _64bit_divide(u64 dividend, u64 divider, u64 *rem_p)
+{
+   u64 result = 0;
+
+   /*
+* If divider is zero - let the rest of the system care about the
+* exception.
+*/
+   if (!divider)
+   return 1 / (u32)divider;
+
+   /* As an optimization, let's not use 64 bit division unless we must. */
+   if (dividend <= MAX_32BIT_UINT) {
+   if (divider > MAX_32BIT_UINT) {
+   result = 0;
+   if (rem_p)
+   *rem_p = divider;
+   } else {
+   result = (u32)dividend / (u32)divider;
+   if (rem_p)
+   *rem_p = (u32)dividend % (u32)divider;
+   }
+   return result;
+   }
+
+   while (divider <= dividend) {
+   u64 locald = divider;
+   u64 limit = __lshrdi3(dividend, 1);
+   int shifts = 0;
+
+   while (locald <= limit) {
+   shifts++;
+   locald = locald + locald;
+   }
+   result |= __ashldi3(1, shifts);
+   dividend -= locald;
+   }
+
+   if (rem_p)
+   *rem_p = dividend;
+
+   return result;
+}
+
+u64 __udivdi3(u64 num, u64 den)
+{

Re: [U-Boot] [PATCH 1/2] common: make bouncebuf work for non-DMA transfers

[Goldschmidt Simon]

Simon Goldschmidt wrote:
>Marek Vasut wrote:
>> So what alignment problems do you observe ? If you copy using the CPU
>> only, why do you need the bounce buffer at all ? I don't quite get it.
> 
> Sorry for not explaining it good enough:
> I don't observe any alignment problems. mach-socfpga can do unaligned
> accesses as well. This driver does CPU based copy, but since it transfers
> words, not bytes, I guess on other platforms, the CPU might fail when trying
> to read a word from an unaligned pointer.
>
> Vignesh added this about a year ago and from that commit message, it
> seems like he was observing alignment errors on his TI platform.
> Also, those commits have a reviewed-by tag from you and Jagan.
>
> For me, reverting these patches would be OK as well, but I guess Vinesh's
> TI platform kind of needs them?

So to clarify it again, the cadence_spi driver has to transfer 32-bit
words to/from the hardware and the driver uses 'readsl' and 'writesl'
to do this. Now if the source/destination buffer is not aligned, this
results in an error on platforms that do not support unaligned access.

We have three options here:
a) fix all call stacks calling dm_spi_ops->xfer to use aligned buffers
   (which could be hard when looking at 'sf read')
b) fix the driver by doing malloc + memcpy or loading byte by byte from
   ram
c) add framework functions doing malloc + memcpy (which is nearly the
   same as bouncebuf)

This 32-bit spi transfer mode does not seem to be used too often, all
other drivers I looked at are transferring byte by byte and thus can
not be used as an example.

Additionally, the TI platform Vignesh used obviously does not support
unaligned access (which is why he added using bouncebuf here although
no dma is used) while mach-socfpga supports unaligned accesses by
default.

So given my explanation above, what's the preferred way to fix this?

I thought a framework solution would be better, which is why I modified
bouncebuf to work with this, but as cadence_qspi is the only driver
using bouncebuf in this fashion for now, I'm open for suggestions.

I need this driver fixed, so whatever way will be accepted is fine by
me, I guess. Just let me know.

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

Re: [U-Boot] [PATCH 0/4] sunxi: Ease eMMC usage and flashing

[Maxime Ripard]

Hi Karsten,

On Wed, Nov 15, 2017 at 09:41:34PM +0100, Karsten Merker wrote:
> > We then provide a default partitionning scheme. I'd like feedback on
> > that one. I appreciate that having a good default in such a case, but
> > I'd like to have a reasonably simple layout that works good enough to
> > install a distro. I'm a bit short on background on what an EFI
> > partition is supposed to look like, and what a good size would be. I'd
> > really like some input on this.
> 
> the partitioning scheme from patch no. 3 of this series looks like
> follows:
> 
> #define PARTS_DEFAULT \
>"name=loader1,start=8k,size=32k;" \
>"name=loader2,size=984k;" \
>"name=boot,size=128M,bootable;" \
>"name=system,size=-;"
> 
> I assume that the intended use is
> - loader1: SPL
> - loader2: u-boot
> - boot: Linux /boot
> - system: Linux /
> 
> AFAIK the UEFI spec requires that the EFI system partition (ESP)
> is FAT-formatted.  Most (probably all?) Linux package management
> tooling assumes that files from packages are installed onto
> filesystems that support POSIX semantics, including hardlinks,
> which FAT does not.  This means that distributions cannot re-use
> an EFI system partition as /boot and therefore need a partition
> for /boot and an additional ESP (AFAIK commonly mounted to
> /boot/efi).  I would therefore like to propose adding a small
> separate partition for use as ESP.

The original intent of the "boot" partition wasn't really to store
/boot, but to be a FAT partition to store the environment + whatever
data needed for the EFI partition.

Maybe we can rename it if it's confusing?

Maxime

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


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

Re: [U-Boot] [PATCH 3/4] sunxi: Add default partition scheme

[Maxime Ripard]

Hi Alexander,

On Wed, Nov 15, 2017 at 10:03:32PM +0100, Alexander Graf wrote:
> On 15.11.17 11:11, Maxime Ripard wrote:
> > The partitions variable is especially useful to create a partition table
> > from U-Boot, either directly from the U-Boot shell, or through flashing
> > tools like fastboot and its oem format command.
> > 
> > This is especially useful on devices with an eMMC you can't take out to
> > flash from another system, and booting a Linux system first to flash our
> > system then is not really practical.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  include/configs/sunxi-common.h | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> > index 4391a8cbc824..11da6ccfbf54 100644
> > --- a/include/configs/sunxi-common.h
> > +++ b/include/configs/sunxi-common.h
> > @@ -493,6 +493,12 @@ extern int soft_i2c_gpio_scl;
> >  #define SUNXI_MTDPARTS_DEFAULT
> >  #endif
> >  
> > +#define PARTS_DEFAULT \
> > +   "name=loader1,start=8k,size=32k;" \
> > +   "name=loader2,size=984k;" \
> > +   "name=boot,size=128M,bootable;" \
> > +   "name=system,size=-;"
> 
> Is there a particular reason you're creating a boot and system
> partition? In a normal distro world, the distro installer will take care
> of creating ESP + root + swap + whatever for you - and they (or the user
> driving the installation) usually know best what they need :)

Right, so let me explain my thought process here :)

We really want a main partition for the system for people that will
not use any distro installer (either because they generated their
image by hand before using something like debootstrap or ELBE) or
because they're using a build system that will generate the system
image directly, without any alternative process.

Then, the boot partition is the one I'm not really sure about. As you
know, we will transition to an FAT-based environment in the future, so
we need to have partition to hold it on all systems, and it can't be
the system one since, well, FAT.

I also was under the impression that it would benefit you in some way
to store the EFI data, and it's actually what I'd really like input
on. I have basically no idea what are your requirements or what would
be a good size.

The only real constraints we have is that it needs to be at least able
to store 128kB for the environment. If we want to align it properly,
that would be 1MB. Then, if you're telling me you don't need anything
else, then that's fine by me :)

Maxime

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


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

[U-Boot] [RFC PATCH 09/10] sunxi: Transition from the MMC to a FAT-based environment

[Maxime Ripard]

The current environment has been hardcoded to an offset that starts to be
an issue given the current size of our main U-Boot binary.

By implementing a custom environment location routine, we can always favor
the FAT-based environment, and fallback to the MMC if we don't find
something in the FAT partition. We also implement the same order when
saving the environment, so that hopefully we can slowly migrate the users
over to FAT-based environment and away from the raw MMC one.

Eventually, and hopefully before we reach that limit again, we will have
most of our users using that setup, and we'll be able to retire the raw
environment, and gain more room for the U-Boot binary.

Signed-off-by: Maxime Ripard 
---
 board/sunxi/board.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index dcacdf3e626d..8891961dcc6b 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -173,6 +173,22 @@ void i2c_init_board(void)
 #endif
 }
 
+#if defined(CONFIG_ENV_IS_IN_MMC) && defined(CONFIG_ENV_IS_IN_FAT)
+enum env_location env_get_location(enum env_operation op, int prio)
+{
+   switch (prio) {
+   case 0:
+   return ENVL_FAT;
+
+   case 1:
+   return ENVL_MMC;
+
+   default:
+   return ENVL_UNKNOWN;
+   }
+}
+#endif
+
 /* add board specific code here */
 int board_init(void)
 {
-- 
2.14.3

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

[U-Boot] [RFC PATCH 06/10] env: Support multiple environments

[Maxime Ripard]

Now that we have everything in place to support multiple environment, let's
make sure the current code can use it.

The priority used between the various environment is the same one that was
used in the code previously.

At read / init times, the highest priority environment is going to be
detected, and we'll use the same one without lookup during writes. This
should implement the same behaviour than we currently have.

Signed-off-by: Maxime Ripard 
---
 env/env.c | 75 ++-
 1 file changed, 50 insertions(+), 25 deletions(-)

diff --git a/env/env.c b/env/env.c
index 1d13220aa79b..6af9f897b0ae 100644
--- a/env/env.c
+++ b/env/env.c
@@ -26,33 +26,58 @@ static struct env_driver *_env_driver_lookup(enum 
env_location loc)
return NULL;
 }
 
+static enum env_location env_locations[] = {
+#ifdef CONFIG_ENV_IS_IN_EEPROM
+   ENVL_EEPROM,
+#endif
+#ifdef CONFIG_ENV_IS_IN_FAT
+   ENVL_FAT,
+#endif
+#ifdef CONFIG_ENV_IS_IN_FLASH
+   ENVL_FLASH,
+#endif
+#ifdef CONFIG_ENV_IS_IN_MMC
+   ENVL_MMC,
+#endif
+#ifdef CONFIG_ENV_IS_IN_NAND
+   ENVL_NAND,
+#endif
+#ifdef CONFIG_ENV_IS_IN_NVRAM
+   ENVL_NVRAM,
+#endif
+#ifdef CONFIG_ENV_IS_IN_REMOTE
+   ENVL_REMOTE,
+#endif
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+   ENVL_SPI_FLASH,
+#endif
+#ifdef CONFIG_ENV_IS_IN_UBI
+   ENVL_UBI,
+#endif
+#ifdef CONFIG_ENV_IS_NOWHERE
+   ENVL_NOWHERE,
+#endif
+   ENVL_UNKNOWN,
+};
+
+static enum env_location env_load_location;
+
 static enum env_location env_get_location(enum env_operation op, int prio)
 {
-   if (prio >= 1)
-   return ENVL_UNKNOWN;
-
-   if IS_ENABLED(CONFIG_ENV_IS_IN_EEPROM)
-   return ENVL_EEPROM;
-   else if IS_ENABLED(CONFIG_ENV_IS_IN_FAT)
-   return ENVL_FAT;
-   else if IS_ENABLED(CONFIG_ENV_IS_IN_FLASH)
-   return ENVL_FLASH;
-   else if IS_ENABLED(CONFIG_ENV_IS_IN_MMC)
-   return ENVL_MMC;
-   else if IS_ENABLED(CONFIG_ENV_IS_IN_NAND)
-   return ENVL_NAND;
-   else if IS_ENABLED(CONFIG_ENV_IS_IN_NVRAM)
-   return ENVL_NVRAM;
-   else if IS_ENABLED(CONFIG_ENV_IS_IN_REMOTE)
-   return ENVL_REMOTE;
-   else if IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH)
-   return ENVL_SPI_FLASH;
-   else if IS_ENABLED(CONFIG_ENV_IS_IN_UBI)
-   return ENVL_UBI;
-   else if IS_ENABLED(CONFIG_ENV_IS_NOWHERE)
-   return ENVL_NOWHERE;
-   else
-   return ENVL_UNKNOWN;
+   switch (op) {
+   case ENVO_GET_CHAR:
+   case ENVO_INIT:
+   case ENVO_LOAD:
+   if (prio >= ARRAY_SIZE(env_locations))
+   return -ENODEV;
+
+   return env_load_location = env_locations[prio];
+
+   case ENVO_SAVE:
+   return env_load_location;
+   }
+
+   return ENVL_UNKNOWN;
 }
 
 static struct env_driver *env_driver_lookup(enum env_operation op, int prio)
-- 
2.14.3

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

[U-Boot] [RFC PATCH 07/10] env: Allow to build multiple environments in Kconfig

[Maxime Ripard]

Now that we have everything in place in the code, let's allow to build
multiple environments backend through Kconfig.

Signed-off-by: Maxime Ripard 
---
 env/Kconfig | 65 ++---
 1 file changed, 32 insertions(+), 33 deletions(-)

diff --git a/env/Kconfig b/env/Kconfig
index 8c9d800f485f..bf6eab6b4ace 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -1,38 +1,18 @@
 menu "Environment"
 
-choice
-   prompt "Select the location of the environment"
-   default ENV_IS_IN_MMC if ARCH_SUNXI
-   default ENV_IS_IN_MMC if ARCH_EXYNOS4
-   default ENV_IS_IN_MMC if MX6SX || MX7D
-   default ENV_IS_IN_MMC if TEGRA30 || TEGRA124
-   default ENV_IS_IN_MMC if TEGRA_ARMV8_COMMON
-   default ENV_IS_IN_FLASH if ARCH_CINTEGRATOR
-   default ENV_IS_IN_FLASH if ARCH_INTEGRATOR_CP
-   default ENV_IS_IN_FLASH if M548x || M547x || M5282 || MCF547x_8x
-   default ENV_IS_IN_FLASH if MCF532x || MCF52x2
-   default ENV_IS_IN_FLASH if MPC86xx || MPC83xx
-   default ENV_IS_IN_FLASH if ARCH_MPC8572 || ARCH_MPC8548 || ARCH_MPC8641
-   default ENV_IS_IN_FLASH if SH && !CPU_SH4
-   default ENV_IS_IN_SPI_FLASH if ARMADA_XP
-   default ENV_IS_IN_SPI_FLASH if INTEL_BAYTRAIL
-   default ENV_IS_IN_SPI_FLASH if INTEL_BRASWELL
-   default ENV_IS_IN_SPI_FLASH if INTEL_BROADWELL
-   default ENV_IS_IN_SPI_FLASH if NORTHBRIDGE_INTEL_IVYBRIDGE
-   default ENV_IS_IN_SPI_FLASH if INTEL_QUARK
-   default ENV_IS_IN_SPI_FLASH if INTEL_QUEENSBAY
-   default ENV_IS_IN_FAT if ARCH_BCM283X
-   default ENV_IS_IN_FAT if MMC_OMAP_HS && TI_COMMON_CMD_OPTIONS
-   default ENV_IS_NOWHERE
-   help
- At present the environment can be stored in only one place. Use this
- option to select the location. This is either a device (where the
- environemnt information is simply written to a fixed location or
- partition on the device) or a filesystem (where the environment
- information is written to a file).
-
 config ENV_IS_NOWHERE
bool "Environment is not stored"
+   depends on !ENV_IS_IN_EEPROM
+   depends on !ENV_IS_IN_FAT
+   depends on !ENV_IS_IN_FLASH
+   depends on !ENV_IS_IN_MMC
+   depends on !ENV_IS_IN_NAND
+   depends on !ENV_IS_IN_NVRAM
+   depends on !ENV_IS_IN_ONENAND
+   depends on !ENV_IS_IN_REMOTE
+   depends on !ENV_IS_IN_SPI_FLASH
+   depends on !ENV_IS_IN_UBI
+   default y
help
  Define this if you don't want to or can't have an environment stored
  on a storage medium. In this case the environemnt will still exist
@@ -74,6 +54,8 @@ config ENV_IS_IN_EEPROM
 config ENV_IS_IN_FAT
bool "Environment is in a FAT filesystem"
depends on !CHAIN_OF_TRUST
+   default y if ARCH_BCM283X
+   default y if MMC_OMAP_HS && TI_COMMON_CMD_OPTIONS
select FAT_WRITE
help
  Define this if you want to use the FAT file system for the 
environment.
@@ -84,6 +66,13 @@ config ENV_IS_IN_FAT
 config ENV_IS_IN_FLASH
bool "Environment in flash memory"
depends on !CHAIN_OF_TRUST
+   default y if ARCH_CINTEGRATOR
+   default y if ARCH_INTEGRATOR_CP
+   default y if M548x || M547x || M5282 || MCF547x_8x
+   default y if MCF532x || MCF52x2
+   default y if MPC86xx || MPC83xx
+   default y if ARCH_MPC8572 || ARCH_MPC8548 || ARCH_MPC8641
+   default y if SH && !CPU_SH4
help
  Define this if you have a flash device which you want to use for the
  environment.
@@ -156,6 +145,11 @@ config ENV_IS_IN_FLASH
 config ENV_IS_IN_MMC
bool "Environment in an MMC device"
depends on !CHAIN_OF_TRUST
+   default y if ARCH_SUNXI
+   default y if ARCH_EXYNOS4
+   default y if MX6SX || MX7D
+   default y if TEGRA30 || TEGRA124
+   default y if TEGRA_ARMV8_COMMON
help
  Define this if you have an MMC device which you want to use for the
  environment.
@@ -293,6 +287,13 @@ config ENV_IS_IN_REMOTE
 config ENV_IS_IN_SPI_FLASH
bool "Environment is in SPI flash"
depends on !CHAIN_OF_TRUST
+   default y if ARMADA_XP
+   default y if INTEL_BAYTRAIL
+   default y if INTEL_BRASWELL
+   default y if INTEL_BROADWELL
+   default y if NORTHBRIDGE_INTEL_IVYBRIDGE
+   default y if INTEL_QUARK
+   default y if INTEL_QUEENSBAY
help
  Define this if you have a SPI Flash memory device which you
  want to use for the environment.
@@ -358,8 +359,6 @@ config ENV_IS_IN_UBI
  You will probably want to define these to avoid a really noisy system
  when storing the env in UBI.
 
-endchoice
-
 config ENV_AES
bool "AES-128 encryption for stored environment (DEPRECATED)"
help
-- 
2.14.3

___
U-Boot mailing list
U-Boot@lists.denx.de

[U-Boot] [RFC PATCH 08/10] env: Mark env_get_location as weak

[Maxime Ripard]

Allow boards and architectures to override the default environment lookup
code by overriding env_get_location.

Signed-off-by: Maxime Ripard 
---
 env/env.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/env/env.c b/env/env.c
index 6af9f897b0ae..aceb77d4073c 100644
--- a/env/env.c
+++ b/env/env.c
@@ -62,7 +62,7 @@ static enum env_location env_locations[] = {
 
 static enum env_location env_load_location;
 
-static enum env_location env_get_location(enum env_operation op, int prio)
+__weak enum env_location env_get_location(enum env_operation op, int prio)
 {
switch (op) {
case ENVO_GET_CHAR:
-- 
2.14.3

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

[U-Boot] [RFC PATCH 04/10] env: Pass additional parameters to the env lookup function

[Maxime Ripard]

In preparation for the multiple environment support, let's introduce two
new parameters to the environment driver lookup function: the priority and
operation.

The operation parameter is meant to identify, obviously, the operation you
might want to perform on the environment.

The priority is a number passed to identify the environment priority you
want to retrieve. The lowest priority parameter (0) will be the primary
source.

Combining the two parameters allow you to support multiple environments
through different priorities, and to change those priorities between read
and writes operations.

This is especially useful to implement migration mechanisms where you want
to always use the same environment first, be it to read or write, while the
common case is more likely to use the same environment it has read from to
write it to.

Signed-off-by: Maxime Ripard 
---
 env/env.c | 122 ++
 include/environment.h |   7 +++
 2 files changed, 80 insertions(+), 49 deletions(-)

diff --git a/env/env.c b/env/env.c
index 97ada5b5a6fd..673bfa6ba41b 100644
--- a/env/env.c
+++ b/env/env.c
@@ -26,8 +26,11 @@ static struct env_driver *_env_driver_lookup(enum 
env_location loc)
return NULL;
 }
 
-static enum env_location env_get_location(void)
+static enum env_location env_get_location(enum env_operation op, int prio)
 {
+   if (prio >= 1)
+   return ENVL_UNKNOWN;
+
if IS_ENABLED(CONFIG_ENV_IS_IN_EEPROM)
return ENVL_EEPROM;
else if IS_ENABLED(CONFIG_ENV_IS_IN_FAT)
@@ -52,11 +55,14 @@ static enum env_location env_get_location(void)
return ENVL_UNKNOWN;
 }
 
-static struct env_driver *env_driver_lookup(void)
+static struct env_driver *env_driver_lookup(enum env_operation op, int prio)
 {
-   enum env_location loc = env_get_location();
+   enum env_location loc = env_get_location(op, prio);
struct env_driver *drv;
 
+   if (loc == ENVL_UNKNOWN)
+   return NULL;
+
drv = _env_driver_lookup(loc);
if (!drv) {
debug("%s: No environment driver for location %d\n", __func__,
@@ -69,83 +75,101 @@ static struct env_driver *env_driver_lookup(void)
 
 int env_get_char(int index)
 {
-   struct env_driver *drv = env_driver_lookup();
-   int ret;
+   struct env_driver *drv;
+   int prio;
 
if (gd->env_valid == ENV_INVALID)
return default_environment[index];
-   if (!drv)
-   return -ENODEV;
-   if (!drv->get_char)
-   return *(uchar *)(gd->env_addr + index);
-   ret = drv->get_char(index);
-   if (ret < 0) {
-   debug("%s: Environment failed to load (err=%d)\n",
- __func__, ret);
+
+   for (prio = 0; (drv = env_driver_lookup(ENVO_GET_CHAR, prio)); prio++) {
+   int ret;
+
+   if (!drv->get_char)
+   continue;
+
+   ret = drv->get_char(index);
+   if (!ret)
+   return 0;
+
+   debug("%s: Environment %s failed to load (err=%d)\n", __func__,
+ drv->name, ret);
}
 
-   return ret;
+   return -ENODEV;
 }
 
 int env_load(void)
 {
-   struct env_driver *drv = env_driver_lookup();
-   int ret = 0;
+   struct env_driver *drv;
+   int prio;
 
-   if (!drv)
-   return -ENODEV;
-   if (!drv->load)
-   return 0;
-   ret = drv->load();
-   if (ret) {
-   debug("%s: Environment failed to load (err=%d)\n", __func__,
- ret);
-   return ret;
+   for (prio = 0; (drv = env_driver_lookup(ENVO_LOAD, prio)); prio++) {
+   int ret;
+
+   if (!drv->load)
+   continue;
+
+   ret = drv->load();
+   if (!ret)
+   return 0;
+
+   debug("%s: Environment %s failed to load (err=%d)\n", __func__,
+ drv->name, ret);
}
 
-   return 0;
+   return -ENODEV;
 }
 
 int env_save(void)
 {
-   struct env_driver *drv = env_driver_lookup();
-   int ret;
+   struct env_driver *drv;
+   int prio;
 
-   if (!drv)
-   return -ENODEV;
-   if (!drv->save)
-   return -ENOSYS;
-
-   printf("Saving Environment to %s...\n", drv->name);
-   ret = drv->save();
-   if (ret) {
-   debug("%s: Environment failed to save (err=%d)\n", __func__,
- ret);
-   return ret;
+   for (prio = 0; (drv = env_driver_lookup(ENVO_SAVE, prio)); prio++) {
+   int ret;
+
+   if (!drv->save)
+   continue;
+
+   printf("Saving Environment to %s...\n", drv->name);
+   ret = drv->save();
+   if (!ret)
+   return 

[U-Boot] [RFC PATCH 03/10] env: Rename env_driver_lookup_default and env_get_default_location

[Maxime Ripard]

The env_driver_lookup_default and env_get_default_location functions are
about to get refactored to support loading from multiple environment.

The name is therefore not really well suited anymore. Drop the default
part to be a bit more relevant.

Signed-off-by: Maxime Ripard 
---
 env/env.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/env/env.c b/env/env.c
index 094538ff5b62..97ada5b5a6fd 100644
--- a/env/env.c
+++ b/env/env.c
@@ -10,7 +10,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static struct env_driver *env_driver_lookup(enum env_location loc)
+static struct env_driver *_env_driver_lookup(enum env_location loc)
 {
struct env_driver *drv;
const int n_ents = ll_entry_count(struct env_driver, env_driver);
@@ -26,7 +26,7 @@ static struct env_driver *env_driver_lookup(enum env_location 
loc)
return NULL;
 }
 
-static enum env_location env_get_default_location(void)
+static enum env_location env_get_location(void)
 {
if IS_ENABLED(CONFIG_ENV_IS_IN_EEPROM)
return ENVL_EEPROM;
@@ -52,12 +52,12 @@ static enum env_location env_get_default_location(void)
return ENVL_UNKNOWN;
 }
 
-static struct env_driver *env_driver_lookup_default(void)
+static struct env_driver *env_driver_lookup(void)
 {
-   enum env_location loc = env_get_default_location();
+   enum env_location loc = env_get_location();
struct env_driver *drv;
 
-   drv = env_driver_lookup(loc);
+   drv = _env_driver_lookup(loc);
if (!drv) {
debug("%s: No environment driver for location %d\n", __func__,
  loc);
@@ -69,7 +69,7 @@ static struct env_driver *env_driver_lookup_default(void)
 
 int env_get_char(int index)
 {
-   struct env_driver *drv = env_driver_lookup_default();
+   struct env_driver *drv = env_driver_lookup();
int ret;
 
if (gd->env_valid == ENV_INVALID)
@@ -89,7 +89,7 @@ int env_get_char(int index)
 
 int env_load(void)
 {
-   struct env_driver *drv = env_driver_lookup_default();
+   struct env_driver *drv = env_driver_lookup();
int ret = 0;
 
if (!drv)
@@ -108,7 +108,7 @@ int env_load(void)
 
 int env_save(void)
 {
-   struct env_driver *drv = env_driver_lookup_default();
+   struct env_driver *drv = env_driver_lookup();
int ret;
 
if (!drv)
@@ -129,7 +129,7 @@ int env_save(void)
 
 int env_init(void)
 {
-   struct env_driver *drv = env_driver_lookup_default();
+   struct env_driver *drv = env_driver_lookup();
int ret = -ENOENT;
 
if (!drv)
-- 
2.14.3

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

[U-Boot] [RFC PATCH 02/10] env: Make env_driver_lookup_default private

[Maxime Ripard]

No that there's no users of env_driver_lookup_default outside of env/env.c,
we can mark that function static and remove it from the environment header.

Signed-off-by: Maxime Ripard 
---
 env/env.c | 2 +-
 include/environment.h | 7 ---
 2 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/env/env.c b/env/env.c
index 84c12e27bc3f..094538ff5b62 100644
--- a/env/env.c
+++ b/env/env.c
@@ -52,7 +52,7 @@ static enum env_location env_get_default_location(void)
return ENVL_UNKNOWN;
 }
 
-struct env_driver *env_driver_lookup_default(void)
+static struct env_driver *env_driver_lookup_default(void)
 {
enum env_location loc = env_get_default_location();
struct env_driver *drv;
diff --git a/include/environment.h b/include/environment.h
index 7b9821638960..226e3ef2d23a 100644
--- a/include/environment.h
+++ b/include/environment.h
@@ -302,13 +302,6 @@ int env_export(env_t *env_out);
 int env_import_redund(const char *buf1, const char *buf2);
 #endif
 
-/**
- * env_driver_lookup_default() - Look up the default environment driver
- *
- * @return pointer to driver, or NULL if none (which should not happen)
- */
-struct env_driver *env_driver_lookup_default(void);
-
 /**
  * env_get_char() - Get a character from the early environment
  *
-- 
2.14.3

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

[U-Boot] [RFC PATCH 01/10] cmd: nvedit: Get rid of the env lookup

[Maxime Ripard]

The nvedit command is the only user of env_driver_lookup_default outside of
the environment code itself, and it uses it only to print the environment
it's about to save to during env save.

As we're about to rework the environment to be able to handle multiple
environment sources, we might not have an idea of what environment backend
is going to be used before trying (and possibly failing for some).

Therefore, it makes sense to remove that message and move it to the
env_save function itself. As a side effect, we also can get rid of the call
to env_driver_lookup default that is also about to get refactored.

Signed-off-by: Maxime Ripard 
---
 cmd/nvedit.c | 4 
 env/env.c| 2 ++
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 4e79d03856fe..a690d743cd46 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -708,10 +708,6 @@ ulong env_get_ulong(const char *name, int base, ulong 
default_val)
 static int do_env_save(cmd_tbl_t *cmdtp, int flag, int argc,
   char * const argv[])
 {
-   struct env_driver *env = env_driver_lookup_default();
-
-   printf("Saving Environment to %s...\n", env->name);
-
return env_save() ? 1 : 0;
 }
 
diff --git a/env/env.c b/env/env.c
index 76a5608628fc..84c12e27bc3f 100644
--- a/env/env.c
+++ b/env/env.c
@@ -115,6 +115,8 @@ int env_save(void)
return -ENODEV;
if (!drv->save)
return -ENOSYS;
+
+   printf("Saving Environment to %s...\n", drv->name);
ret = drv->save();
if (ret) {
debug("%s: Environment failed to save (err=%d)\n", __func__,
-- 
2.14.3

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

[U-Boot] [RFC PATCH 10/10] env: sunxi: Enable FAT-based environment support by default

[Maxime Ripard]

Now that we have everything in place to implement the transition scheme,
let's enable it by default.

Signed-off-by: Maxime Ripard 
---
 env/Kconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/env/Kconfig b/env/Kconfig
index bf6eab6b4ace..19524638e6e1 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -55,6 +55,7 @@ config ENV_IS_IN_FAT
bool "Environment is in a FAT filesystem"
depends on !CHAIN_OF_TRUST
default y if ARCH_BCM283X
+   default y if ARCH_SUNXI
default y if MMC_OMAP_HS && TI_COMMON_CMD_OPTIONS
select FAT_WRITE
help
@@ -370,6 +371,7 @@ config ENV_AES
 config ENV_FAT_INTERFACE
string "Name of the block device for the environment"
depends on ENV_IS_IN_FAT
+   default "mmc" if ARCH_SUNXI
default "mmc" if TI_COMMON_CMD_OPTIONS || ARCH_ZYNQMP || ARCH_AT91
help
  Define this to a string that is the name of the block device.
@@ -379,6 +381,8 @@ config ENV_FAT_DEVICE_AND_PART
depends on ENV_IS_IN_FAT
default "0:1" if TI_COMMON_CMD_OPTIONS
default "0:auto" if ARCH_ZYNQMP
+   default "0:auto" if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA = -1
+   default "1:auto" if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA != -1
default "0" if ARCH_AT91
help
  Define this to a string to specify the partition of the device. It can
-- 
2.14.3

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

[U-Boot] [RFC PATCH 00/10] env: Multiple env support and env transition for sunxi

[Maxime Ripard]

Hi,

Here is a second attempt at transitioning away from the MMC raw
environment to a FAT-based one.

You'll find the first one here for reference:
https://lists.denx.de/pipermail/u-boot/2017-October/310111.html

The fundamental issue I'm trying to adress is that we've had for a
very long time the assumption that the main U-Boot binary wouldn't
exceed around 500 bytes.

However, we're starting to get real close to that limit, and are
running out of silver bullets to deal with the consequences of having
a bigger U-Boot binary, the main consequence being that we would
have some overlap between the environment and U-Boot.

One way to address this that has been suggested by Tom is to move away
from the raw MMC environment to a FAT-based one. This would allow us
to slowly migrate away, and eventually remove the MMC-raw option
entirely to reclaim that space for the binary.

That cannot be done in a single release however, since we might have
environments in the wild already that people rely on. And since we
always encouraged people to use the raw MMC environment, noone would
expect that.

This is even worse since some platforms are using the U-Boot
environment to deal with implement their upgrade mechanism, such as
mender.io, and force moving the environment would break any further
upgrade.

The suggested implementation is to allow U-Boot to compile multiple
environments backend at once, based on the work done by Simon. The
default behaviour shouldn't change obviously. We can then piggy-back
on this to tweak on a per-board basis the environment lookup algorithm
to always favour the FAT-based environment and then fallback to the
MMC. It will allow us to migrate a raw-MMC user to a FAT based
solution as soon as they update their environment (assuming that there
is a bootable FAT partition in the system).

This has just been compile tested on sunxi so far, and I'd like
general comments on the approach taken. Obviously, this will need to
work properly before being merged.

Let me know what you think,
Maxime

Maxime Ripard (10):
  cmd: nvedit: Get rid of the env lookup
  env: Make env_driver_lookup_default private
  env: Rename env_driver_lookup_default and env_get_default_location
  env: Pass additional parameters to the env lookup function
  env: Make the env save message a bit more explicit
  env: Support multiple environments
  env: Allow to build multiple environments in Kconfig
  env: Mark env_get_location as weak
  sunxi: Transition from the MMC to a FAT-based environment
  env: sunxi: Enable FAT-based environment support by default

 board/sunxi/board.c   |  16 +
 cmd/nvedit.c  |   4 --
 env/Kconfig   |  69 +-
 env/env.c | 194 --
 include/environment.h |  14 ++--
 5 files changed, 182 insertions(+), 115 deletions(-)

-- 
2.14.3

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

Re: [U-Boot] [PATCH v6 1/7] armv8: lsch3: Add serdes and DDR voltage setup

[Rajesh Bhagat]

> -Original Message-
> From: York Sun
> Sent: Tuesday, November 14, 2017 10:27 PM
> To: Rajesh Bhagat ; u-boot@lists.denx.de
> Cc: Prabhakar Kushwaha ; Priyanka Jain
> ; Ashish Kumar 
> Subject: Re: [PATCH v6 1/7] armv8: lsch3: Add serdes and DDR voltage setup
> 
> On 11/13/2017 11:06 PM, Rajesh Bhagat wrote:
> > Adds SERDES voltage and reset SERDES lanes API and makes
> > enable/disable DDR controller support 0.9V API common.
> >
> > Signed-off-by: Ashish Kumar 
> > Signed-off-by: Rajesh Bhagat 
> > ---
> > Changes in v6:
> >   - Corrected indentation/alignment issues at various places
> >   - Changed NULL ENTRY in srds_prctl_info array to id as zero
> >   - Corrected the PLL Reset logic, moved code inside for loop
> >   - Used error code(-EINVAL) in setup_serdes_volt API
> >
> > Changes in v5:
> >   - Moved local macros to static functions
> >   - Used array to handle PRCTL mask and shift operations
> >
> > Changes in v4:
> >   - Added local macros instead of magical numbers
> >   - Created macros to remove duplicate code
> >
> > Changes in v3:
> >  Restructured LS1088A VID support to use common VID driver  Cosmetic
> > review comments fixed  Added __iomem for accessing registers
> >
> > Changes in v2:
> >  Checkpatch errors fixed
> >
> >  .../cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c| 312
> +
> >  arch/arm/cpu/armv8/fsl-layerscape/soc.c|  34 +--
> >  .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |   2 +-
> >  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  34 +++
> >  arch/arm/include/asm/arch-fsl-layerscape/soc.h |   1 +
> >  5 files changed, 365 insertions(+), 18 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> > index 179cac6..3e4b0bc 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_serdes.c
> > @@ -158,6 +158,318 @@ void serdes_init(u32 sd, u32 sd_addr, u32 rcwsr, u32
> sd_prctl_mask,
> > serdes_prtcl_map[NONE] = 1;
> >  }
> >
> > +__weak int get_serdes_volt(void)
> > +{
> > +   return -1;
> > +}
> > +
> > +__weak int set_serdes_volt(int svdd)
> > +{
> > +   return -1;
> > +}
> > +
> > +#define LNAGCR0_RESET_MASK 0xFF9F
> > +#define LNAGCR0_RT_RSTB0x0060
> > +#define RSTCTL_RESET_MASK_10xFFBF
> > +#define RSTCTL_RESET_MASK_20xFF1F
> > +#define RSTCTL_RESET_MASK_30xFFEF
> > +#define RSTCTL_RSTREQ  0x1000
> > +#define RSTCTL_RSTERR  0x2000
> > +#define RSTCTL_SDEN0x0020
> > +#define RSTCTL_SDRST_B 0x0040
> > +#define RSTCTL_PLLRST_B0x0080
> > +#define RSTCTL_RST_DONE0x4000
> > +#define TCALCR_RESET_MASK  0xF7FF
> > +#define TCALCR_CALRST_B0x0800
> > +
> > +struct serdes_prctl_info {
> > +   u32 id;
> > +   u32 mask;
> > +   u32 shift;
> > +};
> > +
> > +struct serdes_prctl_info srds_prctl_info[] = { #ifdef
> > +CONFIG_SYS_FSL_SRDS_1
> > +   {.id = 1,
> > +.mask = FSL_CHASSIS3_SRDS1_PRTCL_MASK,
> > +.shift = FSL_CHASSIS3_SRDS1_PRTCL_SHIFT
> > +   },
> > +
> > +#endif
> > +#ifdef CONFIG_SYS_FSL_SRDS_2
> > +   {.id = 2,
> > +.mask = FSL_CHASSIS3_SRDS2_PRTCL_MASK,
> > +.shift = FSL_CHASSIS3_SRDS2_PRTCL_SHIFT
> > +   },
> > +#endif
> > +   {.id = 0,
> > +.mask = 0,
> > +.shift = 0
> > +   } /* NULL ENTRY */
> > +};
> 
> A simple {} will do the same.

Will take care in v7.

> 
> > +
> > +static int get_serdes_prctl_info_idx(u32 serdes_id) {
> > +   int pos = 0;
> > +   struct serdes_prctl_info *srds_info;
> > +
> > +   /* loop until NULL ENTRY defined by .id=0 */
> > +   for (srds_info = srds_prctl_info; srds_info->id != 0;
> > +srds_info++, pos++) {
> > +   if (srds_info->id == serdes_id)
> > +   return pos;
> > +   }
> > +
> > +   return -1;
> > +}
> > +
> > +static void do_enabled_lanes_reset(u32 serdes_id, u32 cfg,
> > +  struct ccsr_serdes __iomem *serdes_base,
> > +  bool cmplt)
> > +{
> > +   int i, pos;
> > +   u32 cfg_tmp, reg = 0;
> > +
> > +   pos = get_serdes_prctl_info_idx(serdes_id);
> > +   if (pos == -1) {
> > +   printf("invalid serdes_id %d\n", serdes_id);
> > +   return;
> > +   }
> > +
> > +   cfg_tmp = cfg & srds_prctl_info[pos].mask;
> > +   cfg_tmp >>= srds_prctl_info[pos].shift;
> > +
> > +   for (i = 0; i < 4 && cfg_tmp & (0xf << (3 - i)); i++) {
> > +   reg = in_le32(_base->lane[i].gcr0);
> > +   reg = (cmplt ? reg | LNAGCR0_RT_RSTB :
> > +  reg & LNAGCR0_RESET_MASK);
> > +   out_le32(_base->lane[i].gcr0, reg);
> > +   }
> > +}
> 
> Have you considered to use 

Re: [U-Boot] [OE-core] [PATCH] u-boot: Upgrade to 2017.11 release

[Marek Vasut]

On 11/15/2017 05:47 PM, Stefan Agner wrote:
> On 2017-11-14 19:32, Otavio Salvador wrote:
>> This upgrades the U-Boot from 2017.09 to 2017.11 release.
> 
> You might encounter this when building fw_printenv/setenv tools alone:
> 
> https://lists.denx.de/pipermail/u-boot/2017-November/311505.html

[...]

>>  SRC_URI = "git://git.denx.de/u-boot.git \
>>  file://MPC8315ERDB-enable-DHCP.patch \
I also see that the number of out-of-tree patches didn't change since
last time, even though I complained about it ... why are these patches
still here ?

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

Re: [U-Boot] [PATCH 1/2] common: Generic file system firmware loader

[Marek Vasut]

On 11/16/2017 09:09 AM, Chee, Tien Fong wrote:
> On Jum, 2017-11-10 at 11:04 +0100, Marek Vasut wrote:
>> On 11/10/2017 10:05 AM, Chee, Tien Fong wrote:
>>>
>>> On Kha, 2017-11-09 at 11:31 +0100, Marek Vasut wrote:

 On 11/09/2017 11:00 AM, Lukasz Majewski wrote:
>
>
> On Thu, 9 Nov 2017 08:05:18 +0100
> Marek Vasut  wrote:
>
>>
>>
>> On 11/09/2017 07:04 AM, Chee, Tien Fong wrote:
>>>
>>>
>>> On Sel, 2017-11-07 at 10:34 +0100, Marek Vasut wrote:  


 On 11/07/2017 10:03 AM, Chee, Tien Fong wrote:  
>
>
>
> On Isn, 2017-11-06 at 11:56 +0100, Marek Vasut wrote:  
>>
>>
>>
>> On 11/06/2017 05:15 AM, Chee, Tien Fong wrote:  
>>>
>>>
>>>
>>>
>>> On Ahd, 2017-11-05 at 17:43 +0100, Marek Vasut
>>> wrote:  




 On 11/02/2017 09:20 AM, Chee, Tien Fong wrote:  
>
>
>
>
>
> On Rab, 2017-11-01 at 10:26 +0100, Marek Vasut
> wrote:  
>>
>>
>>
>>
>>
>> On 11/01/2017 10:18 AM, tien.fong.chee@intel.
>> com
>> wrote:  
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: Tien Fong Chee >> com>
>>>
>>> Generic firmware loader framework contains
>>> some
>>> common
>>> functionality
>>> which is factored out from splash loader.
>>> It is
>>> reusable by
>>> any
>>> specific driver file system firmware
>>> loader.
>>> Specific
>>> driver
>>> file
>>> system
>>> firmware loader handling can be defined
>>> with
>>> both weak
>>> function
>>> fsloader_preprocess and fs_loading.
>>>
>>> Signed-off-by: Tien Fong Chee >> ee@i
>>> ntel.com  


  
>>> ---
>>>  common/Makefile   |   1 +
>>>  common/load_fs.c  | 217
>>> +++
>>> 
>>> +++
>>>  include/load_fs.h |  38 ++
>>>  3 files changed, 256 insertions(+)
>>>  create mode 100644 common/load_fs.c
>>>  create mode 100644 include/load_fs.h  
>> [...]
>>  
>>>
>>>
>>>
>>>
>>>
>>>
>>> +int flash_select_fs_dev(struct
>>> flash_location
>>> *location)  
>> Why does everything have flash_ prefix ?
>>  
> I can remove the flash_ prefix, this generic FS
> loader
> should
> support
> for all filesystem instead of flash.
>  
>>
>>
>>
>>
>>
>> I also mentioned the API should copy the
>> linux
>> firmware
>> loader
>> API.
>>  
> If i'm not mistaken, you are referring firmware
> loader API
> in
> this
> link https://github.com/torvalds/linux/blob/f00
> 7cad
> 159e99fa
> 2acd
> 3b2e
> 9364
> fbb32ad28b971/drivers/base/firmware_class.c#L12
> 64.
>  
>>> I would like to confirm with you whether we are
>>> talking
>>> to the
>>> same
>>> API
>>> above?  
>> https://www.kernel.org/doc/html/v4.13/driver-api/firm
>> ware
>> /index.h
>> tml
>>
>> first link on google btw . You might be able to avoid
>> the
>> firmware
>> structure.
>>  
> After assessment, i found that Linux loader is not
> suitable
> for
> fpga
> loader as fpga loader need
> 1) Able to program FPGA image in SPL chunk bu chunk
> with
> small
> memory
> allocatted.
> 2) Name of FPGA image defined in DTS, and path of FPGA
> image in
> FAT and
> UBI partition.
>
> Linux loader is strongly designed based on Linux
> environment,
> always
> assume having RFF, env support(which SPL don't have),
> sysfs
> and
> udev
> feature.  
 Sigh, you can just have some additional function call to

Re: [U-Boot] cadence_qspi_apb: cache issues on mach-socfpga

[Marek Vasut]

On 11/15/2017 11:38 PM, Rush, Jason A wrote:
> Goldschmidt Simon Wrote:
>> Marek Vasut wrote:
> I don't believe the patchset I submitted for DT bindings were merged in.

 I can confirm that. I'd strongly vote for them to get in as cadence_qspi
 is otherwise not usable on mach socfpga.

 How can I ensure a tested-by from me gets related to that patch set?
 I can't reply to it as I was not subscribed to the list at that time.
>>>
>>> You should rebase that patch anyway and then resend it.
>>
>> I could do that work but I guess it would be up to Jason to do that,
>> regarding authorship?

Just retain the From: field and add your SoB line

>> Simon
> 
> I can probably rebase and send it again later this week.
> 
> -- Jason
> 


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

Re: [U-Boot] [PATCH 1/2] common: Generic file system firmware loader

[Chee, Tien Fong]

On Jum, 2017-11-10 at 11:04 +0100, Marek Vasut wrote:
> On 11/10/2017 10:05 AM, Chee, Tien Fong wrote:
> > 
> > On Kha, 2017-11-09 at 11:31 +0100, Marek Vasut wrote:
> > > 
> > > On 11/09/2017 11:00 AM, Lukasz Majewski wrote:
> > > > 
> > > > 
> > > > On Thu, 9 Nov 2017 08:05:18 +0100
> > > > Marek Vasut  wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > On 11/09/2017 07:04 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > On Sel, 2017-11-07 at 10:34 +0100, Marek Vasut wrote:  
> > > > > > > 
> > > > > > > 
> > > > > > > On 11/07/2017 10:03 AM, Chee, Tien Fong wrote:  
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Isn, 2017-11-06 at 11:56 +0100, Marek Vasut wrote:  
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 11/06/2017 05:15 AM, Chee, Tien Fong wrote:  
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On Ahd, 2017-11-05 at 17:43 +0100, Marek Vasut
> > > > > > > > > > wrote:  
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 11/02/2017 09:20 AM, Chee, Tien Fong wrote:  
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > On Rab, 2017-11-01 at 10:26 +0100, Marek Vasut
> > > > > > > > > > > > wrote:  
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On 11/01/2017 10:18 AM, tien.fong.chee@intel.
> > > > > > > > > > > > > com
> > > > > > > > > > > > > wrote:  
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > From: Tien Fong Chee  > > > > > > > > > > > > > com>
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Generic firmware loader framework contains
> > > > > > > > > > > > > > some
> > > > > > > > > > > > > > common
> > > > > > > > > > > > > > functionality
> > > > > > > > > > > > > > which is factored out from splash loader.
> > > > > > > > > > > > > > It is
> > > > > > > > > > > > > > reusable by
> > > > > > > > > > > > > > any
> > > > > > > > > > > > > > specific driver file system firmware
> > > > > > > > > > > > > > loader.
> > > > > > > > > > > > > > Specific
> > > > > > > > > > > > > > driver
> > > > > > > > > > > > > > file
> > > > > > > > > > > > > > system
> > > > > > > > > > > > > > firmware loader handling can be defined
> > > > > > > > > > > > > > with
> > > > > > > > > > > > > > both weak
> > > > > > > > > > > > > > function
> > > > > > > > > > > > > > fsloader_preprocess and fs_loading.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Signed-off-by: Tien Fong Chee  > > > > > > > > > > > > > ee@i
> > > > > > > > > > > > > > ntel.com  
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > >  
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > >  common/Makefile   |   1 +
> > > > > > > > > > > > > >  common/load_fs.c  | 217
> > > > > > > > > > > > > > +++
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > +++
> > > > > > > > > > > > > >  include/load_fs.h |  38 ++
> > > > > > > > > > > > > >  3 files changed, 256 insertions(+)
> > > > > > > > > > > > > >  create mode 100644 common/load_fs.c
> > > > > > > > > > > > > >  create mode 100644 include/load_fs.h  
> > > > > > > > > > > > > [...]
> > > > > > > > > > > > >  
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > +int flash_select_fs_dev(struct
> > > > > > > > > > > > > > flash_location
> > > > > > > > > > > > > > *location)  
> > > > > > > > > > > > > Why does everything have flash_ prefix ?
> > > > > > > > > > > > >  
> > > > > > > > > > > > I can remove the flash_ prefix, this generic FS
> > > > > > > > > > > > loader
> > > > > > > > > > > > should
> > > > > > > > > > > > support
> > > > > > > > > > > > for all filesystem instead of flash.
> > > > > > > > > > > >  
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I also mentioned the API should copy the
> > > > > > > > > > > > > linux
> > > > > > > > > > > > > firmware
> > > > > > > > > > > > > loader
> > > > > > > > > > > > > API.
> > > > > > > > > > > > >  
> > > > > > > > > > > > If i'm not mistaken, you are referring firmware
> > > > > > > > > > > > loader API
> > > > > > > > > > > > in
> > > > > > > > > > > > this
> > > > > > > > > > > > link https://github.com/torvalds/linux/blob/f00
> > > > > > > > > > > > 7cad
> > > > > > 

[U-Boot] [PATCH] mach-stm32: Factorize MPU's region config for STM32 SoCs

[patrice.chotard]

From: Patrice Chotard 

MPU's region setup can be factorized between STM32F4/F7/H7 SoCs family
and used a common MPU's region config.

Only one exception for STM32H7 which doesn't have device area
located at 0xA000 .

For STM32F4, configure_clocks() need to be moved from arch_cpu_init()
to board_early_init_f().

Signed-off-by: Patrice Chotard 
---
 arch/arm/mach-stm32/Makefile   |  3 +-
 arch/arm/mach-stm32/{stm32h7 => }/soc.c| 25 +--
 arch/arm/mach-stm32/stm32f4/Makefile   |  2 +-
 arch/arm/mach-stm32/stm32f4/soc.c  | 41 --
 arch/arm/mach-stm32/stm32f7/Makefile   |  2 +-
 arch/arm/mach-stm32/stm32f7/soc.c  | 49 --
 arch/arm/mach-stm32/stm32h7/Makefile   |  8 
 board/st/stm32f429-discovery/stm32f429-discovery.c |  2 +
 8 files changed, 16 insertions(+), 116 deletions(-)
 rename arch/arm/mach-stm32/{stm32h7 => }/soc.c (75%)
 delete mode 100644 arch/arm/mach-stm32/stm32f4/soc.c
 delete mode 100644 arch/arm/mach-stm32/stm32f7/soc.c
 delete mode 100644 arch/arm/mach-stm32/stm32h7/Makefile

diff --git a/arch/arm/mach-stm32/Makefile b/arch/arm/mach-stm32/Makefile
index 0f5ac37..c2806af 100644
--- a/arch/arm/mach-stm32/Makefile
+++ b/arch/arm/mach-stm32/Makefile
@@ -4,7 +4,6 @@
 #
 # SPDX-License-Identifier: GPL-2.0+
 #
-
+obj-y += soc.o
 obj-$(CONFIG_STM32F4) += stm32f4/
 obj-$(CONFIG_STM32F7) += stm32f7/
-obj-$(CONFIG_STM32H7) += stm32h7/
diff --git a/arch/arm/mach-stm32/stm32h7/soc.c b/arch/arm/mach-stm32/soc.c
similarity index 75%
rename from arch/arm/mach-stm32/stm32h7/soc.c
rename to arch/arm/mach-stm32/soc.c
index 692dbcc..df20d54 100644
--- a/arch/arm/mach-stm32/stm32h7/soc.c
+++ b/arch/arm/mach-stm32/soc.c
@@ -9,11 +9,6 @@
 #include 
 #include 
 
-u32 get_cpu_rev(void)
-{
-   return 0;
-}
-
 int arch_cpu_init(void)
 {
int i;
@@ -30,11 +25,11 @@ int arch_cpu_init(void)
{ 0x, REGION_0, XN_DIS, PRIV_RW_USR_RW,
O_I_WB_RD_WR_ALLOC, REGION_4GB },
 
-   /* Code area, executable & strongly ordered */
-   { 0xD000, REGION_1, XN_EN, PRIV_RW_USR_RW,
-   STRONG_ORDER, REGION_8MB },
+   /* armv7m code area */
+   { 0x, REGION_1, XN_DIS, PRIV_RW_USR_RW,
+   STRONG_ORDER, REGION_512MB },
 
-   /* Device area in all H7 : Not executable */
+   /* Device area : Not executable */
{ 0x4000, REGION_2, XN_EN, PRIV_RW_USR_RW,
DEVICE_NON_SHARED, REGION_512MB },
 
@@ -42,8 +37,14 @@ int arch_cpu_init(void)
 * Armv7m fixed configuration: strongly ordered & not
 * executable, not cacheable
 */
-   { 0xE000, REGION_4, XN_EN, PRIV_RW_USR_RW,
+   { 0xE000, REGION_3, XN_EN, PRIV_RW_USR_RW,
STRONG_ORDER, REGION_512MB },
+
+#if !defined(CONFIG_STM32H7)
+   /* Device area : Not executable */
+   { 0xA000, REGION_4, XN_EN, PRIV_RW_USR_RW,
+   DEVICE_NON_SHARED, REGION_512MB },
+#endif
};
 
disable_mpu();
@@ -53,7 +54,3 @@ int arch_cpu_init(void)
 
return 0;
 }
-
-void s_init(void)
-{
-}
diff --git a/arch/arm/mach-stm32/stm32f4/Makefile 
b/arch/arm/mach-stm32/stm32f4/Makefile
index 020e783..63db820 100644
--- a/arch/arm/mach-stm32/stm32f4/Makefile
+++ b/arch/arm/mach-stm32/stm32f4/Makefile
@@ -8,4 +8,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y += soc.o clock.o timer.o
+obj-y += clock.o timer.o
diff --git a/arch/arm/mach-stm32/stm32f4/soc.c 
b/arch/arm/mach-stm32/stm32f4/soc.c
deleted file mode 100644
index 9eb655a..000
--- a/arch/arm/mach-stm32/stm32f4/soc.c
+++ /dev/null
@@ -1,41 +0,0 @@
-/*
- * (C) Copyright 2015
- * Kamil Lulko, 
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-#include 
-
-u32 get_cpu_rev(void)
-{
-   return 0;
-}
-
-int arch_cpu_init(void)
-{
-   struct mpu_region_config stm32_region_config[] = {
-   { 0x, REGION_0, XN_DIS, PRIV_RW_USR_RW,
-   STRONG_ORDER, REGION_4GB },
-   };
-   int i;
-
-   configure_clocks();
-   /*
-* Configure the memory protection unit (MPU) to allow full access to
-* the whole 4GB address space.
-*/
-   disable_mpu();
-   for (i = 0; i < ARRAY_SIZE(stm32_region_config); i++)
-   mpu_config(_region_config[i]);
-   enable_mpu();
-
-   return 0;
-}
-
-void s_init(void)
-{
-}
diff --git a/arch/arm/mach-stm32/stm32f7/Makefile 
b/arch/arm/mach-stm32/stm32f7/Makefile
index 6696b26..8132c13 100644
--- a/arch/arm/mach-stm32/stm32f7/Makefile
+++ b/arch/arm/mach-stm32/stm32f7/Makefile
@@ -5,4 +5,4 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-y += timer.o soc.o