Re: [U-Boot] [RFC PATCH v3 01/10] mtd: nand: pxa3xx_nand: Increase initial buffer size

2017-12-05 Thread Chris Packham 
Hi Ofer,

On Wed, Dec 6, 2017 at 7:55 PM,   wrote:
> From: Ofer Heifetz 
>
> The initial buffer is used for the initial commands used to detect
> a flash device (STATUS, READID and PARAM).
>
> ONFI param page is 256 bytes, and there are three redundant copies
> to be read. JEDEC param page is 512 bytes, and there are also three
> redundant copies to be read. Hence this buffer should be at least
> 512 x 3. This commits rounds the buffer size to 2048.
>
> [ Linux commit c16340973fcb6461474a9f811f7f3ff2f946b24c ]
>
> Cc: Ezequiel Garcia 
> Signed-off-by: Chris Packham 
> Reviewed-by: Ofer Heifetz 
> Tested-by: Ofer Heifetz 

Thanks for testing these. Since I sent the initial series I hadn't
heard anything back (the nand maintainer seems to be inactive).

Did you manage to rebase this series against u-boot#master? I've just
got my hands on a DB-88F78460-AMC board I was planning on porting it
to upstream u-boot when I find some time. It would be another good
test platform for these changes.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] arm: sunxi: Allwinner A10 SPI driver

2017-12-05 Thread Jagan Teki 
On Fri, Dec 1, 2017 at 1:57 PM, Stefan Mavrodiev  wrote:
> Add spi driver for sun4i, sun5i and sun7i SoCs. The driver is
> adapted from mailine kernel (currently 4.15.0-rc1).
>
> Signed-off-by: Stefan Mavrodiev 
> ---
>  Tested with A20-OLinuXino-Lime2 with W25Q128 chip. The output is:
>  => sspi
>
>  => sf probe
>  SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16 
> Mib
>
>  => sf test 0 100
>  SPI flash test:
>  0 erase: 188398 ticks, 86 KiB/s 0.688 Mbps
>  1 check: 141504 ticks, 115 KiB/s 0.920 Mbps
>  2 write: 174697 ticks, 93 KiB/s 0.744 Mbps
>  3 read: 141312 ticks, 115 KiB/s 0.920 Mbps
>  Test passed
>  0 erase: 188398 ticks, 86 KiB/s 0.688 Mbps
>  1 check: 141504 ticks, 115 KiB/s 0.920 Mbps
>  2 write: 174697 ticks, 93 KiB/s 0.744 Mbps
>  3 read: 141312 ticks, 115 KiB/s 0.920 Mbps
>
>  drivers/spi/Kconfig |   5 +
>  drivers/spi/Makefile|   1 +
>  drivers/spi/sun4i_spi.c | 423 
> 
>  3 files changed, 429 insertions(+)
>  create mode 100644 drivers/spi/sun4i_spi.c
>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 88da9a4..d78253a 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -132,6 +132,11 @@ config STM32_QSPI
>   used to access the SPI NOR flash chips on platforms embedding
>   this ST IP core.
>
> +config SUN4I_SPI
> +   bool "Allwinner A10 SoCs SPI controller"
> +   help
> + SPI driver for Allwinner sun4i, sun5i and sun7i SoCs
> +
>  config TEGRA114_SPI
> bool "nVidia Tegra114 SPI driver"
> help
> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> index ad56203..04ba305 100644
> --- a/drivers/spi/Makefile
> +++ b/drivers/spi/Makefile
> @@ -42,6 +42,7 @@ obj-$(CONFIG_SANDBOX_SPI) += sandbox_spi.o
>  obj-$(CONFIG_SH_SPI) += sh_spi.o
>  obj-$(CONFIG_SH_QSPI) += sh_qspi.o
>  obj-$(CONFIG_STM32_QSPI) += stm32_qspi.o
> +obj-$(CONFIG_SUN4I_SPI) += sun4i_spi.o
>  obj-$(CONFIG_TEGRA114_SPI) += tegra114_spi.o
>  obj-$(CONFIG_TEGRA20_SFLASH) += tegra20_sflash.o
>  obj-$(CONFIG_TEGRA20_SLINK) += tegra20_slink.o
> diff --git a/drivers/spi/sun4i_spi.c b/drivers/spi/sun4i_spi.c
> new file mode 100644
> index 000..3ef1c68
> --- /dev/null
> +++ b/drivers/spi/sun4i_spi.c
> @@ -0,0 +1,423 @@
> +/*
> + * (C) Copyright 2017 Whitebox Systems / Northend Systems B.V.
> + * S.J.R. van Schaik 
> + * M.B.W. Wajer 
> + *
> + * (C) Copyright 2017 Olimex Ltd..
> + * Stefan Mavrodiev 
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define SUN4I_FIFO_DEPTH   64
> +
> +#define SUN4I_RXDATA_REG   0x00
> +
> +#define SUN4I_TXDATA_REG   0x04
> +
> +#define SUN4I_CTL_REG  0x08
> +#define SUN4I_CTL_ENABLE   BIT(0)
> +#define SUN4I_CTL_MASTER   BIT(1)
> +#define SUN4I_CTL_CPHA BIT(2)
> +#define SUN4I_CTL_CPOL BIT(3)
> +#define SUN4I_CTL_CS_ACTIVE_LOWBIT(4)
> +#define SUN4I_CTL_LMTF BIT(6)
> +#define SUN4I_CTL_TF_RST   BIT(8)
> +#define SUN4I_CTL_RF_RST   BIT(9)
> +#define SUN4I_CTL_XCH  BIT(10)
> +#define SUN4I_CTL_CS_MASK  0x3000
> +#define SUN4I_CTL_CS(cs)   (((cs) << 12) & SUN4I_CTL_CS_MASK)
> +#define SUN4I_CTL_DHB  BIT(15)
> +#define SUN4I_CTL_CS_MANUALBIT(16)
> +#define SUN4I_CTL_CS_LEVEL BIT(17)
> +#define SUN4I_CTL_TP   BIT(18)
> +
> +#define SUN4I_INT_CTL_REG  0x0c
> +#define SUN4I_INT_CTL_RF_F34   BIT(4)
> +#define SUN4I_INT_CTL_TF_E34   BIT(12)
> +#define SUN4I_INT_CTL_TC   BIT(16)
> +
> +#define SUN4I_INT_STA_REG  0x10
> +
> +#define SUN4I_DMA_CTL_REG  0x14
> +
> +#define SUN4I_WAIT_REG 0x18
> +
> +#define SUN4I_CLK_CTL_REG  0x1c
> +#define SUN4I_CLK_CTL_CDR2_MASK0xff
> +#define SUN4I_CLK_CTL_CDR2(div)((div) & 
> SUN4I_CLK_CTL_CDR2_MASK)
> +#define SUN4I_CLK_CTL_CDR1_MASK0xf
> +#define SUN4I_CLK_CTL_CDR1(div)(((div) & 
> SUN4I_CLK_CTL_CDR1_MASK) << 8)
> +#define SUN4I_CLK_CTL_DRS  BIT(12)
> +
> +#define SUN4I_MAX_XFER_SIZE0xff
> +
> +#define SUN4I_BURST_CNT_REG0x20
> +#define SUN4I_BURST_CNT(cnt)   ((cnt) & SUN4I_MAX_XFER_SIZE)
> +
> +#define SUN4I_XMIT_CNT_REG 0x24
> +#define SUN4I_XMIT_CNT(cnt)((cnt) & SUN4I_MAX_XFER_SIZE)
> +
> +#define SUN4I_FIFO_STA_REG 0x28
> +#define SUN4I_FIFO_STA_RF_CNT_MASK 0x7f
> +#define SUN4I_FIFO_STA_RF_CNT_BITS 0
> +#define SUN4I_FIFO_STA_TF_CNT_MASK 0x7f
> +#define SUN4I_FIFO_STA_TF_CNT_BITS 16
> +
> +#define SUN4I_SPI_MAX_RATE 2400
>

[U-Boot] [PATCH 2/3] ARM: uniphier: compute SSCPLL values more precisely

2017-12-05 Thread Masahiro Yamada 
Use DIV_ROUND_CLOSEST().  To make the JK value even more precise,
I used a bigger coefficient, then divide it by 512.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/clk/pll-base-ld20.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-uniphier/clk/pll-base-ld20.c 
b/arch/arm/mach-uniphier/clk/pll-base-ld20.c
index 45fdf0a..c9b78b9 100644
--- a/arch/arm/mach-uniphier/clk/pll-base-ld20.c
+++ b/arch/arm/mach-uniphier/clk/pll-base-ld20.c
@@ -7,6 +7,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -41,13 +42,14 @@ int uniphier_ld20_sscpll_init(unsigned long reg_base, 
unsigned int freq,
if (freq != UNIPHIER_PLL_FREQ_DEFAULT) {
tmp = readl(base);  /* SSCPLLCTRL */
tmp &= ~SC_PLLCTRL_SSC_DK_MASK;
-   tmp |= (487 * freq * ssc_rate / divn / 512) &
+   tmp |= DIV_ROUND_CLOSEST(487UL * freq * ssc_rate, divn * 512) &
SC_PLLCTRL_SSC_DK_MASK;
writel(tmp, base);
 
tmp = readl(base + 4);
tmp &= ~SC_PLLCTRL2_SSC_JK_MASK;
-   tmp |= (41859 * freq / divn) & SC_PLLCTRL2_SSC_JK_MASK;
+   tmp |= DIV_ROUND_CLOSEST(21431887UL * freq, divn * 512) &
+   SC_PLLCTRL2_SSC_JK_MASK;
writel(tmp, base + 4);
 
udelay(50);
-- 
2.7.4

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

[U-Boot] [PATCH 3/3] ARM: uniphier: use FIELD_PREP for PLL settings

2017-12-05 Thread Masahiro Yamada 
It is tedious to define both mask and bit-shift.  
provides a convenient way to get access to register fields with a
single shifted mask.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/clk/pll-base-ld20.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-uniphier/clk/pll-base-ld20.c 
b/arch/arm/mach-uniphier/clk/pll-base-ld20.c
index c9b78b9..385f54d 100644
--- a/arch/arm/mach-uniphier/clk/pll-base-ld20.c
+++ b/arch/arm/mach-uniphier/clk/pll-base-ld20.c
@@ -5,6 +5,7 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -19,7 +20,6 @@
 #define SC_PLLCTRL_SSC_EN  BIT(31)
 #define SC_PLLCTRL2_NRSTDS BIT(28)
 #define SC_PLLCTRL2_SSC_JK_MASKGENMASK(26, 0)
-#define SC_PLLCTRL3_REGI_SHIFT 16
 #define SC_PLLCTRL3_REGI_MASK  GENMASK(19, 16)
 
 /* PLL type: VPLL27 */
@@ -42,14 +42,16 @@ int uniphier_ld20_sscpll_init(unsigned long reg_base, 
unsigned int freq,
if (freq != UNIPHIER_PLL_FREQ_DEFAULT) {
tmp = readl(base);  /* SSCPLLCTRL */
tmp &= ~SC_PLLCTRL_SSC_DK_MASK;
-   tmp |= DIV_ROUND_CLOSEST(487UL * freq * ssc_rate, divn * 512) &
-   SC_PLLCTRL_SSC_DK_MASK;
+   tmp |= FIELD_PREP(SC_PLLCTRL_SSC_DK_MASK,
+ DIV_ROUND_CLOSEST(487UL * freq * ssc_rate,
+   divn * 512));
writel(tmp, base);
 
tmp = readl(base + 4);
tmp &= ~SC_PLLCTRL2_SSC_JK_MASK;
-   tmp |= DIV_ROUND_CLOSEST(21431887UL * freq, divn * 512) &
-   SC_PLLCTRL2_SSC_JK_MASK;
+   tmp |= FIELD_PREP(SC_PLLCTRL2_SSC_JK_MASK,
+ DIV_ROUND_CLOSEST(21431887UL * freq,
+   divn * 512));
writel(tmp, base + 4);
 
udelay(50);
@@ -93,7 +95,7 @@ int uniphier_ld20_sscpll_set_regi(unsigned long reg_base, 
unsigned regi)
 
tmp = readl(base + 8);  /* SSCPLLCTRL3 */
tmp &= ~SC_PLLCTRL3_REGI_MASK;
-   tmp |= regi << SC_PLLCTRL3_REGI_SHIFT;
+   tmp |= FIELD_PREP(SC_PLLCTRL3_REGI_MASK, regi);
writel(tmp, base + 8);
 
iounmap(base);
-- 
2.7.4

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

[U-Boot] [PATCH 1/3] ARM: uniphier: fix SSCPLL init code for LD11 SoC

2017-12-05 Thread Masahiro Yamada 
From: Dai Okamura 

Commit 682e09ff9f35 ("ARM: uniphier: add PLL init code for LD20 SoC")
missed to write the computed value to the SSCPLLCTRL2 register.

Fixes: 682e09ff9f35 ("ARM: uniphier: add PLL init code for LD20 SoC")
Signed-off-by: Dai Okamura 
Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/clk/pll-base-ld20.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-uniphier/clk/pll-base-ld20.c 
b/arch/arm/mach-uniphier/clk/pll-base-ld20.c
index 3aa42f8..45fdf0a 100644
--- a/arch/arm/mach-uniphier/clk/pll-base-ld20.c
+++ b/arch/arm/mach-uniphier/clk/pll-base-ld20.c
@@ -48,6 +48,7 @@ int uniphier_ld20_sscpll_init(unsigned long reg_base, 
unsigned int freq,
tmp = readl(base + 4);
tmp &= ~SC_PLLCTRL2_SSC_JK_MASK;
tmp |= (41859 * freq / divn) & SC_PLLCTRL2_SSC_JK_MASK;
+   writel(tmp, base + 4);
 
udelay(50);
}
-- 
2.7.4

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

[U-Boot] [PATCH] mtd: nand: denali: make NAND_DENALI unconfigurable option

2017-12-05 Thread Masahiro Yamada 
denali.c has no driver entry in itself.  It makes sense only when
compiled together with denali_dt.c

Let NAND_DENALI_DT select NAND_DENALI, and hide NAND_DENALI from
the Kconfig menu.

Signed-off-by: Masahiro Yamada 
---

 drivers/mtd/nand/Kconfig | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 47ec435..78a39ab 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -10,15 +10,14 @@ config SYS_NAND_SELF_INIT
  NAND initialization process.
 
 config NAND_DENALI
-   bool "Support Denali NAND controller"
+   bool
select SYS_NAND_SELF_INIT
imply CMD_NAND
-   help
- Enable support for the Denali NAND controller.
 
 config NAND_DENALI_DT
bool "Support Denali NAND controller as a DT device"
-   depends on NAND_DENALI && OF_CONTROL && DM
+   select NAND_DENALI
+   depends on OF_CONTROL && DM
help
  Enable the driver for NAND flash on platforms using a Denali NAND
  controller as a DT device.
-- 
2.7.4

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

[U-Boot] [PATCH] ARM: uniphier: link pll-base-ld20.o for PXs3

2017-12-05 Thread Masahiro Yamada 
Fix the link error for the combination of
  CONFIG_ARCH_UNIPHIER_LD11=n
  CONFIG_ARCH_UNIPHIER_LD20=n
  CONFIG_ARCH_UNIPHIER_PXS3=y

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/clk/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-uniphier/clk/Makefile 
b/arch/arm/mach-uniphier/clk/Makefile
index 76633bc..5cd0897 100644
--- a/arch/arm/mach-uniphier/clk/Makefile
+++ b/arch/arm/mach-uniphier/clk/Makefile
@@ -27,3 +27,4 @@ endif
 
 obj-$(CONFIG_ARCH_UNIPHIER_LD11)   += pll-base-ld20.o
 obj-$(CONFIG_ARCH_UNIPHIER_LD20)   += pll-base-ld20.o
+obj-$(CONFIG_ARCH_UNIPHIER_PXS3)   += pll-base-ld20.o
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 2/5] net: sun8i_emac: Support RX/TX delay chains

2017-12-05 Thread Chen-Yu Tsai 
On Wed, Dec 6, 2017 at 4:50 AM, Joe Hershberger  wrote:
> On Fri, Nov 24, 2017 at 11:08 PM, Chen-Yu Tsai  wrote:
>> The EMAC syscon has configurable RX/TX delay chains for use with RGMII
>> PHYs.
>>
>> This adds support for configuring them via device tree properties. The
>> property names and format were defined in Linux's dwmac-sun8i binding
>> that was merged at one point.
>
> I'm not seeing this in doc/device-tree-bindings/net/

See 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/dwmac-sun8i.txt

The bindings have been restored as of v4.15-rc1.

We are following DT bindings as defined in the Linux kernel. Deviation
is kept to a minimum, and eliminated if possible. We still need to
migrate the driver to the new bindings for the internal PHY bits.
But that bit might still be changed during the 4.15 release cycle.

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

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

2017-12-05 Thread André Przywara 
Hi,

On 05/12/17 15:56, 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 

Reviewed-by: Andre Przywara 

Thanks!
Andre.

> ---
>  include/configs/sunxi-common.h | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 4391a8cbc824..786155f1e15e 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -493,6 +493,20 @@ extern int soft_i2c_gpio_scl;
>  #define SUNXI_MTDPARTS_DEFAULT
>  #endif
>  
> +#define PARTS_DEFAULT \
> + "name=loader1,start=8k,size=32k,uuid=${uuid_gpt_loader1};" \
> + "name=loader2,size=984k,uuid=${uuid_gpt_loader2};" \
> + "name=esp,size=128M,bootable,uuid=${uuid_gpt_esp};" \
> + "name=system,size=-,uuid=${uuid_gpt_system};"
> +
> +#define UUID_GPT_ESP "c12a7328-f81f-11d2-ba4b-00a0c93ec93b"
> +
> +#ifdef CONFIG_ARM64
> +#define UUID_GPT_SYSTEM "b921b045-1df0-41c3-af44-4c6f280d3fae"
> +#else
> +#define UUID_GPT_SYSTEM "69dad710-2ce4-4e3c-b16c-21a1d49abed3"
> +#endif
> +
>  #define CONSOLE_ENV_SETTINGS \
>   CONSOLE_STDIN_SETTINGS \
>   CONSOLE_STDOUT_SETTINGS
> @@ -511,6 +525,9 @@ extern int soft_i2c_gpio_scl;
>   "console=ttyS0,115200\0" \
>   SUNXI_MTDIDS_DEFAULT \
>   SUNXI_MTDPARTS_DEFAULT \
> + "uuid_gpt_esp=" UUID_GPT_ESP "\0" \
> + "uuid_gpt_system=" UUID_GPT_SYSTEM "\0" \
> + "partitions=" PARTS_DEFAULT "\0" \
>   BOOTCMD_SUNXI_COMPAT \
>   BOOTENV
>  
> 

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

[U-Boot] [PULL] efi patch queue 2017-12-05

2017-12-05 Thread Alexander Graf 
Hi Tom,

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

Alex


The following changes since commit 9804d88630cdb22f5f0ace05ac05942928410fd9:

  Merge branch 'rmobile-mx' of git://git.denx.de/u-boot-sh (2017-11-30 10:39:04 
-0500)

are available in the git repository at:

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

for you to fetch changes up to bb0bb91cf0aa2c13528fe39be2006f32f7b9c437:

  efi_stub: Use efi_uintn_t (2017-12-05 22:56:17 +0100)


Patch queue for efi - 2017-12-05

Highlights for this release:

  - Dynamic EFI object creation (lists instead of static arrays)
  - EFI selftest improvements
  - Minor fixes


Alexander Graf (3):
  efi_loader: Fix partition offsets
  efi_loader helloworld.efi: Fix building with -Os
  efi_stub: Use efi_uintn_t

Heinrich Schuchardt (64):
  efi_loader: move efi_search_obj up in code
  efi_loader: implement SetWatchdogTimer
  efi_selftest: provide test for watchdog timer
  efi_loader: new function utf8_to_utf16
  efi_loader: guard against double inclusion of efi_loader.h
  efi_loader: consistently use efi_status_t in bootefi
  efi_selftest: provide a dummy device path
  efi_selftest: reformat code
  efi_selftest: efi_st_memcmp should return 0
  efi_selftest: deduplicate code
  efi_selftest: allow to select a single test for execution
  efi_selftest: correctly cleanup after selftest
  efi_loader: use bootargs as load options
  efi_selftest: test reboot by watchdog
  test/py: test reboot by EFI watchdog
  test/py: fix typo in test_efi_loader.py
  efi_selftest: provide test for EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL
  efi_loader: set parent handle in efi_load_image
  efi_loader: capitalize EFI_LOCATE_SEARCH_TYPE values
  efi_selftest: test protocol management
  efi_loader: eliminate efi_install_protocol_interface_ext
  efi_loader: eliminate efi_uninstall_protocol_interface_ext
  efi_loader: remove unused typedef for INTN
  efi_loader: replace UINTN by efi_uintn_t
  efi_loader: consistently use efi_uintn_t in boot services
  efi_loader: rework efi_locate_handle
  efi_loader: rework efi_search_obj
  efi_loader: fix typo efi_install_multiple_protocol_interfaces
  efi_loader: debug output efi_install_protocol_interface
  efi_loader implement UninstallMultipleProtocolInterfaces
  efi_loader: efi_gop: check calloc return value
  efi_loader: efi_disk: check return value of calloc
  efi_loader: efi_net: check return value of calloc
  efi_loader: efi_dp_match should have const arguments
  efi_loader: make efi_create_handle non-static
  efi_loader: argument of efi_search_obj should be const
  efi_loader: efi_gop: use correct types for parameters
  efi_selftest: test for graphics output protocol
  efi_loader: helper functions for protocol management
  efi_loader: simplify efi_install_protocol_interface
  efi_loader: simplify efi_search
  efi_loader: simplify efi_uninstall_protocol_interface
  efi_loader: simplify efi_locate_protocol
  efi_loader: refactor efi_setup_loaded_image
  efi_loader: efi_console: use helper functions
  efi_loader: helloworld.c: remove superfluous include
  efi_loader: size of media device path node represenation
  efi_loader: efi_dp_str should print path not node
  efi_loader: fix efi_convert_device_node_to_text
  efi_loader: reimplement LocateDevicePath
  efi_selftest: test EFI_DEVICE_PATH_TO_TEXT_PROTOCOL
  efi_loader: efi_disk: use efi_add_protocol
  efi_loader: efi_net: use efi_add_protocol
  efi_loader: efi_gop: use efi_add_protocol
  efi_loader: simplify efi_open_protocol
  efi_loader: simplify find_obj
  efi_loader: manage protocols in a linked list
  efi_selftest: compile without special compiler flags
  efi_selftest: add missing line feed
  efi_loader: output load options in helloworld
  test/py: check return code of helloworld
  efi_loader: pass handle of loaded image
  efi_loader: helper function to add EFI object to list
  efi_loader: comments for EFI_DEVICE_PATH_TO_TEXT_PROTOCOL

Jonathan Gray (1):
  efi_loader: initialise partition_signature memory

Rob Clark (1):
  efi_loader: add missing breaks

Stefan Roese (1):
  efi_loader: Exit in efi_set_bootdev() upon invalid "desc"

 cmd/bootefi.c   |  73 ++-
 include/charset.h   |  15 +
 include/efi.h   |   6 +-
 include/efi_api.h   |  48 +-
 include/efi_loader.h|  66 +-
 include/efi_selftest.h  |  21 +
 lib/charset.c   |  57 +-
 lib/efi/efi_stub.c  |   2 +-

Re: [U-Boot] [PATCH 4/9] board: freescale: ls1012a: enable network support on ls1012a platforms

2017-12-05 Thread Joe Hershberger 
On Mon, Oct 9, 2017 at 4:11 AM, Calvin Johnson  wrote:
> Ethernet support on all three LS1012A platforms(FRDM, QDS and RDB) is
> enabled with this patch.
>
> eth.c files for all 3 platforms contain board ethernet initialization
> function and also function to reset phy.
>
> Signed-off-by: Calvin Johnson 
> Signed-off-by: Anjaneyulu Jagarlmudi 
> ---
>  board/freescale/ls1012afrdm/Makefile  |   1 +
>  board/freescale/ls1012afrdm/eth.c |  86 +
>  board/freescale/ls1012afrdm/ls1012afrdm.c |   5 -
>  board/freescale/ls1012aqds/Makefile   |   1 +
>  board/freescale/ls1012aqds/eth.c  | 263 
> ++
>  board/freescale/ls1012aqds/ls1012aqds.c   |  97 +-
>  board/freescale/ls1012aqds/ls1012aqds_pfe.h   |  48 +
>  board/freescale/ls1012aqds/ls1012aqds_qixis.h |   2 +-
>  board/freescale/ls1012ardb/Makefile   |   1 +
>  board/freescale/ls1012ardb/eth.c  |  70 +++
>  board/freescale/ls1012ardb/ls1012ardb.c   |   4 -
>  include/configs/ls1012ardb.h  |   5 +
>  12 files changed, 568 insertions(+), 15 deletions(-)
>  create mode 100644 board/freescale/ls1012afrdm/eth.c
>  create mode 100644 board/freescale/ls1012aqds/eth.c
>  create mode 100644 board/freescale/ls1012aqds/ls1012aqds_pfe.h
>  create mode 100644 board/freescale/ls1012ardb/eth.c

It seems reasonable to add support for each platform in individual patches.

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

Re: [U-Boot] [PATCH 3/9] drivers: net: pfe_eth: LS1012A PFE headers

2017-12-05 Thread Joe Hershberger 
On Mon, Oct 9, 2017 at 4:11 AM, Calvin Johnson  wrote:
> Contains all the pfe header files.
>
> Signed-off-by: Calvin Johnson 
> Signed-off-by: Anjaneyulu Jagarlmudi 
> ---
>  include/pfe_eth/pfe/cbus.h   |  75 +++
>  include/pfe_eth/pfe/cbus/bmu.h   |  40 
>  include/pfe_eth/pfe/cbus/class_csr.h | 181 
> +++
>  include/pfe_eth/pfe/cbus/emac.h  | 150 +
>  include/pfe_eth/pfe/cbus/gpi.h   |  62 
>  include/pfe_eth/pfe/cbus/hif.h   |  68 +
>  include/pfe_eth/pfe/cbus/hif_nocpy.h |  40 
>  include/pfe_eth/pfe/cbus/tmu_csr.h   | 148 
>  include/pfe_eth/pfe/cbus/util_csr.h  |  47 +
>  include/pfe_eth/pfe/pfe.h| 178 ++
>  include/pfe_eth/pfe_driver.h |  55 +++
>  include/pfe_eth/pfe_eth.h| 111 +
>  include/pfe_eth/pfe_firmware.h   |  17 
>  13 files changed, 1172 insertions(+)
>  create mode 100644 include/pfe_eth/pfe/cbus.h
>  create mode 100644 include/pfe_eth/pfe/cbus/bmu.h
>  create mode 100644 include/pfe_eth/pfe/cbus/class_csr.h
>  create mode 100644 include/pfe_eth/pfe/cbus/emac.h
>  create mode 100644 include/pfe_eth/pfe/cbus/gpi.h
>  create mode 100644 include/pfe_eth/pfe/cbus/hif.h
>  create mode 100644 include/pfe_eth/pfe/cbus/hif_nocpy.h
>  create mode 100644 include/pfe_eth/pfe/cbus/tmu_csr.h
>  create mode 100644 include/pfe_eth/pfe/cbus/util_csr.h
>  create mode 100644 include/pfe_eth/pfe/pfe.h
>  create mode 100644 include/pfe_eth/pfe_driver.h
>  create mode 100644 include/pfe_eth/pfe_eth.h
>  create mode 100644 include/pfe_eth/pfe_firmware.h
>
> diff --git a/include/pfe_eth/pfe/cbus.h b/include/pfe_eth/pfe/cbus.h
> new file mode 100644
> index 000..ec31481
> --- /dev/null
> +++ b/include/pfe_eth/pfe/cbus.h
> @@ -0,0 +1,75 @@
> +/*
> + * Copyright 2015-2016 Freescale Semiconductor, Inc.
> + * Copyright 2017 NXP
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +
> +#ifndef _CBUS_H_
> +#define _CBUS_H_
> +
> +#include "cbus/emac.h"
> +#include "cbus/gpi.h"
> +#include "cbus/bmu.h"
> +#include "cbus/hif.h"
> +#include "cbus/tmu_csr.h"
> +#include "cbus/class_csr.h"
> +#include "cbus/hif_nocpy.h"
> +#include "cbus/util_csr.h"
> +
> +#define CBUS_BASE_ADDR ((void *)CONFIG_SYS_FSL_PFE_ADDR)
> +
> +/* PFE Control and Status Register Desciption */
> +#define EMAC1_BASE_ADDR(CBUS_BASE_ADDR + 0x20)
> +#define EGPI1_BASE_ADDR(CBUS_BASE_ADDR + 0x21)
> +#define EMAC2_BASE_ADDR(CBUS_BASE_ADDR + 0x22)
> +#define EGPI2_BASE_ADDR(CBUS_BASE_ADDR + 0x23)
> +#define BMU1_BASE_ADDR (CBUS_BASE_ADDR + 0x24)
> +#define BMU2_BASE_ADDR (CBUS_BASE_ADDR + 0x25)
> +#define ARB_BASE_ADDR  (CBUS_BASE_ADDR + 0x26)
> +#define DDR_CONFIG_BASE_ADDR   (CBUS_BASE_ADDR + 0x27)
> +#define HIF_BASE_ADDR  (CBUS_BASE_ADDR + 0x28)
> +#define HGPI_BASE_ADDR (CBUS_BASE_ADDR + 0x29)
> +#define LMEM_BASE_ADDR (CBUS_BASE_ADDR + 0x30)
> +#define LMEM_SIZE  0x1
> +#define LMEM_END   (LMEM_BASE_ADDR + LMEM_SIZE)
> +#define TMU_CSR_BASE_ADDR  (CBUS_BASE_ADDR + 0x31)
> +#define CLASS_CSR_BASE_ADDR(CBUS_BASE_ADDR + 0x32)
> +#define HIF_NOCPY_BASE_ADDR(CBUS_BASE_ADDR + 0x35)
> +#define UTIL_CSR_BASE_ADDR (CBUS_BASE_ADDR + 0x36)
> +#define CBUS_GPT_BASE_ADDR (CBUS_BASE_ADDR + 0x37)
> +
> +/*
> + * defgroup XXX_MEM_ACCESS_ADDR PE memory access through CSR
> + * XXX_MEM_ACCESS_ADDR register bit definitions.
> + */
> +/* Internal Memory Write. */
> +#define PE_MEM_ACCESS_WRITE(1<<31)
> +/* Internal Memory Read. */
> +#define PE_MEM_ACCESS_READ (0<<31)
> +
> +#define PE_MEM_ACCESS_IMEM (1<<15)
> +#define PE_MEM_ACCESS_DMEM (1<<16)

Please use the BIT() macro for this sort of define.

> +/* Byte Enables of the Internal memory access. These are interpred in BE */
> +#define PE_MEM_ACCESS_BYTE_ENABLE(offset, size)(1 << (size)) - 
> 1) << (4 \
> +   - (offset) - (size)))\
> +   & 0xf) << 24)

This is pretty unreadable. If you can improve it, please do.

> +/* PFE cores states */
> +#define CORE_DISABLE   0x
> +#define CORE_ENABLE0x0001
> +#define CORE_SW_RESET  0x0002
> +
> +/* LMEM defines */
> +#define LMEM_HDR_SIZE  0x0010
> +#define LMEM_BUF_SIZE_LN2  0x7
> +#define LMEM_BUF_SIZE  (1 << LMEM_BUF_SIZE_LN2)
> +
> +/* DDR defines */
> +#define DDR_HDR_SIZE   0x0100
> +#define DDR_BUF_SIZE_LN2   0xb
> +#define DDR_BUF_SIZE   (1 << DDR_BUF_SIZE_LN2)
> +
> +/*

Re: [U-Boot] [PATCH v2 03/16] efi: Add error checking for efi_init_obj_list()

2017-12-05 Thread Simon Glass 
Hi Heinrich,

On 4 December 2017 at 15:21, Heinrich Schuchardt  wrote:
>
>
> On 12/04/2017 10:28 PM, Simon Glass wrote:
>>
>> This function calls a function which can fail. Print a message in this
>> case and abort the boot, rather than silently continuing to boot, which
>> will certainly fail.
>>
>> Signed-off-by: Simon Glass 
>> ---
>>
>> Changes in v2:
>> - Change return type of efi_init_obj_list() to efi_status_t
>>
>>   cmd/bootefi.c | 32 +---
>>   1 file changed, 25 insertions(+), 7 deletions(-)
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index 17b26e6f4e..a2138f6075 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -25,11 +25,17 @@ static uint8_t efi_obj_list_initalized;
>>   static struct efi_device_path *bootefi_image_path;
>>   static struct efi_device_path *bootefi_device_path;
>>   -/* Initialize and populate EFI object list */
>> -static void efi_init_obj_list(void)
>> +/**
>> + * efi_init_obj_list() - Initialize and populate EFI object list
>> + *
>> + * @return 0 if OK, -ve on error (in which case it prints a message)
>> + */
>> +static efi_status_t efi_init_obj_list(void)
>>   {
>> +   efi_status_t ret;
>> +
>> if (efi_obj_list_initalized)
>> -   return;
>> +   return 0;
>> efi_obj_list_initalized = 1;
>> efi_console_register();
>> @@ -43,12 +49,19 @@ static void efi_init_obj_list(void)
>> efi_net_register();
>
>
> This function can also fail. Same is true for efi_gop_register.
>
>>   #endif
>>   #ifdef CONFIG_GENERATE_SMBIOS_TABLE
>> -   efi_smbios_register();
>> +   ret = efi_smbios_register();
>> +   if (ret)
>
>
> if (ret != EFI_SUCCESS)
>

Please can we avoid this obfuscation? It really pains me to see what I
consider to be stupidity in the code. Can we just agree that success
is 0 in U-Boot/?

>> +   goto error;
>>   #endif
>> /* Initialize EFI runtime services */
>> efi_reset_system_init();
>> efi_get_time_init();
>> +
>> +   return EFI_SUCCESS;
>> +error:
>> +   printf("Error: Cannot set up EFI object list (err=%d)\n", ret);
>
>
> Now we have some objects initialized and others not.
> Before returning we should clean up.
> We should free all allocated objects.

OK let me take another look at this.

>
> Best regards
>
> Heinrich
>
>
>> +   return ret;
>>   }
>> static void *copy_fdt(void *fdt)
>> @@ -137,6 +150,7 @@ static unsigned long do_bootefi_exec(void *efi, void
>> *fdt,
>> ulong fdt_pages, fdt_size, fdt_start, fdt_end;
>> const efi_guid_t fdt_guid = EFI_FDT_GUID;
>> bootm_headers_t img = { 0 };
>> +   int ret;
>> /*
>>  * Special case for efi payload not loaded from disk, such as
>> @@ -211,7 +225,9 @@ static unsigned long do_bootefi_exec(void *efi, void
>> *fdt,
>> "{ro,boot}(blob)");
>> /* Initialize and populate EFI object list */
>> -   efi_init_obj_list();
>> +   ret = efi_init_obj_list();
>> +   if (ret)
>> +   return ret;
>> /* Call our payload! */
>> debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__,
>> (long)entry);
>> @@ -313,10 +329,12 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag,
>> int argc, char * const argv[])
>>  */
>> efi_save_gd();
>> /* Initialize and populate EFI object list */
>> -   if (!efi_obj_list_initalized)
>> -   efi_init_obj_list();
>> +   if (!efi_obj_list_initalized && efi_init_obj_list())
>> +   return CMD_RET_FAILURE;
>> +
>> loaded_image_info.device_handle = bootefi_device_path;
>> loaded_image_info.file_path = bootefi_image_path;
>> +
>> return efi_selftest(_image_info, );
>> } else
>>   #endif
>>
>


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

Re: [U-Boot] [PATCH v2 05/16] efi: Correct header order in efi_memory

2017-12-05 Thread Simon Glass 
Hi Heinrich,

On 4 December 2017 at 15:28, Heinrich Schuchardt  wrote:
>
>
> On 12/04/2017 10:28 PM, Simon Glass wrote:
>>
>> The headers are not in the correct order. Fix this. Also drop libfdt_env.h
>> since it is not needed.
>
>
> What do you consider as correct order? Do you mean sorted alphabetically?
> Includes should be self sufficient and the correct execution be independent
> of the sequence.

https://www.denx.de/wiki/U-Boot/CodingStyle

If we need libfdt we should include libfdt.h I think.

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

Re: [U-Boot] [PATCH 0/3] ls1012a: fix tftp failure

2017-12-05 Thread Joe Hershberger 
On Tue, Dec 5, 2017 at 2:57 PM, York Sun  wrote:
> On 12/05/2017 12:50 PM, Joe Hershberger wrote:
>> On Wed, Nov 22, 2017 at 7:17 PM, Calvin Johnson  
>> wrote:
>>> Hi York,
>>>
 -Original Message-
 From: York Sun
 Sent: Thursday, November 23, 2017 12:00 AM
 To: Calvin Johnson ; u-boot@lists.denx.de
 Cc: Anji Jagarlmudi ; Joe Hershberger
 ; Prabhakar Kushwaha
 
 Subject: Re: [PATCH 0/3] ls1012a: fix tftp failure

 On 11/21/2017 10:26 PM, Calvin Johnson wrote:
> This patch series fixes bug which fails tftp sometimes
> while using the pfe interfaces and also has some code clean up.
>
>
> Calvin Johnson (3):
>   drivers: net: pfe_eth: add pfe_rx_done to clear bd after packet
> processing
>   drivers: net: pfe_eth: use writel/readl to access hw bds
>   drivers: net: pfe_eth: cleanup typos and indent
>
>  drivers/net/pfe_eth/pfe_driver.c | 126 +++-
 ---
>  drivers/net/pfe_eth/pfe_eth.c|  13 ++--
>  include/pfe_eth/pfe_driver.h |   1 +
>  3 files changed, 82 insertions(+), 58 deletions(-)
>

 Your PFE patch set is not fully reviewed or accepted. If I were you, I
 would probably send v2 version to include all the changes.

 It is up to Joe to decide to take a new version, or patches on top of
 patches.
>>
>> It's assigned to York in patchwork. would you prefer I take them?
>>
>
> Yes, please.
> I also advised Calvin to squash his patches into one set, instead of
> patching the patches.

Ah - I didn't realize this wasn't already in. I see that now.

Yes, I'll review those patches and they should be squashed and resent.

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

[U-Boot] E-Mail Failure

2017-12-05 Thread Joe Hershberger 
Hi All,

All emails I have sent to the list since Oct 2 or so were being
silently dropped. I believe I resent all of the emails that were lost.
I apologize for seeming to ignore people. If you still haven't seen a
response to something you are waiting on, please send again.

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

Re: [U-Boot] [PATCH 0/3] ls1012a: fix tftp failure

2017-12-05 Thread York Sun 
On 12/05/2017 12:50 PM, Joe Hershberger wrote:
> On Wed, Nov 22, 2017 at 7:17 PM, Calvin Johnson  
> wrote:
>> Hi York,
>>
>>> -Original Message-
>>> From: York Sun
>>> Sent: Thursday, November 23, 2017 12:00 AM
>>> To: Calvin Johnson ; u-boot@lists.denx.de
>>> Cc: Anji Jagarlmudi ; Joe Hershberger
>>> ; Prabhakar Kushwaha
>>> 
>>> Subject: Re: [PATCH 0/3] ls1012a: fix tftp failure
>>>
>>> On 11/21/2017 10:26 PM, Calvin Johnson wrote:
 This patch series fixes bug which fails tftp sometimes
 while using the pfe interfaces and also has some code clean up.


 Calvin Johnson (3):
   drivers: net: pfe_eth: add pfe_rx_done to clear bd after packet
 processing
   drivers: net: pfe_eth: use writel/readl to access hw bds
   drivers: net: pfe_eth: cleanup typos and indent

  drivers/net/pfe_eth/pfe_driver.c | 126 +++-
>>> ---
  drivers/net/pfe_eth/pfe_eth.c|  13 ++--
  include/pfe_eth/pfe_driver.h |   1 +
  3 files changed, 82 insertions(+), 58 deletions(-)

>>>
>>> Your PFE patch set is not fully reviewed or accepted. If I were you, I
>>> would probably send v2 version to include all the changes.
>>>
>>> It is up to Joe to decide to take a new version, or patches on top of
>>> patches.
> 
> It's assigned to York in patchwork. would you prefer I take them?
>

Yes, please.
I also advised Calvin to squash his patches into one set, instead of
patching the patches.

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

Re: [U-Boot] [PATCH v2 3/3] net: miiphybb: fix casting error

2017-12-05 Thread Joe Hershberger 
On Fri, Nov 3, 2017 at 8:30 AM, Chris Brandt  wrote:
> Since the return value is a signed int, if the leading MSB of rdreg is a 1,
> it will get signed extended and will return a negative value which is an
> error even though we read the correct value.
>
> Fixes: dfcc496ed7e2 ("net: mii: Changes not made by spatch")
> Signed-off-by: Chris Brandt 

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

Re: [U-Boot] [PATCH] net: ravb: Fix reset GPIO handling

2017-12-05 Thread Joe Hershberger 
On Tue, Nov 28, 2017 at 8:49 PM, Marek Vasut  wrote:
> Fix handling of the reset GPIO. Drop the _nodev() suffix from the
> gpio_request_by_name() call as there is now a proper DM capable
> GPIO driver. Also check if the GPIO is valid before freeing it in
> remove path, otherwise U-Boot will crash.
>
> Signed-off-by: Marek Vasut 
> Cc: Joe Hershberger 
> Cc: Nobuhiro Iwamatsu 

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

Re: [U-Boot] [PATCH v2 1/5] bitfield: Include linux/bitops.h for ffs()

2017-12-05 Thread Joe Hershberger 
On Fri, Nov 24, 2017 at 11:08 PM, Chen-Yu Tsai  wrote:
> bitfield_shift() uses the ffs() function, which is provided by bitops.h.
>
> Explicitly include this header.
>
> Signed-off-by: Chen-Yu Tsai 

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

Re: [U-Boot] [PATCH v2 2/3] net: sh-eth: remove sh_eth_offset_rz table

2017-12-05 Thread Joe Hershberger 
On Fri, Nov 3, 2017 at 8:30 AM, Chris Brandt  wrote:
> First, this table could never be included in the build anyway because
> SH_ETH_TYPE_RZ is not defined until later in the file.
> Second, the register PIR was missing, so PHY MDIO never worked.
> Third, after adding the PIR register, the table is EXACTLY the same as
> sh_eth_offset_gigabit, so there is no value to it.
>
> Therefore, just delete it use the gigabit one.
>
> Signed-off-by: Chris Brandt 

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

Re: [U-Boot] [PATCH v2 1/3] net: sh-eth: fix inl and outl definitions

2017-12-05 Thread Joe Hershberger 
On Fri, Nov 3, 2017 at 8:30 AM, Chris Brandt  wrote:
> The macros inl and outl maybe already be defined from file
> arch/arm/include/asm/io.h so there may be no reason to define them.
> And if you do try defined them here, you get a redefined complier warning.
>
> Signed-off-by: Chris Brandt 

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

Re: [U-Boot] [PATCH 02/16] net: e1000: add support for writing to EEPROM

2017-12-05 Thread Joe Hershberger 
On Wed, Nov 8, 2017 at 9:59 AM, Martyn Welch
 wrote:
> From: Hannu Lounento 
>
> Port functions for writing to EEPROM, updating the checksum and
> committing data to flash from the Linux kernel igb driver.
>
> Functions were ported from Linux 4.8-rc2 (694d0d0bb20).
>
> Signed-off-by: Hannu Lounento 
> CC: Joe Hershberger 
> Signed-off-by: Martyn Welch 

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

Re: [U-Boot] [PATCH v2 0/5] sunxi: Enable EMAC on various boards

2017-12-05 Thread Joe Hershberger 
On Tue, Dec 5, 2017 at 7:07 AM, Chen-Yu Tsai  wrote:
> Hi,
>
> On Sat, Nov 25, 2017 at 1:08 PM, Chen-Yu Tsai  wrote:
>> Hi,
>>
>> This series enables the EMAC for some A83T and A64 boards.
>>
>> Changes since v1:
>>
>>   - Added "bitfield: Include linux/bitops.h for ffs()" to fix build
>> errors
>>   - Use bitfield_replace_by_mask() instead of open coding bitfield ops
>>   - Trimmed used pins in the device tree to only those actually needed
>>   - Enabled Realtek PHY driver
>>   - Added "sunxi: Enable EMAC on the Bananapi M64"
>>
>> ChenYu
>>
>>
>> Chen-Yu Tsai (5):
>>   bitfield: Include linux/bitops.h for ffs()
>>   net: sun8i_emac: Support RX/TX delay chains
>>   sunxi: Enable EMAC on the Cubietruck Plus
>>   sunxi: Enable EMAC on the Bananapi M3
>>   sunxi: Enable EMAC on the Bananapi M64
>
> Any comments (particularly two the first two patches) on this series?
> Joe?

I sent an issue with net: sun8i_emac: Support RX/TX delay chains

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

Re: [U-Boot] [PATCH v2 2/5] net: sun8i_emac: Support RX/TX delay chains

2017-12-05 Thread Joe Hershberger 
On Fri, Nov 24, 2017 at 11:08 PM, Chen-Yu Tsai  wrote:
> The EMAC syscon has configurable RX/TX delay chains for use with RGMII
> PHYs.
>
> This adds support for configuring them via device tree properties. The
> property names and format were defined in Linux's dwmac-sun8i binding
> that was merged at one point.

I'm not seeing this in doc/device-tree-bindings/net/
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] ls1012a: fix tftp failure

2017-12-05 Thread Joe Hershberger 
On Wed, Nov 22, 2017 at 7:17 PM, Calvin Johnson  wrote:
> Hi York,
>
>> -Original Message-
>> From: York Sun
>> Sent: Thursday, November 23, 2017 12:00 AM
>> To: Calvin Johnson ; u-boot@lists.denx.de
>> Cc: Anji Jagarlmudi ; Joe Hershberger
>> ; Prabhakar Kushwaha
>> 
>> Subject: Re: [PATCH 0/3] ls1012a: fix tftp failure
>>
>> On 11/21/2017 10:26 PM, Calvin Johnson wrote:
>> > This patch series fixes bug which fails tftp sometimes
>> > while using the pfe interfaces and also has some code clean up.
>> >
>> >
>> > Calvin Johnson (3):
>> >   drivers: net: pfe_eth: add pfe_rx_done to clear bd after packet
>> > processing
>> >   drivers: net: pfe_eth: use writel/readl to access hw bds
>> >   drivers: net: pfe_eth: cleanup typos and indent
>> >
>> >  drivers/net/pfe_eth/pfe_driver.c | 126 +++-
>> ---
>> >  drivers/net/pfe_eth/pfe_eth.c|  13 ++--
>> >  include/pfe_eth/pfe_driver.h |   1 +
>> >  3 files changed, 82 insertions(+), 58 deletions(-)
>> >
>>
>> Your PFE patch set is not fully reviewed or accepted. If I were you, I
>> would probably send v2 version to include all the changes.
>>
>> It is up to Joe to decide to take a new version, or patches on top of
>> patches.

It's assigned to York in patchwork. would you prefer I take them?


> I can squash all these follow up patches to v2 of the base pfe patch series.
> Yes, it will be better than having these patches on top of it as the base is 
> not yet merged.
>
> Thanks
> Calvin
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 6/8] net: pch_gbe: Support PHY reset GPIOs

2017-12-05 Thread Joe Hershberger 
On Tue, Nov 21, 2017 at 2:33 PM, Paul Burton  wrote:
> Add support to the pch_gbe driver for resetting the PHY using a GPIO
> specified in the device tree. This matches the support already in Linux.
>
> Signed-off-by: Paul Burton 
> Cc: Daniel Schwierzeck 
> Cc: Joe Hershberger 
> Cc: Simon Glass 
> Cc: u-boot@lists.denx.de
> Signed-off-by: Paul Burton 

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

Re: [U-Boot] [PATCH 7/8] net: pch_gbe: Use wait_for_bit() helper

2017-12-05 Thread Joe Hershberger 
On Tue, Nov 21, 2017 at 2:33 PM, Paul Burton  wrote:
> The pch_gbe driver has 4 paths which open-code the equivalent of
> wait_for_bit(). Replace these with use of wait_for_bit() in order to
> shorten the code & avoid duplication.
>
> Signed-off-by: Paul Burton 
> Cc: Daniel Schwierzeck 
> Cc: Joe Hershberger 
> Cc: u-boot@lists.denx.de

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

Re: [U-Boot] [PATCH 2/2] drivers: net: pfe_eth: remove unused code under CONFIG_PFE_WARN_WA

2017-12-05 Thread Joe Hershberger 
On Wed, Nov 22, 2017 at 12:45 AM, Calvin Johnson  wrote:
> remove unused code under CONFIG_PFE_WARN_WA
>
> Signed-off-by: Calvin Johnson 

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

Re: [U-Boot] [PATCH 2/3] drivers: net: pfe_eth: use writel/readl to access hw bds

2017-12-05 Thread Joe Hershberger 
On Wed, Nov 22, 2017 at 12:31 AM, Calvin Johnson  wrote:
> writel/readl accessors should be used to access hardware
> buffer descriptors.
>
> Signed-off-by: Calvin Johnson 
> Signed-off-by: Anjaneyulu Jagarlmudi 

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

Re: [U-Boot] [PATCH 1/2] drivers: net: pfe_eth: remove unused code under CONFIG_UTIL_PE_DISABLED

2017-12-05 Thread Joe Hershberger 
On Wed, Nov 22, 2017 at 12:45 AM, Calvin Johnson  wrote:
> remove unused code under CONFIG_UTIL_PE_DISABLED
>
> Signed-off-by: Calvin Johnson 

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

Re: [U-Boot] [PATCH 3/3] drivers: net: pfe_eth: cleanup typos and indent

2017-12-05 Thread Joe Hershberger 
On Wed, Nov 22, 2017 at 12:31 AM, Calvin Johnson  wrote:
> Typos are corrected.
> Some sentences are rephrased.
> Proper indentation added.
>
> Signed-off-by: Calvin Johnson 

Typically clean-up patches should be at the beginning of the series.

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

Re: [U-Boot] [PATCH] net: sh-eth: Add to Kconfig and convert

2017-12-05 Thread Joe Hershberger 
Please fix the title of this patch. It appears to be incomplete.

On Fri, Dec 1, 2017 at 1:08 AM, Nobuhiro Iwamatsu  wrote:
> This adds SH_ETHER to drivers/net/Kconfig and convert to Kconfig.
>
> Signed-off-by: Nobuhiro Iwamatsu 

Otherwise...

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

Re: [U-Boot] [PATCH 1/3] drivers: net: pfe_eth: add pfe_rx_done to clear bd after packet processing

2017-12-05 Thread Joe Hershberger 
On Wed, Nov 22, 2017 at 12:31 AM, Calvin Johnson  wrote:
> Create pfe_rx_done function to clear buffer descriptor
> after the packet is processed by the network stack.
>
> Signed-off-by: Calvin Johnson 
> Signed-off-by: Anjaneyulu Jagarlmudi 

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

Re: [U-Boot] [PATCH] net: sh-eth: Fix misaligned cache operation warning

2017-12-05 Thread Joe Hershberger 
On Thu, Nov 30, 2017 at 10:56 PM, Nobuhiro Iwamatsu
 wrote:
> When we using network on board using sh-eth, it prints a lot of
> "CACHE: Misaligned operation at range" messages.
> This commit fixes this problem.
>
> Signed-off-by: Nobuhiro Iwamatsu 

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

Re: [U-Boot] [RFC PATCH] test: py: Disable sleep test for qemu targets

2017-12-05 Thread Daniel Schwierzeck 


On 05.12.2017 19:38, Tom Rini wrote:
> On Tue, Dec 05, 2017 at 11:20:57AM -0700, Stephen Warren wrote:
>> On 12/04/2017 04:21 PM, Tom Rini wrote:
>>> On Mon, Dec 04, 2017 at 10:14:06AM -0700, Stephen Warren wrote:
 On 12/04/2017 08:30 AM, Tom Rini wrote:
> On Mon, Dec 04, 2017 at 03:21:04PM +0100, Michal Simek wrote:
>> On 4.12.2017 15:03, Tom Rini wrote:
>>> On Mon, Dec 04, 2017 at 02:55:45PM +0100, Michal Simek wrote:
 On 1.12.2017 23:44, Tom Rini wrote:
> On Fri, Dec 01, 2017 at 10:07:54AM -0700, Stephen Warren wrote:
>> On 12/01/2017 08:19 AM, Michal Simek wrote:
>>> Hi,
>>>
>>> On 1.12.2017 16:06, Heinrich Schuchardt wrote:


 On 12/01/2017 03:46 PM, Michal Simek wrote:
> Qemu for arm32/arm64 has a problem with time setup.

 Wouldn't it be preferable to fix the root cause?
>>>
>>> Definitely that would be the best and IIRC I have tried to convince 
>>> our
>>> qemu guy to do that but they have never done that.
>>
>> What is the exact failure condition? Is it simply that the test is 
>> still
>> slightly too strict about which delays it accepts, or is sleep 
>> outright
>> broken?
>>
>> You can use command-line option -k to avoid some tests. For example 
>> "-k not
>> sleep". That way, we don't have to hard-code the dependency into the 
>> test
>> source. Depending on the root cause (issue in U-Boot, or issue in 
>> just your
>> local version of qemu, or something that will never work) this might 
>> be
>> better?
>
> Even with the most recent relaxing of the sleep test requirements, I 
> can
> still (depending on overall system load) have 'sleep' take too long, 
> on
> QEMU.  I think it might have been half a second slow, but I don't have
> the log handy anymore.  Both locally and in travis we -k not sleep all
> of the qemu instances.

 ok. By locally do you mean just using -k not sleep?
>>>
>>> Yes, I have that in my CI scripts and similar.
>>
>> Wouldn't be easier to keep this in uboot-test-hooks repo with other
>> target setting?
>
> Or do as you did did and mark the tests as not allowed for qemu, yes.
>
>> What we are trying to do is that our testing group will run these tests
>> for me that's why it is just easier for me to change local
>> uboot-test-hooks repo instead of communicate with them what -k not XXX
>> parameters to add to certain scripts.
>>
>> It means in loop they will just run all tests on qemu, local targets and
>> in boardfarm. It is probably not big deal to tell them to add -k not
>> sleep for all qemu runs but I know that for some i2c testing qemu
>> doesn't emulate these devices that's why these tests fails. And the
>> amount of tests which we shouldn't run on qemu will probably grow.
>
> Well, I'm still open to possibly tweaking the allowed variance in the
> sleep test.  OTOH, if we just say "no QEMU" here, we can then go back to
> "sleep should be pretty darn accurate on HW" for the test too, and
> perhaps that's best.

 The fundamental problem of "over-sleeping" due to host system load/.. 
 exists
 with all boards. There's nothing specific to qemu here except that running
 U-Boot on qemu on the host rather than on separate HW might more easily
 trigger the "high load on the host" condition; I see the issue now and then
 and manually retry that test, although that is a bit annoying.

 The original test was mostly intended to make sure that e U-Boot clock
 didn't run at a significantly different rate to the host, since I had seen
 that issue during development of some board support or as a regression
 sometime. Perhaps the definition of "significantly different" should be 
 more
 like "1/2 rate or twice rate or more" rather than "off by a small fraction
 of a second". That might avoid so many false positives.
>>>
>>> I've pushed this up to 10 seconds and 0.5s worth of overrun and on
>>> qemu-mips here I see a 13.2s sleep.  That's pretty close to 1/3rd fast
>>> and to me a wrong-clocking value, yes?
>>
>> For me the qemu-x86 build of mid-Nov commit of U-Boot running under the same
>> qemu version that U-Boot's Travis CI builds use, "sleep 10" takes about 10.5
>> seconds (including my reaction time), so ~13.2 does sound like it's probably
>> a bug. Or maybe qemu just isn't fast enough in its emulation to keep up with
>> real-time? I'd hope not for something simple like this, assuming you're
>> using a recent CPU, but maybe.
> 
> Yeah, I can do x86, ARM and PowerPC but it fails on MIPS.  And my build
> box isn't super new but an 8core/16thread E5-2670 should

Re: [U-Boot] [PATCH] net: sh-eth: Change structure used in read/write function to struct sh_eth_info

2017-12-05 Thread Joe Hershberger 
On Thu, Nov 30, 2017 at 5:10 PM, Nobuhiro Iwamatsu  wrote:
> This changes Change structure used in sh_eth_read and sh_eth_write function
> from struct sh_eth_dev to struct sh_eth_info.
> This is necessary to convert to Drivers model.
>
> Signed-off-by: Nobuhiro Iwamatsu 

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

Re: [U-Boot] [PATCH] net: sh-eth: Remove bd_t from sh_eth_config()

2017-12-05 Thread Joe Hershberger 
On Thu, Nov 30, 2017 at 5:08 PM, Nobuhiro Iwamatsu  wrote:
> bd_t is not used in sh_eth_config(). This deletes bd_t from sh_eth_config().
>
> Signed-off-by: Nobuhiro Iwamatsu 

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

Re: [U-Boot] [RESEND PATCH 2/2] net: designware: add clock support

2017-12-05 Thread Joe Hershberger 
On Wed, Nov 29, 2017 at 2:06 AM,   wrote:
> From: Patrice Chotard 
>
> This implementation manages several clocks, disable and
> free all of them in case of error during probe and in remove
> callback.
>
> Signed-off-by: Patrice Chotard 

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

Re: [U-Boot] [PATCH] net: sh-eth: Fix coding style checked by checkpatch.pl

2017-12-05 Thread Joe Hershberger 
On Thu, Nov 30, 2017 at 5:08 PM, Nobuhiro Iwamatsu  wrote:
> This fixes the chord style checked by checkpatch.pl.
> Details of change details are as follows:
>
>  - Fix typo
> Change from alligned to aligned.
>  - Remove whitespace before ','
>  - Add spaces preferred around that '|'
>  - Fix missing a blank line after declarations
>  - Remove space after a cast declaration
>  - Fix format of block comments
>  - Add a blank line after function/struct/union/enum declarations
>
> Signed-off-by: Nobuhiro Iwamatsu 

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

Re: [U-Boot] [PATCH V2 19/23] net: fec: fix build warnings for 64bits support

2017-12-05 Thread Joe Hershberger 
On Sun, Dec 3, 2017 at 10:31 PM, Peng Fan  wrote:
> When building for 64bits system, we get some warnings about type
> cast between pointer and integer. This patch eliminates the warnings
> by using ulong/long type which is 32bits on 32bits system or 64bits on
> 64bits system.
>
> Signed-off-by: Ye Li 
> Signed-off-by: Peng Fan 
> Cc: Joe Hershberger 

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

Re: [U-Boot] [PATCH V2 18/23] net: fec: do not access reserved register for i.MX8M

2017-12-05 Thread Joe Hershberger 
On Sun, Dec 3, 2017 at 10:31 PM, Peng Fan  wrote:
> The MIB RAM and FIFO receive start register does not exist on
> i.MX8M. Accessing these register will cause system hang.
>
> Signed-off-by: Peng Fan 
> Cc: Joe Hershberger 

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

Re: [U-Boot] [PATCH] TCP and wget implementation.

2017-12-05 Thread Joe Hershberger 
Hi Duncan,

The subject should not end with a '.' character.

Also, this should have been marked as v2. Please mark the next as v3.

On Wed, Nov 8, 2017 at 6:34 PM, Duncan Hare  wrote:
> his is the interface and Kconfig files for introducing TCP and wget
> into u-boot.

Missing 'T' at the beginning?

> Interfaces are in net.c and net.h, ping is modified to the new ip send
> interface, and UDP and TCP have shim procedures call map the protocol
> interface to the ip interface.

I'd like to see the shim and all changes to existing stack as a
separate patch to make review simpler.

Also please make TCP and wget into 2 other separate patches.

> The UDP interface is unchanged, and the existing UDP programs need no
> changes.
>
> All the code is new, and not copied from any source.
>
> The wget command and TCP stack are separately configured in Kconfig,
> and provisioning wget without TCP will result in a number of error
> messages. It might be possible to have Kconfig handle dependencies,
> if so advice is welcome.

Yes it should... you could have wget "selects" tcp.

> Makefile in the net directory is modified by hand. It appears not to be
> generated by Kconfig. Again advice is welcome.

That's fine.

> The rationale behind this change is that UDP file transfers elapsed time
> is twice the sum of network latency x number of pcckets, and TCP file
> transfer times are about 4x network latency plus data transit time.
>
> In tests this reduces kernel trnasfer time from about 15 to 20 seconds
> with tftp on a raspberry pi to about 0.4 seconds with wget.

What settings are used in this tftp benchmark for block size? It makes
a huge difference to the performance.

> The raspberry pi as a sink for the kernel runs at about 10 Mbits/sec.
>
> Signed-off-by: Duncan Hare 
> ---
>
>  cmd/Kconfig   |   5 +++
>  cmd/net.c |  13 
>  include/net.h |  26 ---
>  net/Kconfig   |   5 +++
>  net/Makefile  |   3 +-
>  net/net.c | 100 
> --
>  net/ping.c|   9 ++
>  7 files changed, 132 insertions(+), 29 deletions(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 5a6afab99b..4e5bac685e 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1035,6 +1035,11 @@ config CMD_ETHSW
>   operations such as enabling / disabling a port and
>   viewing/maintaining the filtering database (FDB)
>
> +config CMD_WGET
> +   bool "wget"
> +   help
> + Download a kernel, or other files, from a web server over TCP.
> +
>  endmenu
>
>  menu "Misc commands"
> diff --git a/cmd/net.c b/cmd/net.c
> index d7c776aacf..f5c2d0f8ed 100644
> --- a/cmd/net.c
> +++ b/cmd/net.c
> @@ -110,6 +110,19 @@ U_BOOT_CMD(
>  );
>  #endif
>
> +#if defined(CONFIG_CMD_WGET)
> +static int do_wget(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> +   return netboot_common(WGET, cmdtp, argc, argv);
> +}
> +
> +U_BOOT_CMD(
> +   wget,   3,  1,  do_wget,
> +   "boot image via network using HTTP protocol",
> +   "[loadAddress] [[hostIPaddr:]bootfilename]"
> +);
> +#endif
> +
>  static void netboot_update_env(void)
>  {
> char tmp[22];
> diff --git a/include/net.h b/include/net.h
> index 455b48f6c7..7787413816 100644
> --- a/include/net.h
> +++ b/include/net.h
> @@ -24,8 +24,17 @@
>   * The number of receive packet buffers, and the required packet buffer
>   * alignment in memory.
>   *
> + * The nuber of buffers for TCP is used to calculate a static TCP window
> + * size, becuse TCP window size is a promise to the sending TCP to be 
> able
> + * to buffer up to the window size of data.
> + * When the sending TCP has a window size of outstanding unacknowledged
> + * data, the sending TCP will stop sending.
>   */
>
> +#if defined(CONFIG_TCP)
> +#define CONFIG_SYS_RX_ETH_BUFFER 50/* For TCP */
> +#endif
> +
>  #ifdef CONFIG_SYS_RX_ETH_BUFFER
>  # define PKTBUFSRX CONFIG_SYS_RX_ETH_BUFFER
>  #else
> @@ -354,6 +363,8 @@ struct vlan_ethernet_hdr {
>
>  #define IPPROTO_ICMP1  /* Internet Control Message Protocol*/
>  #define IPPROTO_UDP17  /* User Datagram Protocol   */
> +#define IPPROTO_TCP 6  /* Transmission Control Protocol*/
> +
>
>  /*
>   * Internet Protocol (IP) header.
> @@ -538,7 +549,7 @@ extern int  net_restart_wrap;   /* Tried all 
> network devices */
>
>  enum proto_t {
> BOOTP, RARP, ARP, TFTPGET, DHCP, PING, DNS, NFS, CDP, NETCONS, SNTP,
> -   TFTPSRV, TFTPPUT, LINKLOCAL
> +   TFTPSRV, TFTPPUT, LINKLOCAL, WGET
>  };
>
>  extern charnet_boot_file_name[1024];/* Boot File name */
> @@ -596,10 +607,10 @@ int net_set_ether(uchar *xet, const uchar 
> *dest_ethaddr, uint prot);
>  int net_update_ether(struct ethernet_hdr *et, uchar *addr, uint prot);
>
>  /* Set IP header */
> -void net_set_ip_header(uchar *pkt, struct in_addr dest, struct in_addr 
> source);

Re: [U-Boot] [Patch v2 1/2] driver: net: ldpaa_eth: Add PHY-less SGMII support

2017-12-05 Thread Joe Hershberger 
On Mon, Nov 13, 2017 at 3:37 AM, Ashish Kumar  wrote:
> In case of PHY-less mode, there is no interaction with PHY
> so auto-neg etc is not required and link will have fixed
> attributes

It appears that the commit message does not match the code. It appears
you are adding SGMII support. I don't see any thing that would affect
auto-neg. Please either correct the patch or make the message more
clear.

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

Re: [U-Boot] [PATCH] arm: zynq: Use unsigned type with comparison with ARRAY_SIZE

2017-12-05 Thread Joe Hershberger 
On Fri, Nov 10, 2017 at 7:07 AM, Michal Simek  wrote:
> Sparse is return warning about this:
> arch/arm/mach-zynq/slcr.c: In function 'zynq_slcr_get_mio_pin_status':
> arch/arm/mach-zynq/slcr.c:185:16: warning: comparison between signed and
> unsigned integer expressions [-Wsign-compare]
>   for (i = 0; i < ARRAY_SIZE(mio_periphs); i++) {
> ^
>
> Signed-off-by: Michal Simek 

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

Re: [U-Boot] [PATCH 2/9] drivers: net: pfe_eth: provide pfe commands

2017-12-05 Thread Joe Hershberger 
On Mon, Oct 9, 2017 at 4:11 AM, Calvin Johnson  wrote:
> pfe_command provides command line support for several features that
> support pfe like starting or stopping the pfe, checking the health
> of the processor engines and checking status of different unit inside
> pfe.
>
> Signed-off-by: Calvin Johnson 
> Signed-off-by: Anjaneyulu Jagarlmudi 

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

Re: [U-Boot] [PATCH 4/4] configs: Update Lamobo_R1 with B53 switch options

2017-12-05 Thread Joe Hershberger 
On Sat, Oct 14, 2017 at 8:00 PM, Florian Fainelli  wrote:
> Enable CONFIG_B53_SWITCH, define the CPU/management port number (8) and
> enable all 5 ports of the switch to be usable.
>
> Signed-off-by: Florian Fainelli 

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

Re: [U-Boot] [PATCH 3/4] net: phy: b53: Add b53_reg read/write commands

2017-12-05 Thread Joe Hershberger 
On Sat, Oct 14, 2017 at 3:20 PM, Florian Fainelli  wrote:
> Add a b53_reg read/write command which allows inspecting the switch
> registers. Because the Broadcom BCM53xx registers have different sizes,
> we need to split the accesses in 8, 16, 32, 48 or 64 bits to obtain
> expected results.
>
> Signed-off-by: Florian Fainelli 

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

Re: [U-Boot] [PATCH 2/4] net: designware: Pad small packets

2017-12-05 Thread Joe Hershberger 
On Sat, Oct 14, 2017 at 8:00 PM, Florian Fainelli  wrote:
> Make sure that we pad small packets to a minimum length of 60 bytes
> (without FCS). This is necessary to interface with Ethernet switches
> that will reject RUNT frames unless padded correctly.
>
> Signed-off-by: Florian Fainelli 
> ---
>  drivers/net/designware.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/designware.c b/drivers/net/designware.c
> index 036d231071ca..10356a9abd0e 100644
> --- a/drivers/net/designware.c
> +++ b/drivers/net/designware.c
> @@ -343,6 +343,8 @@ int designware_eth_enable(struct dw_eth_dev *priv)
> return 0;
>  }
>
> +#define ETH_ZLEN   60
> +
>  static int _dw_eth_send(struct dw_eth_dev *priv, void *packet, int length)
>  {
> struct eth_dma_regs *dma_p = priv->dma_regs_p;
> @@ -369,6 +371,8 @@ static int _dw_eth_send(struct dw_eth_dev *priv, void 
> *packet, int length)
> return -EPERM;
> }
>
> +   length = (length < ETH_ZLEN) ? ETH_ZLEN : length;

Why not use max() from include/linux/kernel.h here?


> +
> memcpy((void *)data_start, packet, length);
>
> /* Flush data to be sent */
> --
> 2.11.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] net: phy: Add Broadcom BCM53xx switch driver

2017-12-05 Thread Joe Hershberger 
Hi Florian,

On Sat, Oct 14, 2017 at 8:00 PM, Florian Fainelli  wrote:
> Add a minimalistic Broadcom BCM53xx (roboswitch) switch driver similar
> to the Marvell MV88E617x. This takes care of configuring the minimum
> amount out of the switch hardware such that each user visible port
> (configurable) and the CPU port can forward packets between each other
> while preserving isolation with other ports.
>
> This is useful for e.g: the Lamobo R1 board featuring a Broadcom
> BCM53125 switch.
>
> Signed-off-by: Florian Fainelli 

One small nit below, but...

Acked-by: Joe Hershberger 

> ---
>  drivers/net/phy/Kconfig  |  14 ++
>  drivers/net/phy/Makefile |   1 +
>  drivers/net/phy/b53.c| 629 
> +++
>  drivers/net/phy/phy.c|   3 +
>  include/phy.h|   1 +
>  5 files changed, 648 insertions(+)

[ ... ]

> +static int b53_probe(struct phy_device *phydev)
> +{
> +   struct b53_device *dev;
> +   int ret;
> +
> +   dev = malloc(sizeof(*dev));
> +   if (!dev)
> +   return -ENOMEM;
> +
> +   memset(dev, 0, sizeof(*dev));
> +
> +   phydev->priv = dev;
> +   dev->bus = phydev->bus;
> +   dev->cpu_port = CONFIG_B53_CPU_PORT;
> +
> +   ret = b53_switch_reset(phydev);
> +   if (ret < 0)
> +   return ret;
> +
> +   phydev->priv = dev;

Why set this twice?

> +
> +   return 0;
> +}

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

Re: [U-Boot] [PATCH v3] net: phy: marvell: Add functions to read PHY's extended registers

2017-12-05 Thread Joe Hershberger 
On Mon, Oct 30, 2017 at 4:57 PM, Lukasz Majewski  wrote:
> This commit allows extended Marvell registers to be read with:
>
> foo > mdio rx FEC 3.10
> Reading from bus FEC
> PHY at address 0:
> 3.16 - 0x1063
> foo > mdio wx FEC 3.10 0x1011
>
> The above code changes the way ETH connector LEDs blink.
>
> Signed-off-by: Lukasz Majewski 

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

Re: [U-Boot] [PATCH 076/080] phy: Fix style violations

2017-12-05 Thread Joe Hershberger 
On Fri, Sep 29, 2017 at 7:52 AM, Mario Six  wrote:
> Fix some style violations in the generic PHY management code.
>
> Signed-off-by: Mario Six 
> ---
>  drivers/net/phy/phy.c | 82 
> ++-
>  1 file changed, 49 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 5be51d73ce..0050a70075 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -27,7 +27,7 @@ DECLARE_GLOBAL_DATA_PTR;
>  /* Generic PHY support and helper functions */
>
>  /**
> - * genphy_config_advert - sanitize and advertise auto-negotation parameters
> + * genphy_config_advert - sanitize and advertise auto-negotiation parameters
>   * @phydev: target phy_device struct
>   *
>   * Description: Writes MII_ADVERTISE with the appropriate values,
> @@ -117,7 +117,6 @@ static int genphy_config_advert(struct phy_device *phydev)
> return changed;
>  }
>
> -
>  /**
>   * genphy_setup_forced - configures/forces speed/duplex from @phydev
>   * @phydev: target phy_device struct
> @@ -130,14 +129,15 @@ static int genphy_setup_forced(struct phy_device 
> *phydev)
> int err;
> int ctl = BMCR_ANRESTART;
>
> -   phydev->pause = phydev->asym_pause = 0;
> +   phydev->pause = 0;
> +   phydev->asym_pause = 0;
>
> -   if (SPEED_1000 == phydev->speed)
> +   if (phydev->speed == SPEED_1000)
> ctl |= BMCR_SPEED1000;
> -   else if (SPEED_100 == phydev->speed)
> +   else if (phydev->speed == SPEED_100)
> ctl |= BMCR_SPEED100;
>
> -   if (DUPLEX_FULL == phydev->duplex)
> +   if (phydev->duplex == DUPLEX_FULL)
> ctl |= BMCR_FULLDPLX;
>
> err = phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, ctl);
> @@ -145,7 +145,6 @@ static int genphy_setup_forced(struct phy_device *phydev)
> return err;
>  }
>
> -
>  /**
>   * genphy_restart_aneg - Enable and Restart Autonegotiation
>   * @phydev: target phy_device struct
> @@ -169,7 +168,6 @@ int genphy_restart_aneg(struct phy_device *phydev)
> return ctl;
>  }
>
> -
>  /**
>   * genphy_config_aneg - restart auto-negotiation or write BMCR
>   * @phydev: target phy_device struct
> @@ -182,7 +180,7 @@ int genphy_config_aneg(struct phy_device *phydev)
>  {
> int result;
>
> -   if (AUTONEG_ENABLE != phydev->autoneg)
> +   if (phydev->autoneg != AUTONEG_ENABLE)
> return genphy_setup_forced(phydev);
>
> result = genphy_config_advert(phydev);
> @@ -192,7 +190,8 @@ int genphy_config_aneg(struct phy_device *phydev)
>
> if (result == 0) {
> /* Advertisment hasn't changed, but maybe aneg was never on to

Shouldn't this text start on the line after "/*" ?

> -* begin with?  Or maybe phy was isolated? */
> +* begin with?  Or maybe phy was isolated?
> +*/
> int ctl = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR);
>
> if (ctl < 0)
> @@ -203,7 +202,8 @@ int genphy_config_aneg(struct phy_device *phydev)
> }
>
> /* Only restart aneg if we are advertising something different

Same here.

> -* than we were before.  */
> +* than we were before.
> +*/
> if (result > 0)
> result = genphy_restart_aneg(phydev);
>
> @@ -240,7 +240,7 @@ int genphy_update_link(struct phy_device *phydev)
> int i = 0;
>
> printf("%s Waiting for PHY auto negotiation to complete",
> -   phydev->dev->name);
> +  phydev->dev->name);
> while (!(mii_reg & BMSR_ANEGCOMPLETE)) {
> /*
>  * Timeout reached ?
> @@ -305,7 +305,8 @@ int genphy_parse_link(struct phy_device *phydev)
>  */
> gblpa = phy_read(phydev, MDIO_DEVAD_NONE, 
> MII_STAT1000);
> if (gblpa < 0) {
> -   debug("Could not read MII_STAT1000. Ignoring 
> gigabit capability\n");
> +   debug("Could not read MII_STAT1000. ");
> +   debug("Ignoring gigabit capability\n");
> gblpa = 0;
> }
> gblpa &= phy_read(phydev,
> @@ -338,8 +339,9 @@ int genphy_parse_link(struct phy_device *phydev)
> if (lpa & LPA_100FULL)
> phydev->duplex = DUPLEX_FULL;
>
> -   } else if (lpa & LPA_10FULL)
> +   } else if (lpa & LPA_10FULL) {
> phydev->duplex = DUPLEX_FULL;
> +   }
>
> /*
>  * Extended status may indicate that the PHY supports
> @@ -574,7 +576,9 @@ static int phy_probe(struct phy_device *phydev)
>  {
> int err = 0;
>
> -   phydev->advertising

Re: [U-Boot] [PATCH 1/9] drivers: net: pfe_eth: LS1012A PFE driver introduction

2017-12-05 Thread Joe Hershberger 
On Mon, Oct 9, 2017 at 4:11 AM, Calvin Johnson  wrote:
> This patch adds PFE driver into U-Boot.
>
> Following are the main driver files:-
> pfe.c: provides low level helper functions to initialize PFE internal
> processor engines and other hardware blocks.
> pfe_driver.c: provides probe functions, initialization functions
> and packet send and receive functions.
> pfe_eth.c: provides high level gemac, phy and mdio initialization
> functions.
> pfe_firmware.c: provides functions to load firmware into PFE
> internal processor engines.
>
> Signed-off-by: Calvin Johnson 
> Signed-off-by: Anjaneyulu Jagarlmudi 
> ---
>  drivers/net/pfe_eth/Kconfig|8 +
>  drivers/net/pfe_eth/Makefile   |   10 +
>  drivers/net/pfe_eth/pfe.c  | 1161 
> 
>  drivers/net/pfe_eth/pfe_driver.c   |  626 +++
>  drivers/net/pfe_eth/pfe_eth.c  |  545 +
>  drivers/net/pfe_eth/pfe_firmware.c |  230 +++
>  6 files changed, 2580 insertions(+)
>  create mode 100644 drivers/net/pfe_eth/Kconfig
>  create mode 100644 drivers/net/pfe_eth/Makefile
>  create mode 100644 drivers/net/pfe_eth/pfe.c
>  create mode 100644 drivers/net/pfe_eth/pfe_driver.c
>  create mode 100644 drivers/net/pfe_eth/pfe_eth.c
>  create mode 100644 drivers/net/pfe_eth/pfe_firmware.c
>
> diff --git a/drivers/net/pfe_eth/Kconfig b/drivers/net/pfe_eth/Kconfig
> new file mode 100644
> index 000..b9996df
> --- /dev/null
> +++ b/drivers/net/pfe_eth/Kconfig
> @@ -0,0 +1,8 @@
> +config UTIL_PE_DISABLED
> +   bool
> +   help
> + Disable UTIL processor engine of PFE
> +
> +config SYS_FSL_PPFE_ADDR
> +   hex "PFE base address"
> +   default 0x0400
> diff --git a/drivers/net/pfe_eth/Makefile b/drivers/net/pfe_eth/Makefile
> new file mode 100644
> index 000..e78f1bf
> --- /dev/null
> +++ b/drivers/net/pfe_eth/Makefile
> @@ -0,0 +1,10 @@
> +# Copyright 2015-2016 Freescale Semiconductor, Inc.
> +# Copyright 2017 NXP
> +#
> +# SPDX-License-Identifier:GPL-2.0+
> +
> +# Layerscape PFE driver
> +obj-y += pfe.o \
> +pfe_driver.o   \
> +pfe_eth.o  \
> +pfe_firmware.o
> diff --git a/drivers/net/pfe_eth/pfe.c b/drivers/net/pfe_eth/pfe.c
> new file mode 100644
> index 000..fc6631e
> --- /dev/null
> +++ b/drivers/net/pfe_eth/pfe.c
> @@ -0,0 +1,1161 @@
> +/*
> + * Copyright 2015-2016 Freescale Semiconductor, Inc.
> + * Copyright 2017 NXP
> + *
> + * SPDX-License-Identifier:GPL-2.0+
> + */
> +#include 
> +#include 
> +
> +void *ddr_base_addr;
> +unsigned long ddr_phys_base_addr;
> +static struct pe_info pe[MAX_PE];
> +
> +/*
> + * Initializes the PFE library.
> + * Must be called before using any of the library functions.
> + *
> + * @param[in] cbus_baseCBUS virtual base address (as mapped 
> in
> + * the host CPU address space)
> + * @param[in] ddr_base DDR virtual base address (as mapped in
> + * the host CPU address space)
> + * @param[in] ddr_phys_baseDDR physical base address (as mapped in
> + * platform)
> + */
> +void pfe_lib_init(void *ddr_base, unsigned long ddr_phys_base)

Could you use some loops here to consolidate this code some?

> +{
> +   ddr_base_addr = ddr_base;
> +   ddr_phys_base_addr = ddr_phys_base;
> +
> +   pe[CLASS0_ID].dmem_base_addr = (u32)CLASS_DMEM_BASE_ADDR(0);
> +   pe[CLASS0_ID].pmem_base_addr = (u32)CLASS_IMEM_BASE_ADDR(0);
> +   pe[CLASS0_ID].pmem_size = (u32)CLASS_IMEM_SIZE;
> +   pe[CLASS0_ID].mem_access_wdata = (void *)CLASS_MEM_ACCESS_WDATA;
> +   pe[CLASS0_ID].mem_access_addr = (void *)CLASS_MEM_ACCESS_ADDR;
> +   pe[CLASS0_ID].mem_access_rdata = (void *)CLASS_MEM_ACCESS_RDATA;
> +
> +   pe[CLASS1_ID].dmem_base_addr = (u32)CLASS_DMEM_BASE_ADDR(1);
> +   pe[CLASS1_ID].pmem_base_addr = (u32)CLASS_IMEM_BASE_ADDR(1);
> +   pe[CLASS1_ID].pmem_size = (u32)CLASS_IMEM_SIZE;
> +   pe[CLASS1_ID].mem_access_wdata = (void *)CLASS_MEM_ACCESS_WDATA;
> +   pe[CLASS1_ID].mem_access_addr = (void *)CLASS_MEM_ACCESS_ADDR;
> +   pe[CLASS1_ID].mem_access_rdata = (void *)CLASS_MEM_ACCESS_RDATA;
> +
> +   pe[CLASS2_ID].dmem_base_addr = (u32)CLASS_DMEM_BASE_ADDR(2);
> +   pe[CLASS2_ID].pmem_base_addr = (u32)CLASS_IMEM_BASE_ADDR(2);
> +   pe[CLASS2_ID].pmem_size = (u32)CLASS_IMEM_SIZE;
> +   pe[CLASS2_ID].mem_access_wdata = (void *)CLASS_MEM_ACCESS_WDATA;
> +   pe[CLASS2_ID].mem_access_addr = (void *)CLASS_MEM_ACCESS_ADDR;
> +   pe[CLASS2_ID].mem_access_rdata = (void *)CLASS_MEM_ACCESS_RDATA;
> +
> +   pe[CLASS3_ID].dmem_base_addr = (u32)CLASS_DMEM_BASE_ADDR(3);
> +   pe[CLASS3_ID].pmem_base_addr = (u32)CLASS_IMEM_BASE_ADDR(3);
> +   pe[CLASS3_ID].pmem_size = (u32)CLASS_IMEM_SIZE;
> +   pe[CLASS3_ID].mem_access_wdata = (void

Re: [U-Boot] [PATCH 2/2] net: designware: add clock support

2017-12-05 Thread Joe Hershberger 
On Tue, Nov 28, 2017 at 10:41 AM,   wrote:
> From: Patrice Chotard 
>
> This implementation manages several clocks, disable and
> free all of them in case of error during probe and in remove
> callback.
>
> Signed-off-by: Patrice Chotard 

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

Re: [U-Boot] [PATCH 1/2] dm: core: add missing dev_count_phandle_with_args()

2017-12-05 Thread Joe Hershberger 
On Tue, Nov 28, 2017 at 10:41 AM,   wrote:
> From: Patrice Chotard 
>
> Add missing dev_count_phandle_with_args() to avoid
> compilation issue.
>
> Signed-off-by: Patrice Chotard 

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

Re: [U-Boot] [PATCH v1] net: mvneta - Fixed recv() when multiple packets have arrived.

2017-12-05 Thread Joe Hershberger 
On Tue, Nov 28, 2017 at 1:12 PM, Jason Brown  wrote:
> This patch fixes a problem in the mvneta driver where if more than
> one packet arrives between calls to mvneta_recv(), the additional
> descriptors will be marked as free even though only one descriptor
> has been read and processed from the receive queue.  This causes
> the additional packet(s) to be delayed until the next packet arrives.
> From this point on all packets will be delayed because the receive
> queue will contain unprocessed packets but the hardware shows no
> busy descriptors.
>
> Signed-off-by: Jason Brown 

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

Re: [U-Boot] [PATCH 09/22] mtd: nand: automate NAND timings selection

2017-12-05 Thread York Sun 
On 12/05/2017 08:38 AM, York Sun wrote:
> On 12/04/2017 04:31 PM, Masahiro Yamada wrote:
>>> Err:   serial
>>> Net:
>>> MMC read: dev # 0, block # 2080, count 128 ...
>>> Fman1: Data at 7faf67d0 is not a firmware
>>> e1000#0: Out of Memory!
>>
>>
>> Looks like malloc() failed.
>>
>>
>>> No ethernet found.
>>> Hit any key to stop autoboot:  0
>>> (York: Hit a key to stop the counting down here)
>>> ERROR : memory not allocated
>>
>>
>> This error message comes from xmalloc() or xrealloc().
>>
>>
>>
>> I think your board grew in size by my commit.
>>
>>
>> Does disabling some features solve your problem?
>>
> I tried to disable USB feature and reduced the image size, but that
> didn't fix this issue. I don't believe NAND driver has anything to do
> with this issue though. I will keep debugging.
> 

I think I found the root cause. It is dcache related. I am testing on
more platform before sending out a patch.

Sorry for the noise.

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

[U-Boot] tiny printf limits

2017-12-05 Thread Frank Mori Hess 
Shouldn't tiny printf abort or something when it encounters a printf
format string it doesn't support?  Right now, it just silently skips
it while leaving the associated argument in place, resulting in the
arguments getting shifted onto the wrong format strings.

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

Re: [U-Boot] [PATCH] gpt: add part-uuid and part-num subcommands

2017-12-05 Thread Andrey Yurovsky 
On Tue, Dec 5, 2017 at 7:10 AM, Lukasz Majewski  wrote:
> Hi Andrey,
>
>> On Mon, Dec 4, 2017 at 1:12 PM, Lukasz Majewski
>>  wrote:
>> > Hi Andrey,
>> >
>> >> Hi Lukasz,
>> >>
>> >> On Tue, Nov 14, 2017 at 1:45 AM, Lukasz Majewski
>> >>  wrote:
>> >> > Hi Andrey,
>> >> >
>> >> >> Hi Lukasz,
>> >> >>
>> >> >> On Thu, Nov 9, 2017 at 2:28 PM, Lukasz Majewski
>> >> >>  wrote:
>> >> >> > On Thu, 9 Nov 2017 07:34:44 -0800
>> >> >> > Andrey Yurovsky  wrote:
>> >> >> >
>> >> >> >> On Thu, Nov 9, 2017 at 1:55 AM, Lukasz Majewski
>> >> >> >>  wrote:
>> >> >> >> > Hi Andrey,
>> >> >> >> >
>> >> >> >> >> Hi Otavio,
>> >> >> >> >>
>> >> >> >> >> On Wed, Nov 8, 2017 at 2:47 AM, Otavio Salvador
>> >> >> >> >>  wrote:
>> >> >> >> >> > On Tue, Nov 7, 2017 at 10:43 PM, your name
>> >> >> >> >> >  wrote:
>> >> >> >> >> >> From: Andrey Yurovsky 
>> >> >> >> >> >>
>> >> >> >> >> >> It is useful to be able to retrieve a partition UUID or
>> >> >> >> >> >> number given the partition label, for instance some
>> >> >> >> >> >> systems use the partition label to indicate the purpose
>> >> >> >> >> >> of the partition (such as "rootfs0" being the 0th root
>> >> >> >> >> >> file system in an A/B image scheme).
>> >> >> >> >> >>
>> >> >> >> >> >> Add "gpt part-uuid" to retrieve the partition UUID for
>> >> >> >> >> >> a given label and "gpt part-num" to retrieve the
>> >> >> >> >> >> partition number for a given label along with some
>> >> >> >> >> >> documentation.
>> >> >> >> >> >>
>> >> >> >> >> >> Signed-off-by: Andrey Yurovsky 
>> >> >> >> >> >
>> >> >> >> >> > Why not use the 'part' cmd? it provides it.
>> >> >> >> >>
>> >> >> >> >> Sorry, I missed the part cmd, it doesn't seem to be
>> >> >> >> >> documented in doc/ and it's unclear what  means
>> >> >> >> >> there.
>> >> >> >> >
>> >> >> >> > If I may ask - Andrey, if you are now on this "topic" -
>> >> >> >> > would you dare to add some ./doc entry for 'part'
>> >> >> >> > command?
>> >> >> >>
>> >> >> >> Yes, I will do that.
>> >> >> >
>> >> >> > Thanks :-)
>> >> >>
>> >> >> On further investigation I am not sure that it's possible to
>> >> >> extend the part command to retrieve UUIDs by label because of
>> >> >> the design of the partition type drivers. Here is how I
>> >> >> understand it to work: 1. the "part" command uses
>> >> >> part_get_info() and in turn gets a partition driver and can
>> >> >> call print() there (which is how EFI/GPT disks are printed with
>> >> >> "part list"). The right information (including label) is
>> >> >> printed but it's not tied to the caller in any way.
>> >> >
>> >> > Maybe you can set some env variable with proper data?
>> >> >
>> >> > For example, please refer to ./cmd/part.c do_part_start()
>> >> > function.
>> >> >
>> >> > Example call from envs (include/configs/display5.h):
>> >> > "part start mmc ${mmcdev} ${kernel_part} lba_start; " \
>> >> >
>> >>
>> >> Again that assumes the partition is referred to by number, I need
>> >> it to be by label, and the part/disk interface does not seem to
>> >> have any way to utilize labels. Unfortunately it looks like my
>> >> original approach with the gpt command is the only way to
>> >> implement this with the current design (at least from what I see
>> >> here). Please let me know if I've missed something. Thanks!
>> >
>> > Please correct me if I'm wrong - you need the starting LBA of the
>> > partition named e.g. "FOO" in gpt ?
>> >
>> > Conceptually it would be correct to have:
>> >
>> > part start
>> > gpt start
>> >
>> > If your code is really _small_ and can be used only with GPT, then
>> > lets go for the second option.
>>
>> The use cases I have in mind:
>>
>> 1. determine which root file system to use by label, let's say
>> "rootfs1" and pass its UUID to the Linux kernel via the command line,
>> ex: "PART-UUID=${uuid}". To do this we need a way to ask for a UUID
>> corresponding to a label in the partition table (given duplicate
>> labels, assume it gives us the first or last match).
>
> I see. I thought that you need start LBA.
>
> From your use case it seems like extending the 'gpt' command is the
> right thing to do - since already some uuid handling is done there.

In that case would you please let me know if the patch I sent is reasonable?

>> 2. determine which file system to load a file from (ex: fatload) given
>> a label.
>
> There is a group of generic commands - like load, ls, etc.

It seems that the lowest common denominator for these is indeed the
partition number (then they can talk to the disk driver) so adding a
way to map labels to that number (as in my original patch) may be
useful, the user's script can then use these commands once it learns
that information via the gpt command.

>> I'm not sure that the starting LBA is helpful

Re: [U-Boot] [RFC PATCH] test: py: Disable sleep test for qemu targets

2017-12-05 Thread Tom Rini 
On Tue, Dec 05, 2017 at 11:20:57AM -0700, Stephen Warren wrote:
> On 12/04/2017 04:21 PM, Tom Rini wrote:
> >On Mon, Dec 04, 2017 at 10:14:06AM -0700, Stephen Warren wrote:
> >>On 12/04/2017 08:30 AM, Tom Rini wrote:
> >>>On Mon, Dec 04, 2017 at 03:21:04PM +0100, Michal Simek wrote:
> On 4.12.2017 15:03, Tom Rini wrote:
> >On Mon, Dec 04, 2017 at 02:55:45PM +0100, Michal Simek wrote:
> >>On 1.12.2017 23:44, Tom Rini wrote:
> >>>On Fri, Dec 01, 2017 at 10:07:54AM -0700, Stephen Warren wrote:
> On 12/01/2017 08:19 AM, Michal Simek wrote:
> >Hi,
> >
> >On 1.12.2017 16:06, Heinrich Schuchardt wrote:
> >>
> >>
> >>On 12/01/2017 03:46 PM, Michal Simek wrote:
> >>>Qemu for arm32/arm64 has a problem with time setup.
> >>
> >>Wouldn't it be preferable to fix the root cause?
> >
> >Definitely that would be the best and IIRC I have tried to convince 
> >our
> >qemu guy to do that but they have never done that.
> 
> What is the exact failure condition? Is it simply that the test is 
> still
> slightly too strict about which delays it accepts, or is sleep 
> outright
> broken?
> 
> You can use command-line option -k to avoid some tests. For example 
> "-k not
> sleep". That way, we don't have to hard-code the dependency into the 
> test
> source. Depending on the root cause (issue in U-Boot, or issue in 
> just your
> local version of qemu, or something that will never work) this might 
> be
> better?
> >>>
> >>>Even with the most recent relaxing of the sleep test requirements, I 
> >>>can
> >>>still (depending on overall system load) have 'sleep' take too long, on
> >>>QEMU.  I think it might have been half a second slow, but I don't have
> >>>the log handy anymore.  Both locally and in travis we -k not sleep all
> >>>of the qemu instances.
> >>
> >>ok. By locally do you mean just using -k not sleep?
> >
> >Yes, I have that in my CI scripts and similar.
> 
> Wouldn't be easier to keep this in uboot-test-hooks repo with other
> target setting?
> >>>
> >>>Or do as you did did and mark the tests as not allowed for qemu, yes.
> >>>
> What we are trying to do is that our testing group will run these tests
> for me that's why it is just easier for me to change local
> uboot-test-hooks repo instead of communicate with them what -k not XXX
> parameters to add to certain scripts.
> 
> It means in loop they will just run all tests on qemu, local targets and
> in boardfarm. It is probably not big deal to tell them to add -k not
> sleep for all qemu runs but I know that for some i2c testing qemu
> doesn't emulate these devices that's why these tests fails. And the
> amount of tests which we shouldn't run on qemu will probably grow.
> >>>
> >>>Well, I'm still open to possibly tweaking the allowed variance in the
> >>>sleep test.  OTOH, if we just say "no QEMU" here, we can then go back to
> >>>"sleep should be pretty darn accurate on HW" for the test too, and
> >>>perhaps that's best.
> >>
> >>The fundamental problem of "over-sleeping" due to host system load/.. exists
> >>with all boards. There's nothing specific to qemu here except that running
> >>U-Boot on qemu on the host rather than on separate HW might more easily
> >>trigger the "high load on the host" condition; I see the issue now and then
> >>and manually retry that test, although that is a bit annoying.
> >>
> >>The original test was mostly intended to make sure that e U-Boot clock
> >>didn't run at a significantly different rate to the host, since I had seen
> >>that issue during development of some board support or as a regression
> >>sometime. Perhaps the definition of "significantly different" should be more
> >>like "1/2 rate or twice rate or more" rather than "off by a small fraction
> >>of a second". That might avoid so many false positives.
> >
> >I've pushed this up to 10 seconds and 0.5s worth of overrun and on
> >qemu-mips here I see a 13.2s sleep.  That's pretty close to 1/3rd fast
> >and to me a wrong-clocking value, yes?
> 
> For me the qemu-x86 build of mid-Nov commit of U-Boot running under the same
> qemu version that U-Boot's Travis CI builds use, "sleep 10" takes about 10.5
> seconds (including my reaction time), so ~13.2 does sound like it's probably
> a bug. Or maybe qemu just isn't fast enough in its emulation to keep up with
> real-time? I'd hope not for something simple like this, assuming you're
> using a recent CPU, but maybe.

Yeah, I can do x86, ARM and PowerPC but it fails on MIPS.  And my build
box isn't super new but an 8core/16thread E5-2670 should be good enough
:)

Hey Daniel, do you have test.py running on real MIPS hardware?  Thanks!

-- 
Tom


signature.asc
Description: PGP signature

Re: [U-Boot] [RFC PATCH] test: py: Disable sleep test for qemu targets

2017-12-05 Thread Stephen Warren 

On 12/04/2017 04:21 PM, Tom Rini wrote:

On Mon, Dec 04, 2017 at 10:14:06AM -0700, Stephen Warren wrote:

On 12/04/2017 08:30 AM, Tom Rini wrote:

On Mon, Dec 04, 2017 at 03:21:04PM +0100, Michal Simek wrote:

On 4.12.2017 15:03, Tom Rini wrote:

On Mon, Dec 04, 2017 at 02:55:45PM +0100, Michal Simek wrote:

On 1.12.2017 23:44, Tom Rini wrote:

On Fri, Dec 01, 2017 at 10:07:54AM -0700, Stephen Warren wrote:

On 12/01/2017 08:19 AM, Michal Simek wrote:

Hi,

On 1.12.2017 16:06, Heinrich Schuchardt wrote:



On 12/01/2017 03:46 PM, Michal Simek wrote:

Qemu for arm32/arm64 has a problem with time setup.


Wouldn't it be preferable to fix the root cause?


Definitely that would be the best and IIRC I have tried to convince our
qemu guy to do that but they have never done that.


What is the exact failure condition? Is it simply that the test is still
slightly too strict about which delays it accepts, or is sleep outright
broken?

You can use command-line option -k to avoid some tests. For example "-k not
sleep". That way, we don't have to hard-code the dependency into the test
source. Depending on the root cause (issue in U-Boot, or issue in just your
local version of qemu, or something that will never work) this might be
better?


Even with the most recent relaxing of the sleep test requirements, I can
still (depending on overall system load) have 'sleep' take too long, on
QEMU.  I think it might have been half a second slow, but I don't have
the log handy anymore.  Both locally and in travis we -k not sleep all
of the qemu instances.


ok. By locally do you mean just using -k not sleep?


Yes, I have that in my CI scripts and similar.


Wouldn't be easier to keep this in uboot-test-hooks repo with other
target setting?


Or do as you did did and mark the tests as not allowed for qemu, yes.


What we are trying to do is that our testing group will run these tests
for me that's why it is just easier for me to change local
uboot-test-hooks repo instead of communicate with them what -k not XXX
parameters to add to certain scripts.

It means in loop they will just run all tests on qemu, local targets and
in boardfarm. It is probably not big deal to tell them to add -k not
sleep for all qemu runs but I know that for some i2c testing qemu
doesn't emulate these devices that's why these tests fails. And the
amount of tests which we shouldn't run on qemu will probably grow.


Well, I'm still open to possibly tweaking the allowed variance in the
sleep test.  OTOH, if we just say "no QEMU" here, we can then go back to
"sleep should be pretty darn accurate on HW" for the test too, and
perhaps that's best.


The fundamental problem of "over-sleeping" due to host system load/.. exists
with all boards. There's nothing specific to qemu here except that running
U-Boot on qemu on the host rather than on separate HW might more easily
trigger the "high load on the host" condition; I see the issue now and then
and manually retry that test, although that is a bit annoying.

The original test was mostly intended to make sure that e U-Boot clock
didn't run at a significantly different rate to the host, since I had seen
that issue during development of some board support or as a regression
sometime. Perhaps the definition of "significantly different" should be more
like "1/2 rate or twice rate or more" rather than "off by a small fraction
of a second". That might avoid so many false positives.


I've pushed this up to 10 seconds and 0.5s worth of overrun and on
qemu-mips here I see a 13.2s sleep.  That's pretty close to 1/3rd fast
and to me a wrong-clocking value, yes?


For me the qemu-x86 build of mid-Nov commit of U-Boot running under the 
same qemu version that U-Boot's Travis CI builds use, "sleep 10" takes 
about 10.5 seconds (including my reaction time), so ~13.2 does sound 
like it's probably a bug. Or maybe qemu just isn't fast enough in its 
emulation to keep up with real-time? I'd hope not for something simple 
like this, assuming you're using a recent CPU, but maybe.

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

Re: [U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

2017-12-05 Thread Stephen Warren 

On 12/05/2017 03:32 AM, Dr. Philipp Tomsich wrote:



On 4 Dec 2017, at 20:02, Stephen Warren  wrote:

On 12/02/2017 06:12 PM, Tom Rini wrote:

Move the warning to an error as we have been promising would happen in
this release.


Oh. This has broken my U-Boot build/test system. I guess it's entirely my fault for interpreting the 
"2018.01" warning as "you'll need to fix this in Jan 2018", not "you'll need to fix 
this as soon as development starts for 2018.01":-(

Is there a reason for requiring such an extremely new gcc, as opposed to simply 
something not ancient?


GCC-6 matches the definition of “not ancient”.
We’ve just gone to phase 3 on GCC-8 a few weeks back, so GCC-6 will be 2 years 
old in April.


I disagree here. LTS Ubuntu (as an example of one reasonable distro that 
one might use) is only released every 2 years, and multiple of them are 
fully supported in parallel (so older releases are also reasonable to 
use). A 2-year-old toolchain is just old enough that one single LTS 
distro release /might/ have picked it up (in this case, this hasn't 
happened yet). To me, "not ancient" means "not 5 years old or more", 
where "5" is somewhat arbitary and could easily be 5-10 say, but 
certainly not a very small number like 2.


FWIW, I managed to get my systems running using Linaro gcc-7.2.1 
2017.11. However, the process was annoying since the older internal 
U-Boot branches we still support don't support anything /newer/ than 
gcc-5 (even for releases only about 1.5 years old; U-Boot jumped forward 
on compilers extremely fast with little overlap in support), so I had to 
make my system use a different toolchain for different builds:-( At 
least I have the infrastructure in place for this for next time.

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

Re: [U-Boot] [PATCH 09/22] mtd: nand: automate NAND timings selection

2017-12-05 Thread York Sun 
On 12/04/2017 04:31 PM, Masahiro Yamada wrote:
>> Err:   serial
>> Net:
>> MMC read: dev # 0, block # 2080, count 128 ...
>> Fman1: Data at 7faf67d0 is not a firmware
>> e1000#0: Out of Memory!
> 
> 
> Looks like malloc() failed.
> 
> 
>> No ethernet found.
>> Hit any key to stop autoboot:  0
>> (York: Hit a key to stop the counting down here)
>> ERROR : memory not allocated
> 
> 
> This error message comes from xmalloc() or xrealloc().
> 
> 
> 
> I think your board grew in size by my commit.
> 
> 
> Does disabling some features solve your problem?
> 
I tried to disable USB feature and reduced the image size, but that
didn't fix this issue. I don't believe NAND driver has anything to do
with this issue though. I will keep debugging.

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

Re: [U-Boot] [PATCH V2] SPL: Add FIT data-position property support

2017-12-05 Thread York Sun 
On 12/04/2017 09:21 PM, Peng Fan wrote:
> For external data, FIT has a optional property "data-position" which
> can set the external data to a fixed offset to FIT beginning.
> Add the support for this property in SPL FIT.
> 
> Signed-off-by: Ye Li 
> Signed-off-by: Peng Fan 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tomas Melin 
> Cc: Pantelis Antoniou 
> Cc: "Andrew F. Davis" 
> Cc: Igor Grinberg 
> Cc: "tomas.me...@vaisala.com" 
> Cc: Kever Yang 
> Cc: Andre Przywara 
> Cc: York Sun 
> Cc: Lokesh Vutla 
> Cc: "Cooper Jr., Franklin" 
> Cc: George McCollister 
> Cc: Tuomas Tynkkynen 
> Cc: Jean-Jacques Hiblot 
> Cc: Rick Altherr 
> Cc: Tom Rini 
> ---
> 
> V2:
>  Add review tags
>  Per York's comments, add a piece text in source_file_format.txt.
> 
>  common/image-fit.c| 25 +
>  common/spl/spl_fit.c  | 11 +--
>  doc/uImage.FIT/source_file_format.txt |  3 ++-
>  include/image.h   |  3 +++
>  4 files changed, 39 insertions(+), 3 deletions(-)
> 

Reviewed-by: York Sun 

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

[U-Boot] [PATCH v2 4/4] fastboot: Enable flashing by default on sunxi

2017-12-05 Thread Maxime Ripard 
Now that more and more devices are built using eMMC, providing a way to
easily flash the system without too much hassle seems like a right thing to
do.

Since fastboot is the most deployed tool to do that these days, we can just
rely on it to provide a way to flash the various components in the system
(SPL, U-Boot and the system itself) easily, especially since you can upload
the U-Boot hosting the fastboot "server" through FEL.

Reviewed-by: Andre Przywara 
Signed-off-by: Maxime Ripard 
---
 cmd/fastboot/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cmd/fastboot/Kconfig b/cmd/fastboot/Kconfig
index 4ce7a775e28e..cbb9183ea266 100644
--- a/cmd/fastboot/Kconfig
+++ b/cmd/fastboot/Kconfig
@@ -66,6 +66,7 @@ config FASTBOOT_USB_DEV
 
 config FASTBOOT_FLASH
bool "Enable FASTBOOT FLASH command"
+   default y if ARCH_SUNXI
help
  The fastboot protocol includes a "flash" command for writing
  the downloaded image to a non-volatile storage device. Define
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/4] part: efi: Add default number of partition entries for sunxi

2017-12-05 Thread Maxime Ripard 
The SPL must be located at 8kB (16 sectors) offset. That's right in the
middle of the GPT, so we need to define a smaller amount of partitions to
accomodate for that location.

Reviewed-by: Andre Przywara 
Signed-off-by: Maxime Ripard 
---
 disk/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/disk/Kconfig b/disk/Kconfig
index f82beef6e689..0446bb63ca7e 100644
--- a/disk/Kconfig
+++ b/disk/Kconfig
@@ -81,6 +81,7 @@ config EFI_PARTITION
 config EFI_PARTITION_ENTRIES_NUMBERS
int "Number of the EFI partition entries"
depends on EFI_PARTITION
+   default 56 if ARCH_SUNXI
default 128
help
  Specify the number of partition entries in the GPT. This is
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2017-12-05 Thread Maxime Ripard 
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 | 17 +
 1 file changed, 17 insertions(+)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 4391a8cbc824..786155f1e15e 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -493,6 +493,20 @@ extern int soft_i2c_gpio_scl;
 #define SUNXI_MTDPARTS_DEFAULT
 #endif
 
+#define PARTS_DEFAULT \
+   "name=loader1,start=8k,size=32k,uuid=${uuid_gpt_loader1};" \
+   "name=loader2,size=984k,uuid=${uuid_gpt_loader2};" \
+   "name=esp,size=128M,bootable,uuid=${uuid_gpt_esp};" \
+   "name=system,size=-,uuid=${uuid_gpt_system};"
+
+#define UUID_GPT_ESP "c12a7328-f81f-11d2-ba4b-00a0c93ec93b"
+
+#ifdef CONFIG_ARM64
+#define UUID_GPT_SYSTEM "b921b045-1df0-41c3-af44-4c6f280d3fae"
+#else
+#define UUID_GPT_SYSTEM "69dad710-2ce4-4e3c-b16c-21a1d49abed3"
+#endif
+
 #define CONSOLE_ENV_SETTINGS \
CONSOLE_STDIN_SETTINGS \
CONSOLE_STDOUT_SETTINGS
@@ -511,6 +525,9 @@ extern int soft_i2c_gpio_scl;
"console=ttyS0,115200\0" \
SUNXI_MTDIDS_DEFAULT \
SUNXI_MTDPARTS_DEFAULT \
+   "uuid_gpt_esp=" UUID_GPT_ESP "\0" \
+   "uuid_gpt_system=" UUID_GPT_SYSTEM "\0" \
+   "partitions=" PARTS_DEFAULT "\0" \
BOOTCMD_SUNXI_COMPAT \
BOOTENV
 
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 1/4] part: efi: Add a Kconfig option for the number of partition entries

2017-12-05 Thread Maxime Ripard 
On some SoCs, the SPL needs to be located right in the middle of the GPT
partition entries.

One way to work around that is to create partition entries for a smaller
number of partitions to accomodate with where the SPL will be. Create a
Kconfig option to allow to do that.

Reviewed-by: Andre Przywara 
Reviewed-by: Tom Rini 
Signed-off-by: Maxime Ripard 
---
 disk/Kconfig   | 13 +
 include/part_efi.h |  2 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/disk/Kconfig b/disk/Kconfig
index 939656212065..f82beef6e689 100644
--- a/disk/Kconfig
+++ b/disk/Kconfig
@@ -78,6 +78,19 @@ config EFI_PARTITION
  common when EFI is the bootloader.  Note 2TB partition limit;
  see disk/part_efi.c
 
+config EFI_PARTITION_ENTRIES_NUMBERS
+   int "Number of the EFI partition entries"
+   depends on EFI_PARTITION
+   default 128
+   help
+ Specify the number of partition entries in the GPT. This is
+ meant to allow less than the standard specifies for devices
+ that might need to place their first-stage bootloader in the
+ middle of a regular GPT.
+
+ If unsure, leave at 128 entries, which is the standard
+ number.
+
 config EFI_PARTITION_ENTRIES_OFF
 int "Offset (in bytes) of the EFI partition entries"
depends on EFI_PARTITION
diff --git a/include/part_efi.h b/include/part_efi.h
index 31e6bc6e140f..4c8f6cc473c8 100644
--- a/include/part_efi.h
+++ b/include/part_efi.h
@@ -27,7 +27,7 @@
 #define GPT_HEADER_SIGNATURE 0x5452415020494645ULL
 #define GPT_HEADER_REVISION_V1 0x0001
 #define GPT_PRIMARY_PARTITION_TABLE_LBA 1ULL
-#define GPT_ENTRY_NUMBERS  128
+#define GPT_ENTRY_NUMBERS  CONFIG_EFI_PARTITION_ENTRIES_NUMBERS
 #define GPT_ENTRY_SIZE 128
 
 #define PARTITION_SYSTEM_GUID \
-- 
git-series 0.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

2017-12-05 Thread Maxime Ripard 
Hi,

Here is a set of patches that have been sitting in some variations for
quite some time now.

This is mostly to ease the eMMC (and MMC, to some extent) flashing
using fastboot that in turn rely on GPT.

The Allwinner SoCs need to have the SPL located right in the middle of
a traditional GPT, at 8kB.

To deal with this, we would basically have two options:
  - Use the already in-tree solution to move the partition entries to
another arbitrary offset in the MMC.
  - Use a smaller number of partitions entries

Both are non-standards, but are dealt with nicely by the regular tools
and users (at least on a Linux system). However, the first solution is
quite confusing for users (that needs to be aware where the partitions
will be), might be less flexible because not all tools will allow to
create partitions for things between the GPT main entry and the
partition entries, and might confuse tools if such a setup is
available.

In our case, using the first solution, gdisk will for example refuse
to create a partition for the SPL.

The second solution though seems to be well handled by all the tools,
and just feels the same, except that you end up with a smaller number
of partitions. In our case, that number is 56 partitions (16 sectors
before the SPL, 1 sector for the protective MBR, 1 sector for the GPT
header, and 4 partition entries per sector) instead of 128, which
doesn't sound very impractical either.

The two first patches deal with that.

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.

Finally, we enable fastboot flashing to be able to flash a pristine
system just by using FEL, fastboot oem format, and then fastboot flash
for the various components.

Let me know what you think,
Maxime

Changes from v2:
  - Added Andre's tags
  - Rebased on 2018.01-rc1
  - Changed the rootfs UUID for freedesktop's

Changes from v1:
  - Changed the boot partition name to ESP
  - Used default UUID for the rootfs and esp partitions

Maxime Ripard (4):
  part: efi: Add a Kconfig option for the number of partition entries
  part: efi: Add default number of partition entries for sunxi
  sunxi: Add default partition scheme
  fastboot: Enable flashing by default on sunxi

 cmd/fastboot/Kconfig   |  1 +
 disk/Kconfig   | 14 ++
 include/configs/sunxi-common.h | 17 +
 include/part_efi.h |  2 +-
 4 files changed, 33 insertions(+), 1 deletion(-)

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

Re: [U-Boot] u-boot Licensing exception with OpenSSL

2017-12-05 Thread Vagrant Cascadian 
On 2017-12-04, Tom Rini wrote:
> On Sat, Nov 25, 2017 at 12:50:47PM -0800, Vagrant Cascadian wrote:
>
>> There are a few targets (clearfog, turris_omnia) and features (signing
>> in mkimage) in the Debian build of u-boot that have been avoided due to
>> lack of clarity on Licensing issues regarding GPL and OpenSSL
>> compatibility issues.
...
> So, the most likely thing that could be accomplished (as I don't see how
> we could add exemptions without some legal consult) would be to re-write
> the small areas in question to use libgnutls rather than openssl for
> checking the certificates, etc.

Thanks for the response!

Yes, adding an exception would require, at the very least, tracking down
all copyright holders to the portions of the code that include openssl
headers and/or code...

Switching to gnutls would definitely be an ideal solution from my
perspective packaging u-boot in Debian, though I'm not sure I can
personally commit to making it happen.

A rough starting point for which code may need to be modified:

  $ git grep -i include.*openssl
  include/image.h:# include  
  lib/rsa/rsa-sign.c:#include 
  lib/rsa/rsa-sign.c:#include 
  lib/rsa/rsa-sign.c:#include 
  lib/rsa/rsa-sign.c:#include 
  lib/rsa/rsa-sign.c:#include 
  lib/rsa/rsa-sign.c:#include 
  lib/rsa/rsa-sign.c:#include 
  tools/kwbimage.c:#include 
  tools/kwbimage.c:#include 
  tools/kwbimage.c:#include 
  tools/kwbimage.c:#include 
  tools/kwbimage.c:#include 
  tools/mxsimage.c:#include 


live well,
  vagrant


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

Re: [U-Boot] [RFC PATCH] test: py: Disable sleep test for qemu targets

2017-12-05 Thread Tom Rini 
On Tue, Dec 05, 2017 at 01:10:47PM +0100, Michal Simek wrote:
> On 4.12.2017 18:14, Stephen Warren wrote:
> > On 12/04/2017 08:30 AM, Tom Rini wrote:
> >> On Mon, Dec 04, 2017 at 03:21:04PM +0100, Michal Simek wrote:
> >>> On 4.12.2017 15:03, Tom Rini wrote:
>  On Mon, Dec 04, 2017 at 02:55:45PM +0100, Michal Simek wrote:
> > On 1.12.2017 23:44, Tom Rini wrote:
> >> On Fri, Dec 01, 2017 at 10:07:54AM -0700, Stephen Warren wrote:
> >>> On 12/01/2017 08:19 AM, Michal Simek wrote:
>  Hi,
> 
>  On 1.12.2017 16:06, Heinrich Schuchardt wrote:
> >
> >
> > On 12/01/2017 03:46 PM, Michal Simek wrote:
> >> Qemu for arm32/arm64 has a problem with time setup.
> >
> > Wouldn't it be preferable to fix the root cause?
> 
>  Definitely that would be the best and IIRC I have tried to
>  convince our
>  qemu guy to do that but they have never done that.
> >>>
> >>> What is the exact failure condition? Is it simply that the test
> >>> is still
> >>> slightly too strict about which delays it accepts, or is sleep
> >>> outright
> >>> broken?
> >>>
> >>> You can use command-line option -k to avoid some tests. For
> >>> example "-k not
> >>> sleep". That way, we don't have to hard-code the dependency into
> >>> the test
> >>> source. Depending on the root cause (issue in U-Boot, or issue in
> >>> just your
> >>> local version of qemu, or something that will never work) this
> >>> might be
> >>> better?
> >>
> >> Even with the most recent relaxing of the sleep test requirements,
> >> I can
> >> still (depending on overall system load) have 'sleep' take too
> >> long, on
> >> QEMU.  I think it might have been half a second slow, but I don't
> >> have
> >> the log handy anymore.  Both locally and in travis we -k not sleep
> >> all
> >> of the qemu instances.
> >
> > ok. By locally do you mean just using -k not sleep?
> 
>  Yes, I have that in my CI scripts and similar.
> >>>
> >>> Wouldn't be easier to keep this in uboot-test-hooks repo with other
> >>> target setting?
> >>
> >> Or do as you did did and mark the tests as not allowed for qemu, yes.
> >>
> >>> What we are trying to do is that our testing group will run these tests
> >>> for me that's why it is just easier for me to change local
> >>> uboot-test-hooks repo instead of communicate with them what -k not XXX
> >>> parameters to add to certain scripts.
> >>>
> >>> It means in loop they will just run all tests on qemu, local targets and
> >>> in boardfarm. It is probably not big deal to tell them to add -k not
> >>> sleep for all qemu runs but I know that for some i2c testing qemu
> >>> doesn't emulate these devices that's why these tests fails. And the
> >>> amount of tests which we shouldn't run on qemu will probably grow.
> >>
> >> Well, I'm still open to possibly tweaking the allowed variance in the
> >> sleep test.  OTOH, if we just say "no QEMU" here, we can then go back to
> >> "sleep should be pretty darn accurate on HW" for the test too, and
> >> perhaps that's best.
> > 
> > The fundamental problem of "over-sleeping" due to host system load/..
> > exists with all boards. There's nothing specific to qemu here except
> > that running U-Boot on qemu on the host rather than on separate HW might
> > more easily trigger the "high load on the host" condition; I see the
> > issue now and then and manually retry that test, although that is a bit
> > annoying.
> > 
> > The original test was mostly intended to make sure that e U-Boot clock
> > didn't run at a significantly different rate to the host, since I had
> > seen that issue during development of some board support or as a
> > regression sometime. Perhaps the definition of "significantly different"
> > should be more like "1/2 rate or twice rate or more" rather than "off by
> > a small fraction of a second". That might avoid so many false positives.
> 
> We had this issue with silicon v1 and having accurate sleep measuring is
> definitely good thing to have (Probably make sense to enable margin
> setup via variable anyway).
> 
> But still I would extend this to more wider discussion how to disable
> just one particular test case which is verified that it is broken on
> certain target/target configuration.
> Using -k not XXX option is possible but as I said before it is not ideal
> to keep track of these problematic tests in two locations and share this
> between two teams.
> 
> Better would be to add to u_boot_boardenv...py file line like this
> skip_test_sleep = True
> 
> Which would be parsed and test won't run for specific board/configuration.
> The same logic can be generic that user can add for example
> skip_test_net_dhcp = True
> to skip dhcp test for whatever reason.
> 
> Then for travis-ci we can just put these lines to py/travis-ci/.
> 
> What do you think?

Ah, good

Re: [U-Boot] [PATCH] gpt: add part-uuid and part-num subcommands

2017-12-05 Thread Lukasz Majewski 
Hi Andrey,

> On Mon, Dec 4, 2017 at 1:12 PM, Lukasz Majewski
>  wrote:
> > Hi Andrey,
> >  
> >> Hi Lukasz,
> >>
> >> On Tue, Nov 14, 2017 at 1:45 AM, Lukasz Majewski
> >>  wrote:  
> >> > Hi Andrey,
> >> >  
> >> >> Hi Lukasz,
> >> >>
> >> >> On Thu, Nov 9, 2017 at 2:28 PM, Lukasz Majewski
> >> >>  wrote:  
> >> >> > On Thu, 9 Nov 2017 07:34:44 -0800
> >> >> > Andrey Yurovsky  wrote:
> >> >> >  
> >> >> >> On Thu, Nov 9, 2017 at 1:55 AM, Lukasz Majewski
> >> >> >>  wrote:  
> >> >> >> > Hi Andrey,
> >> >> >> >  
> >> >> >> >> Hi Otavio,
> >> >> >> >>
> >> >> >> >> On Wed, Nov 8, 2017 at 2:47 AM, Otavio Salvador
> >> >> >> >>  wrote:  
> >> >> >> >> > On Tue, Nov 7, 2017 at 10:43 PM, your name
> >> >> >> >> >  wrote:  
> >> >> >> >> >> From: Andrey Yurovsky 
> >> >> >> >> >>
> >> >> >> >> >> It is useful to be able to retrieve a partition UUID or
> >> >> >> >> >> number given the partition label, for instance some
> >> >> >> >> >> systems use the partition label to indicate the purpose
> >> >> >> >> >> of the partition (such as "rootfs0" being the 0th root
> >> >> >> >> >> file system in an A/B image scheme).
> >> >> >> >> >>
> >> >> >> >> >> Add "gpt part-uuid" to retrieve the partition UUID for
> >> >> >> >> >> a given label and "gpt part-num" to retrieve the
> >> >> >> >> >> partition number for a given label along with some
> >> >> >> >> >> documentation.
> >> >> >> >> >>
> >> >> >> >> >> Signed-off-by: Andrey Yurovsky   
> >> >> >> >> >
> >> >> >> >> > Why not use the 'part' cmd? it provides it.  
> >> >> >> >>
> >> >> >> >> Sorry, I missed the part cmd, it doesn't seem to be
> >> >> >> >> documented in doc/ and it's unclear what  means
> >> >> >> >> there.  
> >> >> >> >
> >> >> >> > If I may ask - Andrey, if you are now on this "topic" -
> >> >> >> > would you dare to add some ./doc entry for 'part'
> >> >> >> > command?  
> >> >> >>
> >> >> >> Yes, I will do that.  
> >> >> >
> >> >> > Thanks :-)  
> >> >>
> >> >> On further investigation I am not sure that it's possible to
> >> >> extend the part command to retrieve UUIDs by label because of
> >> >> the design of the partition type drivers. Here is how I
> >> >> understand it to work: 1. the "part" command uses
> >> >> part_get_info() and in turn gets a partition driver and can
> >> >> call print() there (which is how EFI/GPT disks are printed with
> >> >> "part list"). The right information (including label) is
> >> >> printed but it's not tied to the caller in any way.  
> >> >
> >> > Maybe you can set some env variable with proper data?
> >> >
> >> > For example, please refer to ./cmd/part.c do_part_start()
> >> > function.
> >> >
> >> > Example call from envs (include/configs/display5.h):
> >> > "part start mmc ${mmcdev} ${kernel_part} lba_start; " \
> >> >  
> >>
> >> Again that assumes the partition is referred to by number, I need
> >> it to be by label, and the part/disk interface does not seem to
> >> have any way to utilize labels. Unfortunately it looks like my
> >> original approach with the gpt command is the only way to
> >> implement this with the current design (at least from what I see
> >> here). Please let me know if I've missed something. Thanks!  
> >
> > Please correct me if I'm wrong - you need the starting LBA of the
> > partition named e.g. "FOO" in gpt ?
> >
> > Conceptually it would be correct to have:
> >
> > part start
> > gpt start
> >
> > If your code is really _small_ and can be used only with GPT, then
> > lets go for the second option.  
> 
> The use cases I have in mind:
> 
> 1. determine which root file system to use by label, let's say
> "rootfs1" and pass its UUID to the Linux kernel via the command line,
> ex: "PART-UUID=${uuid}". To do this we need a way to ask for a UUID
> corresponding to a label in the partition table (given duplicate
> labels, assume it gives us the first or last match).

I see. I thought that you need start LBA.

From your use case it seems like extending the 'gpt' command is the
right thing to do - since already some uuid handling is done there.

> 2. determine which file system to load a file from (ex: fatload) given
> a label. 

There is a group of generic commands - like load, ls, etc.

> I'm not sure that the starting LBA is helpful here, we really
> are looking to map a label to a partition number in the table.

If you are using GPT, then you also may want to extend the 'gpt'
command -> iterate through PTEs and when label matched, return the part
number. With it you can use e.g. load mmc 0  file.

> 
> The implementation of "part start" interprets the argument as a
> partition number, so I can get the stating LBA if I know the partition
> number but I don't see a way (via cmd/disk.c) to get anything useful
> if all I know is a label, and that is what I'm trying to

Re: [U-Boot] U-Boot for Firetux PNX8181 board

2017-12-05 Thread Lukasz Majewski 
On Tue, 5 Dec 2017 11:50:19 + (UTC)
"A.W.C."  wrote:

> Where to download U-boot source customized for Firetux PNX8181 board?
> (ARM926EJS) 
> 
> mentioned in
> 
> https://lists.denx.de/pipermail/u-boot/2009-January/045332.html

It is _old_ stuff...

Please find following link:
http://ftp.denx.de/pub/u-boot/u-boot-2009.01.tar.bz2

(Other versions in the same directory).

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



Best regards,

Lukasz Majewski

--

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


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

Re: [U-Boot] [PATCH v2 0/5] sunxi: Enable EMAC on various boards

2017-12-05 Thread Chen-Yu Tsai 
Hi,

On Sat, Nov 25, 2017 at 1:08 PM, Chen-Yu Tsai  wrote:
> Hi,
>
> This series enables the EMAC for some A83T and A64 boards.
>
> Changes since v1:
>
>   - Added "bitfield: Include linux/bitops.h for ffs()" to fix build
> errors
>   - Use bitfield_replace_by_mask() instead of open coding bitfield ops
>   - Trimmed used pins in the device tree to only those actually needed
>   - Enabled Realtek PHY driver
>   - Added "sunxi: Enable EMAC on the Bananapi M64"
>
> ChenYu
>
>
> Chen-Yu Tsai (5):
>   bitfield: Include linux/bitops.h for ffs()
>   net: sun8i_emac: Support RX/TX delay chains
>   sunxi: Enable EMAC on the Cubietruck Plus
>   sunxi: Enable EMAC on the Bananapi M3
>   sunxi: Enable EMAC on the Bananapi M64

Any comments (particularly two the first two patches) on this series?
Joe?

ChenYu

>
>  arch/arm/dts/sun50i-a64-bananapi-m64-u-boot.dtsi   | 39 +
>  arch/arm/dts/sun8i-a83t-bananapi-m3-u-boot.dtsi| 40 
> ++
>  .../arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi | 38 
>  configs/Cubietruck_plus_defconfig  |  2 ++
>  configs/Sinovoip_BPI_M3_defconfig  |  2 ++
>  drivers/net/sun8i_emac.c   | 22 
>  include/bitfield.h |  1 +
>  7 files changed, 144 insertions(+)
>  create mode 100644 arch/arm/dts/sun50i-a64-bananapi-m64-u-boot.dtsi
>  create mode 100644 arch/arm/dts/sun8i-a83t-bananapi-m3-u-boot.dtsi
>  create mode 100644 arch/arm/dts/sun8i-a83t-cubietruck-plus-u-boot.dtsi
>
> --
> 2.15.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

2017-12-05 Thread Tom Rini 
On Tue, Dec 05, 2017 at 06:02:16AM +0100, Heiko Schocher wrote:
> Hello Tom, Stephen,
> 
> Am 04.12.2017 um 20:02 schrieb Stephen Warren:
> >On 12/02/2017 06:12 PM, Tom Rini wrote:
> >>Move the warning to an error as we have been promising would happen in
> >>this release.
> >
> >Oh. This has broken my U-Boot build/test system. I guess it's entirely my
> >fault for interpreting the "2018.01" warning as "you'll need to fix this
> >in Jan 2018", not "you'll need to fix this as soon as development starts
> >for 2018.01":-(
> 
> Yes, all my U-Boot tbot builds tonight failed :-(
> 
> I use eldk-5.8 (gcc 4.9.2) or I fetch toolchain with
> buildman from kernel org:
> 
> pollux:u-boot hs [ubi-rework] $ ./tools/buildman/buildman --fetch-arch arm
> 
> Downloading toolchain for arch 'arm'
> Checking: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/
> Downloading: 
> https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.9.0/x86_64-gcc-4.9.0-nolibc_arm-unknown-linux-gnueabi.tar.xz
> Unpacking to: /home/hs/.buildman-toolchains
> Testing
>   - looking in 
> '/home/hs/.buildman-toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/.'
>   - looking in 
> '/home/hs/.buildman-toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin'
>  - found 
> '/home/hs/.buildman-toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc'
>   - looking in 
> '/home/hs/.buildman-toolchains/gcc-4.9.0-nolibc/arm-unknown-linux-gnueabi/usr/bin'
> Tool chain test:  OK, arch='arm', priority 4
> pollux:u-boot hs [ubi-rework] $
> 
> Which has gcc 4.9.0 ...

I guess it's time, really, to make buildman fetch from the free
electrons toolchains instead of the old kernel.org ones, can you take a
pass at that?  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] [RFC PATCH] test: py: Disable sleep test for qemu targets

2017-12-05 Thread Michal Simek 
On 4.12.2017 18:14, Stephen Warren wrote:
> On 12/04/2017 08:30 AM, Tom Rini wrote:
>> On Mon, Dec 04, 2017 at 03:21:04PM +0100, Michal Simek wrote:
>>> On 4.12.2017 15:03, Tom Rini wrote:
 On Mon, Dec 04, 2017 at 02:55:45PM +0100, Michal Simek wrote:
> On 1.12.2017 23:44, Tom Rini wrote:
>> On Fri, Dec 01, 2017 at 10:07:54AM -0700, Stephen Warren wrote:
>>> On 12/01/2017 08:19 AM, Michal Simek wrote:
 Hi,

 On 1.12.2017 16:06, Heinrich Schuchardt wrote:
>
>
> On 12/01/2017 03:46 PM, Michal Simek wrote:
>> Qemu for arm32/arm64 has a problem with time setup.
>
> Wouldn't it be preferable to fix the root cause?

 Definitely that would be the best and IIRC I have tried to
 convince our
 qemu guy to do that but they have never done that.
>>>
>>> What is the exact failure condition? Is it simply that the test
>>> is still
>>> slightly too strict about which delays it accepts, or is sleep
>>> outright
>>> broken?
>>>
>>> You can use command-line option -k to avoid some tests. For
>>> example "-k not
>>> sleep". That way, we don't have to hard-code the dependency into
>>> the test
>>> source. Depending on the root cause (issue in U-Boot, or issue in
>>> just your
>>> local version of qemu, or something that will never work) this
>>> might be
>>> better?
>>
>> Even with the most recent relaxing of the sleep test requirements,
>> I can
>> still (depending on overall system load) have 'sleep' take too
>> long, on
>> QEMU.  I think it might have been half a second slow, but I don't
>> have
>> the log handy anymore.  Both locally and in travis we -k not sleep
>> all
>> of the qemu instances.
>
> ok. By locally do you mean just using -k not sleep?

 Yes, I have that in my CI scripts and similar.
>>>
>>> Wouldn't be easier to keep this in uboot-test-hooks repo with other
>>> target setting?
>>
>> Or do as you did did and mark the tests as not allowed for qemu, yes.
>>
>>> What we are trying to do is that our testing group will run these tests
>>> for me that's why it is just easier for me to change local
>>> uboot-test-hooks repo instead of communicate with them what -k not XXX
>>> parameters to add to certain scripts.
>>>
>>> It means in loop they will just run all tests on qemu, local targets and
>>> in boardfarm. It is probably not big deal to tell them to add -k not
>>> sleep for all qemu runs but I know that for some i2c testing qemu
>>> doesn't emulate these devices that's why these tests fails. And the
>>> amount of tests which we shouldn't run on qemu will probably grow.
>>
>> Well, I'm still open to possibly tweaking the allowed variance in the
>> sleep test.  OTOH, if we just say "no QEMU" here, we can then go back to
>> "sleep should be pretty darn accurate on HW" for the test too, and
>> perhaps that's best.
> 
> The fundamental problem of "over-sleeping" due to host system load/..
> exists with all boards. There's nothing specific to qemu here except
> that running U-Boot on qemu on the host rather than on separate HW might
> more easily trigger the "high load on the host" condition; I see the
> issue now and then and manually retry that test, although that is a bit
> annoying.
> 
> The original test was mostly intended to make sure that e U-Boot clock
> didn't run at a significantly different rate to the host, since I had
> seen that issue during development of some board support or as a
> regression sometime. Perhaps the definition of "significantly different"
> should be more like "1/2 rate or twice rate or more" rather than "off by
> a small fraction of a second". That might avoid so many false positives.

We had this issue with silicon v1 and having accurate sleep measuring is
definitely good thing to have (Probably make sense to enable margin
setup via variable anyway).

But still I would extend this to more wider discussion how to disable
just one particular test case which is verified that it is broken on
certain target/target configuration.
Using -k not XXX option is possible but as I said before it is not ideal
to keep track of these problematic tests in two locations and share this
between two teams.

Better would be to add to u_boot_boardenv...py file line like this
skip_test_sleep = True

Which would be parsed and test won't run for specific board/configuration.
The same logic can be generic that user can add for example
skip_test_net_dhcp = True
to skip dhcp test for whatever reason.

Then for travis-ci we can just put these lines to py/travis-ci/.

What do you think?

Thanks,
Michal









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

[U-Boot] U-Boot for Firetux PNX8181 board

2017-12-05 Thread A.W.C. 

Where to download U-boot source customized for Firetux PNX8181 board? 
(ARM926EJS) 

mentioned in

https://lists.denx.de/pipermail/u-boot/2009-January/045332.html

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

Re: [U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

2017-12-05 Thread Peter Robinson 
On Tue, Dec 5, 2017 at 6:53 AM, Heiko Schocher  wrote:
> Hello Tom,
>
> Am 04.12.2017 um 20:09 schrieb Tom Rini:
>>
>> On Mon, Dec 04, 2017 at 12:02:20PM -0700, Stephen Warren wrote:
>>>
>>> On 12/02/2017 06:12 PM, Tom Rini wrote:

 Move the warning to an error as we have been promising would happen in
 this release.
>>>
>>>
>>> Oh. This has broken my U-Boot build/test system. I guess it's entirely my
>>> fault for interpreting the "2018.01" warning as "you'll need to fix this
>>> in
>>> Jan 2018", not "you'll need to fix this as soon as development starts for
>>> 2018.01":-(
>>
>>
>> I'm tagging v2018.01-rc1 later today, so I think this is about the time
>> to enforce the warning.
>>
>>> Is there a reason for requiring such an extremely new gcc, as opposed to
>>> simply something not ancient? For example, no LTS version of Ubuntu
>>> packages
>>> a compiler that's new enough to build U-Boot now:-(
>>
>>
>> There's always the Free Electrons toolchains, as well as Linaro.  And
>> yes, we've been having size problems and having to play various games to
>
>
> Yes, I have the AT91 based smartweb board, for which the SPL have to fit
> into 4k sram (is in my weekly tbot builds).
>
>> allow for older gcc versions to still fit things in.  GCC-6 is where
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 was resolved and we
>> get a lot of space saved, and a number of platforms simply won't work
>> with older.
>
>
> Just looked at:
>
> http://toolchains.free-electrons.com/
>
> for example the stable toolchains for arm are gcc 5.4.0 based.
>
> Ok, there is the "bleeding-edge" ... gcc 7.2.0 based...
>
> Hmm.. linaro has 7.2.0 in its latest release ... so, currently only
> linaro toolchain can be used for compiling U-Boot ?

I've been using gcc 7.x in Fedora since the beginning of the year to
build u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot,v3,1/1] add support for Raspberry Pi Zero W

2017-12-05 Thread Dmitry Korunov 
Great, thanks!

On Dec 4, 2017 10:36 PM, "Tom Rini"  wrote:

On Sun, Nov 26, 2017 at 01:38:53PM +0400, Dmitry Korunov wrote:

> Signed-off-by: Dmitry Korunov 

Applied to u-boot/master, thanks!

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

Re: [U-Boot] [PATCH] arm: Make gcc 6.0 or later a hard requirement now.

2017-12-05 Thread Dr. Philipp Tomsich 

> On 4 Dec 2017, at 20:02, Stephen Warren  wrote:
> 
> On 12/02/2017 06:12 PM, Tom Rini wrote:
>> Move the warning to an error as we have been promising would happen in
>> this release.
> 
> Oh. This has broken my U-Boot build/test system. I guess it's entirely my 
> fault for interpreting the "2018.01" warning as "you'll need to fix this in 
> Jan 2018", not "you'll need to fix this as soon as development starts for 
> 2018.01":-(
> 
> Is there a reason for requiring such an extremely new gcc, as opposed to 
> simply something not ancient?

GCC-6 matches the definition of “not ancient”.
We’ve just gone to phase 3 on GCC-8 a few weeks back, so GCC-6 will be 2 years 
old in April.

Usually, toolchains for embedded targets are maintained on a “stable” and “one 
behind-stable” basis.
Which already makes GCC-6 the oldest toolchain that will receive backports.  
For example, Linaro now has GCC-6 and GCC-7 trees and will retire the GCC-6 
tree once GCC-8 becomes stable (i.e. once 8.1.0 comes out in about April).

> For example, no LTS version of Ubuntu packages a compiler that's new enough 
> to build U-Boot now:-(

I recommend crosstools-ng for situations like this… in fact, I recommend 
crosstools-ng for any setup.
Building a [target]-elf toolchain really doesn’t take long.

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

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

2017-12-05 Thread Andre Przywara 
Hi,

On 28/11/17 10:24, Maxime Ripard wrote:
> Now that we have everything in place to implement the transition scheme,
> let's enable it by default.
> 
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  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
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 13/14] sunxi: Transition from the MMC to a FAT-based environment

2017-12-05 Thread Andre Przywara 
Hi,

On 28/11/17 10:24, Maxime Ripard wrote:
> 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.
> 
> Reviewed-by: Lukasz Majewski 
> 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;

So even though the actual u-boot.bin for 64-bit boards is still somewhat
below the limit (~480KB), adding the ATF image (~32KB) pushes it over
the edge. So since v2017.11 u-boot.itb is already too big for the
traditional MMC env location.
So shall this "case 1:" be guarded by #ifndef CONFIG_ARM64, to not even
consider MMC for sunxi64 anymore?

Cheers,
Andre.

> +
> + default:
> + return ENVL_UNKNOWN;
> + }
> +}
> +#endif
> +
>  /* add board specific code here */
>  int board_init(void)
>  {
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 12/14] env: Mark env_get_location as weak

2017-12-05 Thread Andre Przywara 
Hi,

On 28/11/17 10:24, Maxime Ripard wrote:
> Allow boards and architectures to override the default environment lookup
> code by overriding env_get_location.
> 
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  env/env.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/env/env.c b/env/env.c
> index b4d8886e7a69..9b8b38cf3c2b 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:
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 11/14] env: Allow to build multiple environments in Kconfig

2017-12-05 Thread Andre Przywara 
Hi,

On 28/11/17 10:24, Maxime Ripard wrote:
> Now that we have everything in place in the code, let's allow to build
> multiple environments backend through Kconfig.
> 
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Maxime Ripard 

Looks good, but doesn't apply cleanly to mainline anymore, because
CONFIG_ENV_AES was removed meanwhile (c6831c74a9e9).

Otherwise:
Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  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

Re: [U-Boot] [PATCH 10/14] env: Initialise all the environments

2017-12-05 Thread Andre Przywara 
Hi,

On 28/11/17 10:24, Maxime Ripard wrote:
> Since we want to have multiple environments, we will need to initialise
> all the environments since we don't know at init time what drivers might
> fail when calling load.
> 
> Let's init all of them, and only consider for further operations the ones
> that have not reported any errors at init time.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  env/env.c | 19 ---
>  include/asm-generic/global_data.h |  1 +
>  2 files changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/env/env.c b/env/env.c
> index 5176700133d3..b4d8886e7a69 100644
> --- a/env/env.c
> +++ b/env/env.c
> @@ -112,6 +112,9 @@ int env_get_char(int index)
>   if (!drv->get_char)
>   continue;
>  
> + if (!(gd->env_has_init & BIT(drv->location)))
> + continue;
> +
>   ret = drv->get_char(index);
>   if (!ret)
>   return 0;
> @@ -134,6 +137,9 @@ int env_load(void)
>   if (!drv->load)
>   continue;
>  
> + if (!(gd->env_has_init & BIT(drv->location)))
> + continue;
> +
>   printf("Loading Environment from %s... ", drv->name);
>   ret = drv->load();
>   printf("%s\n", ret ? "Failed" : "OK");
> @@ -155,6 +161,9 @@ int env_save(void)
>   if (!drv->save)
>   continue;
>  
> + if (!(gd->env_has_init & BIT(drv->location)))
> + continue;
> +
>   printf("Saving Environment to %s... ", drv->name);
>   ret = drv->save();
>   printf("%s\n", ret ? "Failed" : "OK");
> @@ -175,14 +184,10 @@ int env_init(void)
>   int prio;
>  

Becoming a bit desperate now, because I am struggling to find actual
issues in this series ;-), so:

Maybe we should have a build time check should the env_locations array
ever grow beyond 32?
BUILD_BUG_ON(ARRAY_SIZE(env_locations) > BITS_PER_LONG);

>   for (prio = 0; (drv = env_driver_lookup(ENVO_INIT, prio)); prio++) {
> - if (!drv->init)
> - continue;
> -
> - ret = drv->init();
> - if (!ret)
> - return 0;
> + if (!drv->init || !drv->init())
> + gd->env_has_init |= BIT(drv->location);
>  
> - debug("%s: Environment %s failed to init (err=%d)\n", __func__,
> + debug("%s: Environment %s init done (ret=%d)\n", __func__,
> drv->name, ret);
>   }
>  
> diff --git a/include/asm-generic/global_data.h 
> b/include/asm-generic/global_data.h
> index 944f58195caf..1d0611fe9498 100644
> --- a/include/asm-generic/global_data.h
> +++ b/include/asm-generic/global_data.h
> @@ -50,6 +50,7 @@ typedef struct global_data {
>  #endif
>   unsigned long env_addr; /* Address  of Environment struct */
>   unsigned long env_valid;/* Environment valid? enum env_valid */
> + unsigned long env_has_init; /* Bitmask of boolean of struct 
> env_location offsets */

struct env_location? Do you mean the env_location array? Or the enum?

Cheers,
Andre.

>   unsigned long ram_top;  /* Top address of RAM used by U-Boot */
>   unsigned long relocaddr;/* Start address of U-Boot in RAM */
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] fpga: allow programming fpga from FIT image for all FPGA drivers

2017-12-05 Thread Michal Simek 
On 5.12.2017 08:37, Goldschmidt Simon wrote:
> On 5.12.2017 08:22, Michal Simek wrote:
>>> Which release will this be in? Does it fit into 2018.01 or has that
>>> window already closed?
>>
>> I believe so.
> 
> Sorry to bother you again, I'm just not sure I understood your answer.
> 
> Was that "I beleive so" meant as "yes, 2018.01 unless someone rejects
> it"? Because Tom just wrote patches already on the ML were OK for that
> release?

I will be preparing at least one more pull request and this should be
the part of that. And it is end of year that's why different things can
come but I believe that I will have enough time to test all patches in
queue and send them to Tom.

Thanks,
Michal

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

Re: [U-Boot] [PATCH 09/14] env: Support multiple environments

2017-12-05 Thread Andre Przywara 
On 28/11/17 10:24, Maxime Ripard wrote:
> 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 44f9908e2c2d..5176700133d3 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];

That looks a bit fishy. Can you please make this two lines?

Otherwise: Reviewed-by: Andre Przywara 

Cheers,
Andre

> +
> + case ENVO_SAVE:
> + return env_load_location;
> + }
> +
> + return ENVL_UNKNOWN;
>  }
>  
>  static struct env_driver *env_driver_lookup(enum env_operation op, int prio)
> 

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

Re: [U-Boot] [PATCH 06/14] env: fat: Make the debug messages play a little nicer

2017-12-05 Thread Andre Przywara 
On 28/11/17 10:24, Maxime Ripard wrote:
> Since we have global messages to indicate what's going on, the custom
> messages in the environment drivers only make the output less readable.
> 
> Make FAT play a little nicer by removing all the extra \n and formatting
> that is redundant with the global output.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Andre Przywara 

One nit below...

> ---
>  env/fat.c |  9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/env/fat.c b/env/fat.c
> index ec49c3905369..51c4cedda6be 100644
> --- a/env/fat.c
> +++ b/env/fat.c
> @@ -55,7 +55,7 @@ static int env_fat_save(void)
>  
>   dev = dev_desc->devnum;
>   if (fat_set_blk_dev(dev_desc, ) != 0) {
> - printf("\n** Unable to use %s %d:%d for saveenv **\n",
> + printf("Unable to use %s %d:%d... ",

It might be worth to note here that those prints are embedded in
messages from the caller, which takes care of the linefeed.

Cheers,
Andre.

>  CONFIG_ENV_FAT_INTERFACE, dev, part);
>   return 1;
>   }
> @@ -63,12 +63,11 @@ static int env_fat_save(void)
>   err = file_fat_write(CONFIG_ENV_FAT_FILE, (void *)_new, 0, 
> sizeof(env_t),
>);
>   if (err == -1) {
> - printf("\n** Unable to write \"%s\" from %s%d:%d **\n",
> + printf("Unable to write \"%s\" from %s%d:%d... ",
>   CONFIG_ENV_FAT_FILE, CONFIG_ENV_FAT_INTERFACE, dev, 
> part);
>   return 1;
>   }
>  
> - puts("done\n");
>   return 0;
>  }
>  #endif /* CMD_SAVEENV */
> @@ -90,14 +89,14 @@ static int env_fat_load(void)
>  
>   dev = dev_desc->devnum;
>   if (fat_set_blk_dev(dev_desc, ) != 0) {
> - printf("\n** Unable to use %s %d:%d for loading the env **\n",
> + printf("Unable to use %s %d:%d... ",
>  CONFIG_ENV_FAT_INTERFACE, dev, part);
>   goto err_env_relocate;
>   }
>  
>   err = file_fat_read(CONFIG_ENV_FAT_FILE, buf, CONFIG_ENV_SIZE);
>   if (err == -1) {
> - printf("\n** Unable to read \"%s\" from %s%d:%d **\n",
> + printf("Unable to read \"%s\" from %s%d:%d... ",
>   CONFIG_ENV_FAT_FILE, CONFIG_ENV_FAT_INTERFACE, dev, 
> part);
>   goto err_env_relocate;
>   }
> 

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

Re: [U-Boot] [PATCH 07/14] env: mmc: Make the debug messages play a little nicer

2017-12-05 Thread Andre Przywara 
On 28/11/17 10:24, Maxime Ripard wrote:
> Since we have global messages to indicate what's going on, the custom
> messages in the environment drivers only make the output less readable.
> 
> Make MMC play a little nicer by removing all the extra \n and formatting
> that is redundant with the global output.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  env/mmc.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/env/mmc.c b/env/mmc.c
> index 3f3092d97560..885e000307db 100644
> --- a/env/mmc.c
> +++ b/env/mmc.c
> @@ -179,7 +179,6 @@ static int env_mmc_save(void)
>   goto fini;
>   }
>  
> - puts("done\n");
>   ret = 0;
>  
>  #ifdef CONFIG_ENV_OFFSET_REDUND
> 

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

Re: [U-Boot] [PATCH 08/14] env: common: Make the debug messages play a little nicer

2017-12-05 Thread Andre Przywara 
On 28/11/17 10:24, Maxime Ripard wrote:
> Since we have global messages to indicate what's going on, the custom
> messages in the environment drivers only make the output less readable.
> 
> Make the common code play a little nicer by removing all the extra output
> in the standard case.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Andre Przywara 

One nit below ...

> ---
>  env/common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/env/common.c b/env/common.c
> index 70715bb6e756..fb66432bdc81 100644
> --- a/env/common.c
> +++ b/env/common.c
> @@ -78,7 +78,7 @@ void set_default_env(const char *s)
>   puts(s);
>   }
>   } else {
> - puts("Using default environment\n\n");
> + debug("Using default environment\n\n");

Do we still need the extra empty line?

Cheers,
Andre

>   }
>  
>   if (himport_r(_htab, (char *)default_environment,
> 

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

Re: [U-Boot] [PATCH 05/14] env: Make it explicit where we're loading our environment from

2017-12-05 Thread Andre Przywara 
On 28/11/17 10:24, Maxime Ripard wrote:
> Since we can have multiple environments now, it's better to provide a
> decent indication on what environments were tried and which were the one to
> fail and succeed.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  env/env.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/env/env.c b/env/env.c
> index 1d13220aa79b..44f9908e2c2d 100644
> --- a/env/env.c
> +++ b/env/env.c
> @@ -109,12 +109,11 @@ int env_load(void)
>   if (!drv->load)
>   continue;
>  
> + printf("Loading Environment from %s... ", drv->name);
>   ret = drv->load();
> + printf("%s\n", ret ? "Failed" : "OK");

This looses the error code that was printed with debug() below. Might be
worth to keep it? Either always or as a debug?
printf("%s (%d)\n", ...);

Cheers,
Andre.

>   if (!ret)
>   return 0;
> -
> - debug("%s: Environment %s failed to load (err=%d)\n", __func__,
> -   drv->name, ret);
>   }
>  
>   return -ENODEV;
> 

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

Re: [U-Boot] [PATCH 04/14] env: Make the env save message a bit more explicit

2017-12-05 Thread Andre Przywara 
On 28/11/17 10:24, Maxime Ripard wrote:
> Since we'll soon have support for multiple environments, the environment
> saving message might end up being printed multiple times if the higher
> priority environment cannot be used.
> 
> That might confuse the user, so let's make it explicit if the operation
> failed or not.
> 
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  env/env.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/env/env.c b/env/env.c
> index 673bfa6ba41b..1d13220aa79b 100644
> --- a/env/env.c
> +++ b/env/env.c
> @@ -131,8 +131,9 @@ int env_save(void)
>   if (!drv->save)
>   continue;
>  
> - printf("Saving Environment to %s...\n", drv->name);
> + printf("Saving Environment to %s... ", drv->name);
>   ret = drv->save();
> + printf("%s\n", ret ? "Failed" : "OK");
>   if (!ret)
>   return 0;
>  
> 

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

Re: [U-Boot] [PATCH 03/14] env: Pass additional parameters to the env lookup function

2017-12-05 Thread Andre Przywara 
Hi Maxime,

On 28/11/17 10:24, Maxime Ripard wrote:
> 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.

I wonder if this is a bit too generic. Wouldn't a simple:
bool is_save_op (or some more clever name)
be sufficient? At least this is actually all we need, if I understand
the code correctly.
But it's up to you, I can see advantages for both approaches.

> 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);

Did you deliberately remove this fallback from the new code below?

> - 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;

Is this change to the algorithm acceptable? Formerly we returned 0 on
finding a drv->load pointer to be NULL, now it's -ENODEV, plus we try to
find other sources first.
Or is that solved later somehow with the env_has_init bitmap?

> +
> + 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();
> -

Re: [U-Boot] [PATCH 02/14] env: Rename env_driver_lookup_default and env_get_default_location

2017-12-05 Thread Andre Przywara 
On 28/11/17 10:24, Maxime Ripard wrote:
> 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.
> 
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  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)
> 

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

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

2017-12-05 Thread Andre Przywara 
On 28/11/17 10:24, Maxime Ripard wrote:
> 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.
> 
> Reviewed-by: Lukasz Majewski 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Andre Przywara 

Cheers,
Andre

> ---
>  cmd/nvedit.c  | 4 
>  env/env.c | 4 +++-
>  include/environment.h | 7 ---
>  3 files changed, 3 insertions(+), 12 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..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;
> @@ -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__,
> diff --git a/include/environment.h b/include/environment.h
> index 7b9821638960..226e3ef2d23a 100644
> --- a/include/environment.h
> +++ b/include/environment.h
> @@ -303,13 +303,6 @@ 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
>   *
>   * This reads from the pre-relocation environemnt
> 

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

Re: [U-Boot] [PATCH] sunxi: Fix UART console index for A33-OLinuXino

2017-12-05 Thread Maxime Ripard 
On Tue, Dec 05, 2017 at 02:00:07PM +0800, Chen-Yu Tsai wrote:
> The A33-OLinuXino defconfig was using the default CONS_INDEX value for
> A33, which actually points to the R_UART, which is routed to the GPIO
> header without proper pull-ups or diodes. The board has a separate
> header for UART0, which are routed to pins PB0 and PB1. This header
> is properly marked and is likely the first pins any user would try
> to get a console.
> 
> Fix CONS_INDEX in the defconfig so the console appears on UART0.
> 
> Fixes: ca5c37026be4 ("sunxi: Add support for A33-OLinuXino board")
> Signed-off-by: Chen-Yu Tsai 

Acked-by: Maxime Ripard 

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 v5 07/20] common: Generic firmware loader for file system

2017-12-05 Thread Lothar Waßmann 
Hi,

On Tue,  5 Dec 2017 15:57:57 +0800 tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> This is file system generic loader which can be used to load
> the file image from the storage into target such as memory.
> The consumer driver would then use this loader to program whatever,
> ie. the FPGA device.
> 
> Signed-off-by: Tien Fong Chee 
> ---
>  common/Makefile |   1 +
>  common/fs_loader.c  | 304 
> 
>  include/fs_loader.h |  30 ++
>  3 files changed, 335 insertions(+)
>  create mode 100644 common/fs_loader.c
>  create mode 100644 include/fs_loader.h
> 
> diff --git a/common/Makefile b/common/Makefile
> index 801ea31..419e915 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -130,3 +130,4 @@ obj-$(CONFIG_CMD_DFU) += dfu.o
>  obj-y += command.o
>  obj-y += s_record.o
>  obj-y += xyzModem.o
> +obj-y += fs_loader.o
> diff --git a/common/fs_loader.c b/common/fs_loader.c
> new file mode 100644
> index 000..04f682b
> --- /dev/null
> +++ b/common/fs_loader.c
> @@ -0,0 +1,304 @@
> +/*
> + * Copyright (C) 2017 Intel Corporation 
> + *
> + * SPDX-License-Identifier:GPL-2.0
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static struct device_location default_locations[] = {
> + {
> + .name = "mmc",
> + .devpart = "0:1",
> + },
> + {
> + .name = "usb",
> + .devpart = "0:1",
> + },
> + {
> + .name = "sata",
> + .devpart = "0:1",
> + },
> +};
> +
> +/* USB build is not supported yet in SPL */
> +#ifndef CONFIG_SPL_BUILD
> +#ifdef CONFIG_USB_STORAGE
> +static int init_usb(void)
> +{
> + int err = 0;
>
Useless initialization.

> + err = usb_init();
> +
> + if (err)
>
Unnecessary blank line.

> + return err;
> +
> +#ifndef CONFIG_DM_USB
> + err = usb_stor_scan(1) < 0 ? -ENODEV : 0;
> +#endif
> +
> + return err;
> +}
> +#else
> +static int init_usb(void)
> +{
> + printf("Error: Cannot load flash image: no USB support\n");
> + return -ENOSYS;
> +}
> +#endif
> +#endif
> +
> +#ifdef CONFIG_SATA
> +static int init_storage_sata(void)
> +{
> + return sata_probe(0);
> +}
> +#else
> +static int init_storage_sata(void)
> +{
> + printf("Error: Cannot load image: no SATA support\n");
> + return -ENOSYS;
> +}
> +#endif
> +
> +#ifdef CONFIG_CMD_UBIFS
> +static int mount_ubifs(struct device_location *location)
> +{
> + int ret = 0;
>
Useless initialization.

> + char cmd[32];
> +
> + sprintf(cmd, "ubi part %s", location->mtdpart);
> +
> + ret = run_command(cmd, 0);
> +
> + if (ret)
Unnecessary blank line.

> + return ret;
> +
> + sprintf(cmd, "ubifsmount %s", location->ubivol);
> +
> + ret = run_command(cmd, 0);
> +
> + return res;
>
s/res/ret/
You obviously never compiled this code with CONFIG_CMD_UBIFS enabled.

> +}
> +
> +static int umount_ubifs(void)
> +{
> + return run_command("ubifsumount", 0);
> +}
> +#else
> +static int mount_ubifs(struct device_location *location)
> +{
> + printf("Error: Cannot load image: no UBIFS support\n");
> + return -ENOSYS;
> +}
> +
> +static int umount_ubifs(void)
> +{
> + printf("Error: Cannot unmount UBIFS: no UBIFS support\n");
>
This error message is useless, since umount_ubifs() would
probably never be called when mount_ubifs() failed.

> +}
> +#endif
> +
> +#if defined(CONFIG_SPL_MMC_SUPPORT) && defined(CONFIG_SPL_BUILD)
> +static int init_mmc(void)
> +{
> + /* Just for the case MMC is not yet initialized */
> + struct mmc *mmc = NULL;
> + int err = 0;
>
Useless initialization.

> +
> + spl_mmc_find_device(, spl_boot_device());
> +
> + err = mmc_init(mmc);
> +
> + if (err) {
> + printf("spl: mmc init failed with error: %d\n", err);
> + return err;
> + }
> +
> + return err;
> +}
> +#else
> +static int init_mmc(void)
> +{
> + /* Expect somewhere already initialize MMC */
> + return 0;
> +}
> +#endif
> +
> +static int select_fs_dev(struct device_location *location)
> +{
> + int ret = 0;
>
Useless initialization. Omitting the initialization here makes sure,
that 'ret' is properly set in each of the below if/else clauses.
Otherwise the compiler will complain about an unitialized use of 'ret'.

> + if (!strcmp("mmc", location->name))
> + ret = fs_set_blk_dev("mmc", location->devpart, FS_TYPE_ANY);
> + else if (!strcmp("usb", location->name))
> + ret = fs_set_blk_dev("usb", location->devpart, FS_TYPE_ANY);
> + else if (!strcmp("sata", location->name))
> + ret = fs_set_blk_dev("sata", location->devpart, FS_TYPE_ANY);
> + else if (!strcmp("ubi", location->name))
> + if (location->ubivol != NULL)
> +

[U-Boot] [PATCH v5 10/20] arm: socfpga: Rename the gen5 sdram driver to more specific name

2017-12-05 Thread tien . fong . chee 
From: Tien Fong Chee 

Current sdram driver is only applied to gen5 device, hence it is better
to rename sdram driver to more specific name which is related to gen5
device.

Signed-off-by: Tien Fong Chee 
---
 arch/arm/mach-socfpga/include/mach/sdram.h | 432 +
 .../include/mach/{sdram.h => sdram_gen5.h} |   6 +-
 drivers/ddr/altera/Makefile|   2 +-
 drivers/ddr/altera/{sdram.c => sdram_gen5.c}   |   0
 4 files changed, 7 insertions(+), 433 deletions(-)
 copy arch/arm/mach-socfpga/include/mach/{sdram.h => sdram_gen5.h} (99%)
 rename drivers/ddr/altera/{sdram.c => sdram_gen5.c} (100%)

diff --git a/arch/arm/mach-socfpga/include/mach/sdram.h 
b/arch/arm/mach-socfpga/include/mach/sdram.h
index b11228f..137e073 100644
--- a/arch/arm/mach-socfpga/include/mach/sdram.h
+++ b/arch/arm/mach-socfpga/include/mach/sdram.h
@@ -8,435 +8,9 @@
 
 #ifndef __ASSEMBLY__
 
-unsigned long sdram_calculate_size(void);
-int sdram_mmr_init_full(unsigned int sdr_phy_reg);
-int sdram_calibration_full(void);
-
-const struct socfpga_sdram_config *socfpga_get_sdram_config(void);
-
-void socfpga_get_seq_ac_init(const u32 **init, unsigned int *nelem);
-void socfpga_get_seq_inst_init(const u32 **init, unsigned int *nelem);
-const struct socfpga_sdram_rw_mgr_config *socfpga_get_sdram_rwmgr_config(void);
-const struct socfpga_sdram_io_config *socfpga_get_sdram_io_config(void);
-const struct socfpga_sdram_misc_config *socfpga_get_sdram_misc_config(void);
-
-#define SDR_CTRLGRP_ADDRESS(SOCFPGA_SDR_ADDRESS | 0x5000)
-
-struct socfpga_sdr_ctrl {
-   u32 ctrl_cfg;
-   u32 dram_timing1;
-   u32 dram_timing2;
-   u32 dram_timing3;
-   u32 dram_timing4;   /* 0x10 */
-   u32 lowpwr_timing;
-   u32 dram_odt;
-   u32 extratime1;
-   u32 __padding0[3];
-   u32 dram_addrw; /* 0x2c */
-   u32 dram_if_width;  /* 0x30 */
-   u32 dram_dev_width;
-   u32 dram_sts;
-   u32 dram_intr;
-   u32 sbe_count;  /* 0x40 */
-   u32 dbe_count;
-   u32 err_addr;
-   u32 drop_count;
-   u32 drop_addr;  /* 0x50 */
-   u32 lowpwr_eq;
-   u32 lowpwr_ack;
-   u32 static_cfg;
-   u32 ctrl_width; /* 0x60 */
-   u32 cport_width;
-   u32 cport_wmap;
-   u32 cport_rmap;
-   u32 rfifo_cmap; /* 0x70 */
-   u32 wfifo_cmap;
-   u32 cport_rdwr;
-   u32 port_cfg;
-   u32 fpgaport_rst;   /* 0x80 */
-   u32 __padding1;
-   u32 fifo_cfg;
-   u32 protport_default;
-   u32 prot_rule_addr; /* 0x90 */
-   u32 prot_rule_id;
-   u32 prot_rule_data;
-   u32 prot_rule_rdwr;
-   u32 __padding2[3];
-   u32 mp_priority;/* 0xac */
-   u32 mp_weight0; /* 0xb0 */
-   u32 mp_weight1;
-   u32 mp_weight2;
-   u32 mp_weight3;
-   u32 mp_pacing0; /* 0xc0 */
-   u32 mp_pacing1;
-   u32 mp_pacing2;
-   u32 mp_pacing3;
-   u32 mp_threshold0;  /* 0xd0 */
-   u32 mp_threshold1;
-   u32 mp_threshold2;
-   u32 __padding3[29];
-   u32 phy_ctrl0;  /* 0x150 */
-   u32 phy_ctrl1;
-   u32 phy_ctrl2;
-};
-
-/* SDRAM configuration structure for the SPL. */
-struct socfpga_sdram_config {
-   u32 ctrl_cfg;
-   u32 dram_timing1;
-   u32 dram_timing2;
-   u32 dram_timing3;
-   u32 dram_timing4;
-   u32 lowpwr_timing;
-   u32 dram_odt;
-   u32 extratime1;
-   u32 dram_addrw;
-   u32 dram_if_width;
-   u32 dram_dev_width;
-   u32 dram_intr;
-   u32 lowpwr_eq;
-   u32 static_cfg;
-   u32 ctrl_width;
-   u32 cport_width;
-   u32 cport_wmap;
-   u32 cport_rmap;
-   u32 rfifo_cmap;
-   u32 wfifo_cmap;
-   u32 cport_rdwr;
-   u32 port_cfg;
-   u32 fpgaport_rst;
-   u32 fifo_cfg;
-   u32 mp_priority;
-   u32 mp_weight0;
-   u32 mp_weight1;
-   u32 mp_weight2;
-   u32 mp_weight3;
-   u32 mp_pacing0;
-   u32 mp_pacing1;
-   u32 mp_pacing2;
-   u32 mp_pacing3;
-   u32 mp_threshold0;
-   u32 mp_threshold1;
-   u32 mp_threshold2;
-   u32 phy_ctrl0;
-};
-
-struct socfpga_sdram_rw_mgr_config {
-   u8  activate_0_and_1;
-   u8  activate_0_and_1_wait1;
-   u8  activate_0_and_1_wait2;
-   u8  activate_1;
-   u8  clear_dqs_enable;
-   u8  guaranteed_read;
-   u8  guaranteed_read_cont;
-   u8  guaranteed_write;
-   u8  guaranteed_write_wait0;
-   u8  guaranteed_write_wait1;
-   u8

[U-Boot] [PATCH v5 19/20] arm: socfpga: Enable DDR working

2017-12-05 Thread tien . fong . chee 
From: Tien Fong Chee 

SPL configures DDR by programming peripheral raw binary file
and calibrating DDR.

Signed-off-by: Tien Fong Chee 
---
 arch/arm/mach-socfpga/spl.c   | 43 +++
 configs/socfpga_arria10_defconfig | 17 +---
 2 files changed, 57 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c
index aba116d..60159b2 100644
--- a/arch/arm/mach-socfpga/spl.c
+++ b/arch/arm/mach-socfpga/spl.c
@@ -15,13 +15,19 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
 #include 
@@ -29,6 +35,9 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#define BSIZE  4096
+#define PERIPH_RBF 0
+
 #if defined(CONFIG_TARGET_SOCFPGA_GEN5)
 static struct pl310_regs *const pl310 =
(struct pl310_regs *)CONFIG_SYS_PL310_BASE;
@@ -197,6 +206,12 @@ void board_init_f(ulong dummy)
 #elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
 void spl_board_init(void)
 {
+   int rval = 0;
+   int len = 0;
+   u32 buffer[BSIZE] __aligned(ARCH_DMA_MINALIGN);
+   struct spl_boot_device bootdev;
+   fpga_fs_info fpga_fsinfo;
+
/* configuring the clock based on handoff */
cm_basic_init(gd->fdt_blob);
WATCHDOG_RESET();
@@ -214,6 +229,34 @@ void spl_board_init(void)
 
/* Add device descriptor to FPGA device table */
socfpga_fpga_add();
+
+   set_default_env(NULL);
+
+   bootdev.boot_device = spl_boot_device();
+
+   if (BOOT_DEVICE_MMC1 == bootdev.boot_device) {
+   fpga_fsinfo.interface = "mmc";
+   fpga_fsinfo.fstype = FS_TYPE_FAT;
+   }
+
+   fpga_fsinfo.filename = (char *)get_cff_filename(gd->fdt_blob,
+   ,
+   PERIPH_RBF);
+
+   fpga_fsinfo.dev_part = (char *)get_cff_devpart(gd->fdt_blob,
+  );
+
+   if (fpga_fsinfo.dev_part)
+   env_set("FW_DEV_PART", fpga_fsinfo.dev_part);
+
+   /* Program peripheral RBF */
+   rval = fpga_fsload(0, buffer, BSIZE, _fsinfo);
+
+   if (!rval) {
+   config_pins(gd->fdt_blob, "shared");
+
+   ddr_calibration_sequence();
+   }
 }
 
 void board_init_f(ulong dummy)
diff --git a/configs/socfpga_arria10_defconfig 
b/configs/socfpga_arria10_defconfig
index 4c73d73..14adbd8 100644
--- a/configs/socfpga_arria10_defconfig
+++ b/configs/socfpga_arria10_defconfig
@@ -7,28 +7,39 @@ CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc"
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="console=ttyS0,115200"
 CONFIG_DEFAULT_FDT_FILE="socfpga_arria10_socdk_sdmmc.dtb"
+CONFIG_FIT=y
+CONFIG_SPL_ENV_SUPPORT=y
+CONFIG_SPL_FIT=y
 CONFIG_SPL=y
 CONFIG_SPL_FPGA_SUPPORT=y
+CONFIG_SPL_FAT_SUPPORT=y
+CONFIG_FS_FAT_MAX_CLUSTSIZE=32768
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_IMLS is not set
 CONFIG_CMD_ASKENV=y
 CONFIG_CMD_GREPENV=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_GPIO=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_EXT4_WRITE=y
 CONFIG_DOS_PARTITION=y
-# CONFIG_SPL_DOS_PARTITION is not set
 CONFIG_ENV_IS_IN_MMC=y
+CONFIG_SPL_DOS_PARTITION=y
+CONFIG_SPL_FS_GENERIC=y
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_DFU_MMC=y
 CONFIG_FPGA_SOCFPGA=y
 CONFIG_DM_GPIO=y
 CONFIG_DWAPB_GPIO=y
 CONFIG_DM_MMC=y
+CONFIG_MMC_DW=y
 CONFIG_SYS_NS16550=y
 CONFIG_USE_TINY_PRINTF=y
+CONFIG_CMD_FPGA_LOADFS=y
+CONFIG_SPL_MMC_SUPPORT=y
-- 
2.2.0

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

[U-Boot] [PATCH v5 15/20] arm: socfpga: Improve comments for Intel SoCFPGA program header

2017-12-05 Thread tien . fong . chee 
From: Tien Fong Chee 

Adding some details about size in bytes to each section.

Signed-off-by: Tien Fong Chee 
Reviewed-by: Dinh Nguyen 
---
 arch/arm/mach-socfpga/include/mach/boot0.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-socfpga/include/mach/boot0.h 
b/arch/arm/mach-socfpga/include/mach/boot0.h
index 22d9e7f..e06b548 100644
--- a/arch/arm/mach-socfpga/include/mach/boot0.h
+++ b/arch/arm/mach-socfpga/include/mach/boot0.h
@@ -11,8 +11,8 @@
.balignl 64,0xf33db33f;
 
.word   0x1337c0d3; /* SoCFPGA preloader validation word */
-   .word   0xc01df00d; /* Version, flags, length */
-   .word   0xcafec0d3; /* Checksum, zero-pad */
+   .word   0xc01df00d; /* Header length(2B),flags(1B),version(1B) */
+   .word   0xcafec0d3; /* Simple checksum(2B),spare offset(2B) */
nop;
 
b reset;/* SoCFPGA jumps here */
-- 
2.2.0

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

  1   2   >