[U-Boot] [PATCH 11/11] configs: dra7xx: Enable lp873x options

[Lokesh Vutla]

From: Keerthy 

DRA71-evm uses LP873x regulator. Enable lp873x PMIC config options.

Signed-off-by: Keerthy 
Signed-off-by: Lokesh Vutla 
---
 configs/dra7xx_evm_defconfig| 3 +++
 configs/dra7xx_hs_evm_defconfig | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index 0802898..64fe038 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -66,9 +66,12 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_DM_ETH=y
 CONFIG_DM_PMIC=y
 CONFIG_PMIC_PALMAS=y
+CONFIG_PMIC_LP873X=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_DM_REGULATOR_PALMAS=y
+CONFIG_DM_REGULATOR_LP873X=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index 84f1be6..e350d9f 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -68,9 +68,12 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_DM_ETH=y
 CONFIG_DM_PMIC=y
 CONFIG_PMIC_PALMAS=y
+CONFIG_PMIC_LP873X=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_DM_REGULATOR_PALMAS=y
+CONFIG_DM_REGULATOR_LP873X=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
-- 
2.10.1

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

[U-Boot] [PATCH 10/11] configs: dra7xx: Enable pmic/regulator options

[Lokesh Vutla]

Enable pmic/regulator config options.

Signed-off-by: Lokesh Vutla 
---
 configs/dra7xx_evm_defconfig| 1 +
 configs/dra7xx_hs_evm_defconfig | 4 
 2 files changed, 5 insertions(+)

diff --git a/configs/dra7xx_evm_defconfig b/configs/dra7xx_evm_defconfig
index 4bd031d..0802898 100644
--- a/configs/dra7xx_evm_defconfig
+++ b/configs/dra7xx_evm_defconfig
@@ -40,6 +40,7 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
+CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index 0da6790..84f1be6 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -42,6 +42,7 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
+CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
@@ -65,8 +66,11 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_DM_ETH=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_PALMAS=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_PALMAS=y
 CONFIG_DM_SERIAL=y
 CONFIG_SYS_NS16550=y
 CONFIG_DM_SPI=y
-- 
2.10.1

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

[U-Boot] [PATCH 09/11] configs: dra7xx: hs: Enable DM_ETH

[Lokesh Vutla]

Enable DM_ETH for hs boards.

Signed-off-by: Lokesh Vutla 
---
 configs/dra7xx_hs_evm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index 390c569..0da6790 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -64,6 +64,7 @@ CONFIG_DM_SPI_FLASH=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
 CONFIG_SPI_FLASH_SPANSION=y
+CONFIG_DM_ETH=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_SERIAL=y
-- 
2.10.1

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

[U-Boot] [PATCH 08/11] configs: ti_omap5_common: Select dtb name for dra71x

[Lokesh Vutla]

From: Nishanth Menon 

Select dtb name for dra71x-evm.

Signed-off-by: Nishanth Menon 
---
 include/configs/ti_omap5_common.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/ti_omap5_common.h 
b/include/configs/ti_omap5_common.h
index 8322f64..3bc7bf9 100644
--- a/include/configs/ti_omap5_common.h
+++ b/include/configs/ti_omap5_common.h
@@ -98,6 +98,8 @@
"setenv fdtfile dra72-evm-revc.dtb; fi;" \
"if test $board_name = dra72x; then " \
"setenv fdtfile dra72-evm.dtb; fi;" \
+   "if test $board_name = dra71x; then " \
+   "setenv fdtfile dra71-evm.dtb; fi;" \
"if test $board_name = beagle_x15; then " \
"setenv fdtfile am57xx-beagle-x15.dtb; fi;" \
"if test $board_name = am572x_idk; then " \
-- 
2.10.1

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

[U-Boot] [PATCH 07/11] ARM: dts: dra71x-evm: Add DT support

[Lokesh Vutla]

Add DT support for dra71-evm and built it as part of FIT image.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/dts/Makefile   |   2 +-
 arch/arm/dts/dra71-evm.dts  | 230 
 board/ti/dra7xx/evm.c   |   5 +-
 configs/dra7xx_evm_defconfig|   2 +-
 configs/dra7xx_hs_evm_defconfig |   2 +-
 5 files changed, 237 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/dts/dra71-evm.dts

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2c5b2f2..f7d9e1c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -136,7 +136,7 @@ dtb-$(CONFIG_ARCH_SOCFPGA) +=   
\
socfpga_cyclone5_vining_fpga.dtb
 
 dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb  \
-   dra72-evm-revc.dtb
+   dra72-evm-revc.dtb dra71-evm.dtb
 dtb-$(CONFIG_TARGET_AM57XX_EVM) += am57xx-beagle-x15.dtb \
am572x-idk.dtb
 dtb-$(CONFIG_TARGET_STV0991) += stv0991.dtb
diff --git a/arch/arm/dts/dra71-evm.dts b/arch/arm/dts/dra71-evm.dts
new file mode 100644
index 000..875116c
--- /dev/null
+++ b/arch/arm/dts/dra71-evm.dts
@@ -0,0 +1,230 @@
+/*
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "dra72-evm-common.dtsi"
+#include 
+
+/ {
+   compatible = "ti,dra718-evm", "ti,dra718", "ti,dra722", "ti,dra72", 
"ti,dra7";
+   model = "TI DRA718 EVM";
+
+   memory {
+   device_type = "memory";
+   reg = <0x0 0x8000 0x0 0x8000>; /* 2GB */
+   };
+
+   vpo_sd_1v8_3v3: gpio-regulator-TPS74801 {
+   compatible = "regulator-gpio";
+
+   regulator-name = "vddshv8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <300>;
+   regulator-boot-on;
+   vin-supply = <_5v0>;
+
+   gpios = < 11 GPIO_ACTIVE_HIGH>;
+   states = <180 0x0
+ 300 0x1>;
+   };
+
+   poweroff: gpio-poweroff {
+   compatible = "gpio-poweroff";
+   gpios = < 30 GPIO_ACTIVE_HIGH>;
+   input;
+   };
+};
+
+ {
+   status = "okay";
+   clock-frequency = <40>;
+
+   lp8733: lp8733@60 {
+   compatible = "ti,lp8733";
+   reg = <0x60>;
+
+   buck0-in-supply =<_3v3>;
+   buck1-in-supply =<_3v3>;
+   ldo0-in-supply =<_5v0>;
+   ldo1-in-supply =<_5v0>;
+
+   lp8733_regulators: regulators {
+   lp8733_buck0_reg: buck0 {
+   /* FB_B0 -> LP8733-BUCK1 - VPO_S1_AVS - 
VDD_CORE_AVS (core, mpu, gpu) */
+   regulator-name = "lp8733-buck0";
+   regulator-min-microvolt = <85>;
+   regulator-max-microvolt = <125>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   lp8733_buck1_reg: buck1 {
+   /* FB_B1 -> LP8733-BUCK2 - VPO_S2_AVS - 
VDD_DSP_AVS (DSP/eve/iva) */
+   regulator-name = "lp8733-buck1";
+   regulator-min-microvolt = <85>;
+   regulator-max-microvolt = <125>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   lp8733_ldo0_reg: ldo0 {
+   /* LDO0 -> LP8733-LDO1 - VPO_L1_3V3 - VDDSHV8 
(optional) */
+   regulator-name = "lp8733-ldo0";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   lp8733_ldo1_reg: ldo1 {
+   /* LDO1 -> LP8733-LDO2 - VPO_L2_3V3 - 
VDDA_USB3V3 */
+   regulator-name = "lp8733-ldo1";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+   };
+   };
+
+   lp8732: lp8732@61 {
+   compatible = "ti,lp8732";
+   reg = <0x61>;
+
+   buck0-in-supply =<_3v3>;
+   buck1-in-supply =<_3v3>;
+   ldo0-in-supply =<_3v3>;
+   ldo1-in-supply =<_3v3>;
+
+   lp8732_regulators: regulators {
+   lp8732_buck0_reg: buck0 {
+   

[U-Boot] [PATCH 05/11] ARM: OMAP4+: Add support for getting pbias info from board

[Lokesh Vutla]

Palmas driver assumes it is always TPS659xx regulator on all DRA7xx based
boards to enable mmc regulator. This is not true always like in case of
DRA71x-evm. So get this information based on the board.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Vignesh R 
Signed-off-by: Nishanth Menon 
---
 arch/arm/include/asm/omap_mmc.h|  2 +-
 arch/arm/mach-omap2/omap4/hwinit.c | 13 +
 arch/arm/mach-omap2/omap5/hwinit.c | 34 ++
 drivers/mmc/omap_hsmmc.c   | 33 ++---
 drivers/power/palmas.c | 21 -
 include/palmas.h   | 13 -
 6 files changed, 82 insertions(+), 34 deletions(-)

diff --git a/arch/arm/include/asm/omap_mmc.h b/arch/arm/include/asm/omap_mmc.h
index b69d073..f2bf645 100644
--- a/arch/arm/include/asm/omap_mmc.h
+++ b/arch/arm/include/asm/omap_mmc.h
@@ -167,5 +167,5 @@ struct hsmmc {
 int omap_mmc_init(int dev_index, uint host_caps_mask, uint f_max, int cd_gpio,
int wp_gpio);
 
-
+void vmmc_pbias_config(uint voltage);
 #endif /* OMAP_MMC_H_ */
diff --git a/arch/arm/mach-omap2/omap4/hwinit.c 
b/arch/arm/mach-omap2/omap4/hwinit.c
index 7c6638c..67ab1cc 100644
--- a/arch/arm/mach-omap2/omap4/hwinit.c
+++ b/arch/arm/mach-omap2/omap4/hwinit.c
@@ -12,6 +12,7 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -175,3 +176,15 @@ void v7_outer_cache_disable(void)
omap_smc1(OMAP4_SERVICE_PL310_CONTROL_REG_SET, 0);
 }
 #endif /* !CONFIG_SYS_L2CACHE_OFF */
+
+void vmmc_pbias_config(uint voltage)
+{
+   u32 value = 0;
+
+   value = readl((*ctrl)->control_pbiaslite);
+   value &= ~(MMC1_PBIASLITE_PWRDNZ | MMC1_PWRDNZ);
+   writel(value, (*ctrl)->control_pbiaslite);
+   value = readl((*ctrl)->control_pbiaslite);
+   value |= MMC1_PBIASLITE_VMODE | MMC1_PBIASLITE_PWRDNZ | MMC1_PWRDNZ;
+   writel(value, (*ctrl)->control_pbiaslite);
+}
diff --git a/arch/arm/mach-omap2/omap5/hwinit.c 
b/arch/arm/mach-omap2/omap5/hwinit.c
index e3ac8bb..839d79d 100644
--- a/arch/arm/mach-omap2/omap5/hwinit.c
+++ b/arch/arm/mach-omap2/omap5/hwinit.c
@@ -13,6 +13,7 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -451,3 +452,36 @@ void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 
cpu_rev_comb,
 #endif
omap_smc1(OMAP5_SERVICE_ACR_SET, acr);
 }
+
+#if defined(CONFIG_PALMAS_POWER)
+void vmmc_pbias_config(uint voltage)
+{
+   u32 value = 0;
+   struct vcores_data const *vcores = *omap_vcores;
+
+   value = readl((*ctrl)->control_pbias);
+   value &= ~SDCARD_PWRDNZ;
+   writel(value, (*ctrl)->control_pbias);
+   udelay(10); /* wait 10 us */
+   value &= ~SDCARD_BIAS_PWRDNZ;
+   writel(value, (*ctrl)->control_pbias);
+
+   if (vcores->core.pmic->i2c_slave_addr == 0x60) {
+   if (voltage == LDO_VOLT_3V0)
+   voltage = 0x19;
+   else if (voltage == LDO_VOLT_1V8)
+   voltage = 0xa;
+   lp873x_mmc1_poweron_ldo(voltage);
+   } else {
+   palmas_mmc1_poweron_ldo(voltage);
+   }
+
+   value = readl((*ctrl)->control_pbias);
+   value |= SDCARD_BIAS_PWRDNZ;
+   writel(value, (*ctrl)->control_pbias);
+   udelay(150); /* wait 150 us */
+   value |= SDCARD_PWRDNZ;
+   writel(value, (*ctrl)->control_pbias);
+   udelay(150); /* wait 150 us */
+}
+#endif
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index fceafe1..0d824a6 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -110,30 +110,6 @@ static void omap4_vmmc_pbias_config(struct mmc *mmc)
 }
 #endif
 
-#if defined(CONFIG_OMAP54XX) && defined(CONFIG_PALMAS_POWER)
-static void omap5_pbias_config(struct mmc *mmc)
-{
-   u32 value = 0;
-
-   value = readl((*ctrl)->control_pbias);
-   value &= ~SDCARD_PWRDNZ;
-   writel(value, (*ctrl)->control_pbias);
-   udelay(10); /* wait 10 us */
-   value &= ~SDCARD_BIAS_PWRDNZ;
-   writel(value, (*ctrl)->control_pbias);
-
-   palmas_mmc1_poweron_ldo();
-
-   value = readl((*ctrl)->control_pbias);
-   value |= SDCARD_BIAS_PWRDNZ;
-   writel(value, (*ctrl)->control_pbias);
-   udelay(150); /* wait 150 us */
-   value |= SDCARD_PWRDNZ;
-   writel(value, (*ctrl)->control_pbias);
-   udelay(150); /* wait 150 us */
-}
-#endif
-
 static unsigned char mmc_board_init(struct mmc *mmc)
 {
 #if defined(CONFIG_OMAP34XX)
@@ -173,14 +149,10 @@ static unsigned char mmc_board_init(struct mmc *mmc)
_base->iclken1_core);
 #endif
 
-#if defined(CONFIG_OMAP44XX)
+#if defined(CONFIG_OMAP54XX) || defined(CONFIG_OMAP44XX)
/* PBIAS config needed for MMC1 only */
if (mmc->block_dev.devnum == 0)
-   omap4_vmmc_pbias_config(mmc);
-#endif
-#if 

[U-Boot] [PATCH 03/11] board: ti: dra72: Introduce optimization for rgmii timing for rev C

[Lokesh Vutla]

From: Nishanth Menon 

Rev C version of EVM does require IODelay to be configured for RGMII
pins in MANUAL_1 configuration. Update the same based on PG2.0 initial
simulation values.
Data based on PCT_DRA72x_SR2.0_SR1.0_v1.3.0.7

Signed-off-by: Nishanth Menon 
Signed-off-by: Lokesh Vutla 
---
 board/ti/dra7xx/mux_data.h | 75 ++
 1 file changed, 50 insertions(+), 25 deletions(-)

diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index d071b74..2cc4be3 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -193,30 +193,30 @@ const struct pad_conf_entry 
dra72x_rgmii_padconf_array_revb[] = {
 
 const struct pad_conf_entry dra72x_rgmii_padconf_array_revc[] = {
{VIN2A_FLD0, (M14 | PIN_INPUT)},/* vin2a_fld0.gpio3_30 */
-   {RGMII0_TXC, (M0 | PIN_OUTPUT)},/* rgmii0_txc.rgmii0_txc */
-   {RGMII0_TXCTL, (M0 | PIN_OUTPUT)},  /* rgmii0_txctl.rgmii0_txctl */
-   {RGMII0_TXD3, (M0 | PIN_OUTPUT)},   /* rgmii0_txd3.rgmii0_txd3 */
-   {RGMII0_TXD2, (M0 | PIN_OUTPUT)},   /* rgmii0_txd2.rgmii0_txd2 */
-   {RGMII0_TXD1, (M0 | PIN_OUTPUT)},   /* rgmii0_txd1.rgmii0_txd1 */
-   {RGMII0_TXD0, (M0 | PIN_OUTPUT)},   /* rgmii0_txd0.rgmii0_txd0 */
-   {RGMII0_RXC, (M0 | PIN_INPUT_PULLDOWN)},/* 
rgmii0_rxc.rgmii0_rxc */
-   {RGMII0_RXCTL, (M0 | PIN_INPUT_PULLDOWN)},  /* 
rgmii0_rxctl.rgmii0_rxctl */
-   {RGMII0_RXD3, (M0 | PIN_INPUT_PULLDOWN)},   /* 
rgmii0_rxd3.rgmii0_rxd3 */
-   {RGMII0_RXD2, (M0 | PIN_INPUT_PULLDOWN)},   /* 
rgmii0_rxd2.rgmii0_rxd2 */
-   {RGMII0_RXD1, (M0 | PIN_INPUT_PULLDOWN)},   /* 
rgmii0_rxd1.rgmii0_rxd1 */
-   {RGMII0_RXD0, (M0 | PIN_INPUT_PULLDOWN)},   /* 
rgmii0_rxd0.rgmii0_rxd0 */
-   {VIN2A_D12, (M3 | PIN_OUTPUT)}, /* vin2a_d12.rgmii1_txc */
-   {VIN2A_D13, (M3 | PIN_OUTPUT)}, /* vin2a_d13.rgmii1_txctl */
-   {VIN2A_D14, (M3 | PIN_OUTPUT)}, /* vin2a_d14.rgmii1_txd3 */
-   {VIN2A_D15, (M3 | PIN_OUTPUT)}, /* vin2a_d15.rgmii1_txd2 */
-   {VIN2A_D16, (M3 | PIN_OUTPUT)}, /* vin2a_d16.rgmii1_txd1 */
-   {VIN2A_D17, (M3 | PIN_OUTPUT)}, /* vin2a_d17.rgmii1_txd0 */
-   {VIN2A_D18, (M3 | PIN_INPUT_PULLDOWN)}, /* vin2a_d18.rgmii1_rxc */
-   {VIN2A_D19, (M3 | PIN_INPUT_PULLDOWN)}, /* vin2a_d19.rgmii1_rxctl */
-   {VIN2A_D20, (M3 | PIN_INPUT_PULLDOWN)}, /* vin2a_d20.rgmii1_rxd3 */
-   {VIN2A_D21, (M3 | PIN_INPUT_PULLDOWN)}, /* vin2a_d21.rgmii1_rxd2 */
-   {VIN2A_D22, (M3 | PIN_INPUT_PULLDOWN)}, /* vin2a_d22.rgmii1_rxd1 */
-   {VIN2A_D23, (M3 | PIN_INPUT_PULLDOWN)}, /* vin2a_d23.rgmii1_rxd0 */
+   {RGMII0_TXC, (M0 | PIN_OUTPUT | MANUAL_MODE)},  /* 
rgmii0_txc.rgmii0_txc */
+   {RGMII0_TXCTL, (M0 | PIN_OUTPUT | MANUAL_MODE)},/* 
rgmii0_txctl.rgmii0_txctl */
+   {RGMII0_TXD3, (M0 | PIN_OUTPUT | MANUAL_MODE)}, /* 
rgmii0_txd3.rgmii0_txd3 */
+   {RGMII0_TXD2, (M0 | PIN_OUTPUT | MANUAL_MODE)}, /* 
rgmii0_txd2.rgmii0_txd2 */
+   {RGMII0_TXD1, (M0 | PIN_OUTPUT | MANUAL_MODE)}, /* 
rgmii0_txd1.rgmii0_txd1 */
+   {RGMII0_TXD0, (M0 | PIN_OUTPUT | MANUAL_MODE)}, /* 
rgmii0_txd0.rgmii0_txd0 */
+   {RGMII0_RXC, (M0 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},  /* 
rgmii0_rxc.rgmii0_rxc */
+   {RGMII0_RXCTL, (M0 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/* 
rgmii0_rxctl.rgmii0_rxctl */
+   {RGMII0_RXD3, (M0 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
rgmii0_rxd3.rgmii0_rxd3 */
+   {RGMII0_RXD2, (M0 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
rgmii0_rxd2.rgmii0_rxd2 */
+   {RGMII0_RXD1, (M0 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
rgmii0_rxd1.rgmii0_rxd1 */
+   {RGMII0_RXD0, (M0 | PIN_INPUT_PULLDOWN | MANUAL_MODE)}, /* 
rgmii0_rxd0.rgmii0_rxd0 */
+   {VIN2A_D12, (M3 | PIN_OUTPUT | MANUAL_MODE)},   /* vin2a_d12.rgmii1_txc 
*/
+   {VIN2A_D13, (M3 | PIN_OUTPUT | MANUAL_MODE)},   /* 
vin2a_d13.rgmii1_txctl */
+   {VIN2A_D14, (M3 | PIN_OUTPUT | MANUAL_MODE)},   /* 
vin2a_d14.rgmii1_txd3 */
+   {VIN2A_D15, (M3 | PIN_OUTPUT | MANUAL_MODE)},   /* 
vin2a_d15.rgmii1_txd2 */
+   {VIN2A_D16, (M3 | PIN_OUTPUT | MANUAL_MODE)},   /* 
vin2a_d16.rgmii1_txd1 */
+   {VIN2A_D17, (M3 | PIN_OUTPUT | MANUAL_MODE)},   /* 
vin2a_d17.rgmii1_txd0 */
+   {VIN2A_D18, (M3 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},   /* 
vin2a_d18.rgmii1_rxc */
+   {VIN2A_D19, (M3 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},   /* 
vin2a_d19.rgmii1_rxctl */
+   {VIN2A_D20, (M3 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},   /* 
vin2a_d20.rgmii1_rxd3 */
+   {VIN2A_D21, (M3 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},   /* 
vin2a_d21.rgmii1_rxd2 */
+   {VIN2A_D22, (M3 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},   /* 
vin2a_d22.rgmii1_rxd1 */
+   {VIN2A_D23, (M3 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},   /* 
vin2a_d23.rgmii1_rxd0 */
{XREF_CLK2, (M5 | PIN_INPUT_PULLDOWN)}, /* xref_clk2.atl_clk2 */
 };
 
@@ -428,7 +428,32 @@ 

[U-Boot] [PATCH 04/11] board: ti: dra71x-evm: Add PMIC support

[Lokesh Vutla]

From: Keerthy 

Add the pmic_data for LP873x PMIC which is used to power
up dra71x-evm.

Note: As per the DM[1] DRA71x supports only OP_NOM. So, updating
the efuse registers only to use OPP_NOM irrespective of any
CONFIG_DRA7__OPP_{NOM,od,high} is defined.

[1] http://www.ti.com/product/DRA718/technicaldocuments

Signed-off-by: Keerthy 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/include/asm/arch-omap5/clock.h |  8 +
 arch/arm/include/asm/omap_common.h  |  1 +
 arch/arm/mach-omap2/omap5/hw_data.c | 16 ++
 board/ti/dra7xx/evm.c   | 52 +
 4 files changed, 77 insertions(+)

diff --git a/arch/arm/include/asm/arch-omap5/clock.h 
b/arch/arm/include/asm/arch-omap5/clock.h
index e8b286b..d104ad2 100644
--- a/arch/arm/include/asm/arch-omap5/clock.h
+++ b/arch/arm/include/asm/arch-omap5/clock.h
@@ -324,6 +324,9 @@
 /* Standard offset is 0.5v expressed in uv */
 #define PALMAS_SMPS_BASE_VOLT_UV 50
 
+/* Offset is 0.73V for LP873x */
+#define LP873X_BUCK_BASE_VOLT_UV   73
+
 /* TPS659038 */
 #define TPS659038_I2C_SLAVE_ADDR   0x58
 #define TPS659038_REG_ADDR_SMPS12  0x23
@@ -338,6 +341,11 @@
 #define TPS65917_REG_ADDR_SMPS20x27
 #define TPS65917_REG_ADDR_SMPS30x2F
 
+/* LP873X */
+#define LP873X_I2C_SLAVE_ADDR  0x60
+#define LP873X_REG_ADDR_BUCK0  0x6
+#define LP873X_REG_ADDR_BUCK1  0x7
+#define LP873X_REG_ADDR_LDO1   0xA
 
 /* TPS */
 #define TPS62361_I2C_SLAVE_ADDR0x60
diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 00bd9fc..41986ae 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -600,6 +600,7 @@ extern struct omap_sys_ctrl_regs const omap5_ctrl;
 extern struct omap_sys_ctrl_regs const dra7xx_ctrl;
 
 extern struct pmic_data tps659038;
+extern struct pmic_data lp8733;
 
 void hw_data_init(void);
 
diff --git a/arch/arm/mach-omap2/omap5/hw_data.c 
b/arch/arm/mach-omap2/omap5/hw_data.c
index 0674480..8e7480e 100644
--- a/arch/arm/mach-omap2/omap5/hw_data.c
+++ b/arch/arm/mach-omap2/omap5/hw_data.c
@@ -336,6 +336,22 @@ struct pmic_data tps659038 = {
.gpio_en = 0,
 };
 
+/* The LP8732 and LP8733 are software-compatible, use common struct */
+struct pmic_data lp8733 = {
+   .base_offset = LP873X_BUCK_BASE_VOLT_UV,
+   .step = 5000, /* 5 mV represented in uV */
+   /*
+* Offset codes 0 - 0x13 Invalid.
+* Offset codes 0x14 0x17 give 10mV steps
+* Offset codes 0x17 through 0x9D give 5mV steps
+* So let us start with our operating range from .73V
+*/
+   .start_code = 0x17,
+   .i2c_slave_addr = 0x60,
+   .pmic_bus_init  = gpi2c_init,
+   .pmic_write = palmas_i2c_write_u8,
+};
+
 struct vcores_data omap5430_volts = {
.mpu.value[OPP_NOM] = VDD_MPU,
.mpu.addr = SMPS_REG_ADDR_12_MPU,
diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index b2ca75b..f2a60ae 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -408,10 +408,60 @@ struct vcores_data dra722_volts = {
.iva.abb_tx_done_mask = OMAP_ABB_IVA_TXDONE_MASK,
 };
 
+struct vcores_data dra718_volts = {
+   /*
+* In the case of dra71x GPU MPU and CORE
+* are all powered up by BUCK0 of LP873X PMIC
+*/
+   .mpu.value[OPP_NOM] = VDD_MPU_DRA7_NOM,
+   .mpu.efuse.reg[OPP_NOM] = STD_FUSE_OPP_VMIN_MPU_NOM,
+   .mpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
+   .mpu.addr   = LP873X_REG_ADDR_BUCK0,
+   .mpu.pmic   = ,
+   .mpu.abb_tx_done_mask = OMAP_ABB_MPU_TXDONE_MASK,
+
+   .core.value[OPP_NOM]= VDD_CORE_DRA7_NOM,
+   .core.efuse.reg[OPP_NOM]= STD_FUSE_OPP_VMIN_CORE_NOM,
+   .core.efuse.reg_bits = DRA752_EFUSE_REGBITS,
+   .core.addr  = LP873X_REG_ADDR_BUCK0,
+   .core.pmic  = ,
+
+   .gpu.value[OPP_NOM] = VDD_GPU_DRA7_NOM,
+   .gpu.efuse.reg[OPP_NOM] = STD_FUSE_OPP_VMIN_GPU_NOM,
+   .gpu.efuse.reg_bits = DRA752_EFUSE_REGBITS,
+   .gpu.addr   = LP873X_REG_ADDR_BUCK0,
+   .gpu.pmic   = ,
+   .gpu.abb_tx_done_mask = OMAP_ABB_GPU_TXDONE_MASK,
+
+   /*
+* The DSPEVE and IVA rails are grouped on DRA71x-evm
+* and are powered by BUCK1 of LP873X PMIC
+*/
+   .eve.value[OPP_NOM] = VDD_EVE_DRA7_NOM,
+   .eve.efuse.reg[OPP_NOM] = STD_FUSE_OPP_VMIN_DSPEVE_NOM,
+   .eve.efuse.reg_bits = DRA752_EFUSE_REGBITS,
+   .eve.addr   = LP873X_REG_ADDR_BUCK1,
+   .eve.pmic   = ,
+   .eve.abb_tx_done_mask = OMAP_ABB_EVE_TXDONE_MASK,
+
+   .iva.value[OPP_NOM] = VDD_IVA_DRA7_NOM,
+   .iva.efuse.reg[OPP_NOM] = STD_FUSE_OPP_VMIN_IVA_NOM,
+   .iva.efuse.reg_bits = DRA752_EFUSE_REGBITS,
+   .iva.addr   = LP873X_REG_ADDR_BUCK1,
+ 

[U-Boot] [PATCH 02/11] board: ti: dra71x-evm: Add mux settings

[Lokesh Vutla]

Add mux and iodelay settings for dra71x-evm.
Data generated using PCT_DRA71x_SR2.0_v1.0.0.0 version (June 2016).

Signed-off-by: Lokesh Vutla 
---
 board/ti/dra7xx/evm.c  |   7 +-
 board/ti/dra7xx/mux_data.h | 200 +
 2 files changed, 206 insertions(+), 1 deletion(-)

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 73d99ae..b2ca75b 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -562,7 +562,12 @@ void recalibrate_iodelay(void)
case DRA722_ES2_0:
pads = dra72x_core_padconf_array_common;
npads = ARRAY_SIZE(dra72x_core_padconf_array_common);
-   if (board_is_dra72x_revc_or_later()) {
+   if (board_is_dra71x_evm()) {
+   pads = dra71x_core_padconf_array;
+   npads = ARRAY_SIZE(dra71x_core_padconf_array);
+   iodelay = dra71_iodelay_cfg_array;
+   niodelays = ARRAY_SIZE(dra71_iodelay_cfg_array);
+   } else if (board_is_dra72x_revc_or_later()) {
delta_pads = dra72x_rgmii_padconf_array_revc;
delta_npads =
ARRAY_SIZE(dra72x_rgmii_padconf_array_revc);
diff --git a/board/ti/dra7xx/mux_data.h b/board/ti/dra7xx/mux_data.h
index 34a05dd..d071b74 100644
--- a/board/ti/dra7xx/mux_data.h
+++ b/board/ti/dra7xx/mux_data.h
@@ -220,6 +220,157 @@ const struct pad_conf_entry 
dra72x_rgmii_padconf_array_revc[] = {
{XREF_CLK2, (M5 | PIN_INPUT_PULLDOWN)}, /* xref_clk2.atl_clk2 */
 };
 
+const struct pad_conf_entry dra71x_core_padconf_array[] = {
+   {GPMC_AD0, (M3 | PIN_INPUT)},   /* gpmc_ad0.vout3_d0 */
+   {GPMC_AD1, (M3 | PIN_INPUT)},   /* gpmc_ad1.vout3_d1 */
+   {GPMC_AD2, (M3 | PIN_INPUT)},   /* gpmc_ad2.vout3_d2 */
+   {GPMC_AD3, (M3 | PIN_INPUT)},   /* gpmc_ad3.vout3_d3 */
+   {GPMC_AD4, (M3 | PIN_INPUT)},   /* gpmc_ad4.vout3_d4 */
+   {GPMC_AD5, (M3 | PIN_INPUT)},   /* gpmc_ad5.vout3_d5 */
+   {GPMC_AD6, (M3 | PIN_INPUT)},   /* gpmc_ad6.vout3_d6 */
+   {GPMC_AD7, (M3 | PIN_INPUT)},   /* gpmc_ad7.vout3_d7 */
+   {GPMC_AD8, (M3 | PIN_INPUT)},   /* gpmc_ad8.vout3_d8 */
+   {GPMC_AD9, (M3 | PIN_INPUT)},   /* gpmc_ad9.vout3_d9 */
+   {GPMC_AD10, (M3 | PIN_INPUT)},  /* gpmc_ad10.vout3_d10 */
+   {GPMC_AD11, (M3 | PIN_INPUT)},  /* gpmc_ad11.vout3_d11 */
+   {GPMC_AD12, (M3 | PIN_INPUT)},  /* gpmc_ad12.vout3_d12 */
+   {GPMC_AD13, (M3 | PIN_INPUT)},  /* gpmc_ad13.vout3_d13 */
+   {GPMC_AD14, (M3 | PIN_INPUT)},  /* gpmc_ad14.vout3_d14 */
+   {GPMC_AD15, (M3 | PIN_INPUT)},  /* gpmc_ad15.vout3_d15 */
+   {GPMC_A0, (M3 | PIN_INPUT_PULLDOWN)},   /* gpmc_a0.vout3_d16 */
+   {GPMC_A1, (M3 | PIN_INPUT_PULLDOWN)},   /* gpmc_a1.vout3_d17 */
+   {GPMC_A2, (M3 | PIN_INPUT_PULLDOWN)},   /* gpmc_a2.vout3_d18 */
+   {GPMC_A3, (M3 | PIN_INPUT_PULLDOWN)},   /* gpmc_a3.vout3_d19 */
+   {GPMC_A4, (M3 | PIN_INPUT_PULLDOWN)},   /* gpmc_a4.vout3_d20 */
+   {GPMC_A5, (M3 | PIN_INPUT_PULLDOWN)},   /* gpmc_a5.vout3_d21 */
+   {GPMC_A6, (M3 | PIN_INPUT_PULLDOWN)},   /* gpmc_a6.vout3_d22 */
+   {GPMC_A7, (M3 | PIN_INPUT_PULLDOWN)},   /* gpmc_a7.vout3_d23 */
+   {GPMC_A8, (M3 | PIN_INPUT_PULLDOWN)},   /* gpmc_a8.vout3_hsync */
+   {GPMC_A9, (M3 | PIN_INPUT_PULLDOWN)},   /* gpmc_a9.vout3_vsync */
+   {GPMC_A10, (M3 | PIN_INPUT_PULLDOWN)},  /* gpmc_a10.vout3_de */
+   {GPMC_A11, (M14 | PIN_INPUT)},  /* gpmc_a11.gpio2_1 */
+   {GPMC_A13, (M1 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/* 
gpmc_a13.qspi1_rtclk */
+   {GPMC_A14, (M1 | PIN_INPUT_PULLUP | MANUAL_MODE)},  /* 
gpmc_a14.qspi1_d3 */
+   {GPMC_A15, (M1 | PIN_INPUT_PULLUP | MANUAL_MODE)},  /* 
gpmc_a15.qspi1_d2 */
+   {GPMC_A16, (M1 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/* 
gpmc_a16.qspi1_d0 */
+   {GPMC_A17, (M1 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/* 
gpmc_a17.qspi1_d1 */
+   {GPMC_A18, (M1 | PIN_INPUT_PULLDOWN | MANUAL_MODE)},/* 
gpmc_a18.qspi1_sclk */
+   {GPMC_A19, (M1 | PIN_INPUT_PULLUP)},/* gpmc_a19.mmc2_dat4 */
+   {GPMC_A20, (M1 | PIN_INPUT_PULLUP)},/* gpmc_a20.mmc2_dat5 */
+   {GPMC_A21, (M1 | PIN_INPUT_PULLUP)},/* gpmc_a21.mmc2_dat6 */
+   {GPMC_A22, (M1 | PIN_INPUT_PULLUP)},/* gpmc_a22.mmc2_dat7 */
+   {GPMC_A23, (M1 | PIN_INPUT_PULLUP)},/* gpmc_a23.mmc2_clk */
+   {GPMC_A24, (M1 | PIN_INPUT_PULLUP)},/* gpmc_a24.mmc2_dat0 */
+   {GPMC_A25, (M1 | PIN_INPUT_PULLUP)},/* gpmc_a25.mmc2_dat1 */
+   {GPMC_A26, (M1 | PIN_INPUT_PULLUP)},/* gpmc_a26.mmc2_dat2 */
+   {GPMC_A27, (M1 | PIN_INPUT_PULLUP)},/* gpmc_a27.mmc2_dat3 */
+   {GPMC_CS1, (M1 | PIN_INPUT_PULLUP)},/* gpmc_cs1.mmc2_cmd */
+   {GPMC_CS2, (M1 | PIN_INPUT_PULLUP | MANUAL_MODE)},  /* 
gpmc_cs2.qspi1_cs0 */
+   {GPMC_CS3, (M3 | PIN_INPUT_PULLUP)},/* 

[U-Boot] [PATCH 01/11] board: ti: dra71x-evm: Add epprom support

[Lokesh Vutla]

The dra71x-evm is a board based on TI's DRA718 processor targeting BOM-optimized
entry infotainment systems such as display audio and is a software compatible
derivative of the highly successful DRA74 and DRA72 processor families.
More information can be found here[1].

Add epprom detection for dra71-evm.

[1] http://www.ti.com/product/dra718

Signed-off-by: Lokesh Vutla 
---
 board/ti/dra7xx/evm.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index e0470e9..73d99ae 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -36,6 +36,7 @@
 
 #define board_is_dra74x_evm()  board_ti_is("5777xCPU")
 #define board_is_dra72x_evm()  board_ti_is("DRA72x-T")
+#define board_is_dra71x_evm()  board_ti_is("DRA79x,D")
 #define board_is_dra74x_revh_or_later() (board_is_dra74x_evm() &&  \
(strncmp("H", board_ti_get_rev(), 1) <= 0))
 #define board_is_dra72x_revc_or_later() (board_is_dra72x_evm() &&  \
@@ -469,6 +470,8 @@ int board_late_init(void)
if (is_dra72x()) {
if (board_is_dra72x_revc_or_later())
name = "dra72x-revc";
+   else if (board_is_dra71x_evm())
+   name = "dra71x";
else
name = "dra72x";
} else {
@@ -509,6 +512,8 @@ void do_board_detect(void)
bname = "DRA74x EVM";
} else if (board_is_dra72x_evm()) {
bname = "DRA72x EVM";
+   } else if (board_is_dra71x_evm()) {
+   bname = "DRA71x EVM";
} else {
/* If EEPROM is not populated */
if (is_dra72x())
-- 
2.10.1

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

[U-Boot] [PATCH 00/11] ARM: ti: dra71: Add support for dra71-evm

[Lokesh Vutla]

This series adds support for dra71-evm. This is dependent on the OPP kconfig
support series posted recently[1].

Testing:
dra71-evm: http://pastebin.ubuntu.com/23521081/
dra72-evm-revc: http://pastebin.ubuntu.com/23521117/ 
dra7-evm: http://pastebin.ubuntu.com/23521091/ 

[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg231685.html

Keerthy (2):
  board: ti: dra71x-evm: Add PMIC support
  configs: dra7xx: Enable lp873x options

Lokesh Vutla (7):
  board: ti: dra71x-evm: Add epprom support
  board: ti: dra71x-evm: Add mux settings
  ARM: OMAP4+: Add support for getting pbias info from board
  ARM: dts: dra7xx: sync DT with latest Linux
  ARM: dts: dra71x-evm: Add DT support
  configs: dra7xx: hs: Enable DM_ETH
  configs: dra7xx: Enable pmic/regulator options

Nishanth Menon (2):
  board: ti: dra72: Introduce optimization for rgmii timing for rev C
  configs: ti_omap5_common: Select dtb name for dra71x

 arch/arm/dts/Makefile   |   2 +-
 arch/arm/dts/dra7-dspeve-thermal.dtsi   |  27 ++
 arch/arm/dts/dra7-evm.dts   | 507 --
 arch/arm/dts/dra7-iva-thermal.dtsi  |  27 ++
 arch/arm/dts/dra7.dtsi  | 717 ++--
 arch/arm/dts/dra71-evm.dts  | 230 ++
 arch/arm/dts/dra72-evm-common.dtsi  | 353 +---
 arch/arm/dts/dra72-evm-revc.dts |  30 +-
 arch/arm/dts/dra72-evm-tps65917.dtsi| 134 ++
 arch/arm/dts/dra72-evm.dts  |  37 +-
 arch/arm/dts/dra7xx-clocks.dtsi | 425 ++-
 arch/arm/include/asm/arch-omap5/clock.h |   8 +
 arch/arm/include/asm/omap_common.h  |   1 +
 arch/arm/include/asm/omap_mmc.h |   2 +-
 arch/arm/mach-omap2/omap4/hwinit.c  |  13 +
 arch/arm/mach-omap2/omap5/hw_data.c |  16 +
 arch/arm/mach-omap2/omap5/hwinit.c  |  34 ++
 board/ti/dra7xx/evm.c   |  69 ++-
 board/ti/dra7xx/mux_data.h  | 275 ++--
 configs/dra7xx_evm_defconfig|   6 +-
 configs/dra7xx_hs_evm_defconfig |  10 +-
 drivers/mmc/omap_hsmmc.c|  33 +-
 drivers/power/palmas.c  |  21 +-
 include/configs/ti_omap5_common.h   |   2 +
 include/dt-bindings/clk/ti-dra7-atl.h   |  40 ++
 include/dt-bindings/pinctrl/dra.h   |  26 ++
 include/palmas.h|  13 +-
 27 files changed, 2354 insertions(+), 704 deletions(-)
 create mode 100644 arch/arm/dts/dra7-dspeve-thermal.dtsi
 create mode 100644 arch/arm/dts/dra7-iva-thermal.dtsi
 create mode 100644 arch/arm/dts/dra71-evm.dts
 create mode 100644 arch/arm/dts/dra72-evm-tps65917.dtsi
 create mode 100644 include/dt-bindings/clk/ti-dra7-atl.h

-- 
2.10.1

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

[U-Boot] [PATCH v2 1/3] ARM: OMAP4+: Add support for dynamically selecting OPPs

[Lokesh Vutla]

It can be expected that different paper spins of a SoC can have
different definitions for OPP and can have their own constraints
on the boot up OPP for each voltage rail. In order to have this
flexibility, add support for dynamically selecting the OPP voltage
based on the board to handle any such exceptions.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/include/asm/omap_common.h  |  23 ++-
 arch/arm/mach-omap2/clocks-common.c | 116 ++--
 arch/arm/mach-omap2/omap4/hw_data.c |  24 
 arch/arm/mach-omap2/omap5/hw_data.c |  12 ++--
 board/ti/am57xx/board.c |  92 +---
 board/ti/dra7xx/evm.c   |  91 +---
 6 files changed, 254 insertions(+), 104 deletions(-)

diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 605c549..00bd9fc 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -539,18 +539,26 @@ struct pmic_data {
int (*pmic_write)(u8 sa, u8 reg_addr, u8 reg_data);
 };
 
+enum {
+   OPP_LOW,
+   OPP_NOM,
+   OPP_OD,
+   OPP_HIGH,
+   NUM_OPPS,
+};
+
 /**
  * struct volts_efuse_data - efuse definition for voltage
  * @reg:   register address for efuse
  * @reg_bits:  Number of bits in a register address, mandatory.
  */
 struct volts_efuse_data {
-   u32 reg;
+   u32 reg[NUM_OPPS];
u8 reg_bits;
 };
 
 struct volts {
-   u32 value;
+   u32 value[NUM_OPPS];
u32 addr;
struct volts_efuse_data efuse;
struct pmic_data *pmic;
@@ -558,6 +566,16 @@ struct volts {
u32 abb_tx_done_mask;
 };
 
+enum {
+   VOLT_MPU,
+   VOLT_CORE,
+   VOLT_MM,
+   VOLT_GPU,
+   VOLT_EVE,
+   VOLT_IVA,
+   NUM_VOLT_RAILS,
+};
+
 struct vcores_data {
struct volts mpu;
struct volts core;
@@ -612,6 +630,7 @@ void enable_usb_clocks(int index);
 void disable_usb_clocks(int index);
 
 void scale_vcores(struct vcores_data const *);
+int get_voltrail_opp(int rail_offset);
 u32 get_offset_code(u32 volt_offset, struct pmic_data *pmic);
 void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct pmic_data *pmic);
 void abb_setup(u32 fuse, u32 ldovbb, u32 setup, u32 control,
diff --git a/arch/arm/mach-omap2/clocks-common.c 
b/arch/arm/mach-omap2/clocks-common.c
index 9b97583..84f93e7 100644
--- a/arch/arm/mach-omap2/clocks-common.c
+++ b/arch/arm/mach-omap2/clocks-common.c
@@ -477,35 +477,45 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
gpio_direction_output(pmic->gpio, 1);
 }
 
-static u32 optimize_vcore_voltage(struct volts const *v)
+int __weak get_voltrail_opp(int rail_offset)
+{
+   /*
+* By default return OPP_NOM for all voltage rails.
+*/
+   return OPP_NOM;
+}
+
+static u32 optimize_vcore_voltage(struct volts const *v, int opp)
 {
u32 val;
-   if (!v->value)
+
+   if (!v->value[opp])
return 0;
-   if (!v->efuse.reg)
-   return v->value;
+   if (!v->efuse.reg[opp])
+   return v->value[opp];
 
switch (v->efuse.reg_bits) {
case 16:
-   val = readw(v->efuse.reg);
+   val = readw(v->efuse.reg[opp]);
break;
case 32:
-   val = readl(v->efuse.reg);
+   val = readl(v->efuse.reg[opp]);
break;
default:
printf("Error: efuse 0x%08x bits=%d unknown\n",
-  v->efuse.reg, v->efuse.reg_bits);
-   return v->value;
+  v->efuse.reg[opp], v->efuse.reg_bits);
+   return v->value[opp];
}
 
if (!val) {
printf("Error: efuse 0x%08x bits=%d val=0, using %d\n",
-  v->efuse.reg, v->efuse.reg_bits, v->value);
-   return v->value;
+  v->efuse.reg[opp], v->efuse.reg_bits, v->value[opp]);
+   return v->value[opp];
}
 
debug("%s:efuse 0x%08x bits=%d Vnom=%d, using efuse value %d\n",
- __func__, v->efuse.reg, v->efuse.reg_bits, v->value, val);
+ __func__, v->efuse.reg[opp], v->efuse.reg_bits, v->value[opp],
+ val);
return val;
 }
 
@@ -529,16 +539,19 @@ void __weak recalibrate_iodelay(void)
  */
 void scale_vcores(struct vcores_data const *vcores)
 {
-   int i;
+   int i, opp, j, ol;
struct volts *pv = (struct volts *)vcores;
struct volts *px;
 
for (i=0; i<(sizeof(struct vcores_data)/sizeof(struct volts)); i++) {
-   debug("%d -> ", pv->value);
-   if (pv->value) {
+   opp = get_voltrail_opp(i);
+   debug("%d -> ", pv->value[opp]);
+
+   if (pv->value[opp]) {
/* Handle non-empty members only */
-   pv->value = optimize_vcore_voltage(pv);
+  

[U-Boot] [PATCH v2 2/3] ARM: DRA7: Redefine voltage and efuse macros per OPP using Kconfig

[Lokesh Vutla]

From: Suman Anna 

Redefine the macros used to define the voltage values and the
efuse register offsets based on OPP for all the voltage domains.
This is done using Kconfig macros that can be set in a defconfig
or selected during a config step. This allows a voltage domain
to be configured/set to a corresponding voltage value depending
on the OPP selection choice.

The Kconfig choices have been added for MPU, DSPEVE, IVA and GPU
voltage domains, with the MPU domain restricted to OPP_NOM. The
OPP_OD and OPP_HIGH options will be added when the support for
configuring the MPU clock frequency is added. The clock
configuration for other voltage domains is out of scope in
u-boot code.

The CORE voltage domain does not have separate voltage values
and efuse register offset at different OPPs, while the MPU
voltage domain only has different efuse register offsets for
different OPPs, but uses the same voltage value. Any different
choices of OPPs for voltage domains on common ganged-rails
is automatically taken care to select the corresponding
highest OPP voltage value.

Signed-off-by: Suman Anna 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/include/asm/arch-omap5/clock.h | 47 -
 arch/arm/mach-omap2/omap5/Kconfig   | 93 +
 2 files changed, 127 insertions(+), 13 deletions(-)

diff --git a/arch/arm/include/asm/arch-omap5/clock.h 
b/arch/arm/include/asm/arch-omap5/clock.h
index 551c927..e8b286b 100644
--- a/arch/arm/include/asm/arch-omap5/clock.h
+++ b/arch/arm/include/asm/arch-omap5/clock.h
@@ -286,19 +286,40 @@
 /* STD_FUSE_OPP_VMIN_MPU_4 */
 #define STD_FUSE_OPP_VMIN_MPU_HIGH (DRA752_EFUSE_BASE + 0x1B28)
 
-/* Common voltage and Efuse register macros */
-/* DRA74x/DRA75x/DRA72x */
-#define VDD_MPU_DRA7   VDD_MPU_DRA7_NOM
-#define VDD_CORE_DRA7  VDD_CORE_DRA7_NOM
-#define VDD_EVE_DRA7   VDD_EVE_DRA7_NOM
-#define VDD_GPU_DRA7   VDD_GPU_DRA7_NOM
-#define VDD_IVA_DRA7   VDD_IVA_DRA7_NOM
-
-#define STD_FUSE_OPP_VMIN_MPU  STD_FUSE_OPP_VMIN_MPU_NOM
-#define STD_FUSE_OPP_VMIN_CORE STD_FUSE_OPP_VMIN_CORE_NOM
-#define STD_FUSE_OPP_VMIN_DSPEVE   STD_FUSE_OPP_VMIN_DSPEVE_NOM
-#define STD_FUSE_OPP_VMIN_GPU  STD_FUSE_OPP_VMIN_GPU_NOM
-#define STD_FUSE_OPP_VMIN_IVA  STD_FUSE_OPP_VMIN_IVA_NOM
+#if defined(CONFIG_DRA7_MPU_OPP_HIGH)
+#define DRA7_MPU_OPP   OPP_HIGH
+#elif defined(CONFIG_DRA7_MPU_OPP_OD)
+#define DRA7_MPU_OPP   OPP_OD
+#else /* OPP_NOM default */
+#define DRA7_MPU_OPP   OPP_NOM
+#endif
+
+/* OPP_NOM only available option for CORE */
+#define DRA7_CORE_OPP  OPP_NOM
+
+#if defined(CONFIG_DRA7_DSPEVE_OPP_HIGH)
+#define DRA7_DSPEVE_OPPOPP_HIGH
+#elif defined(CONFIG_DRA7_DSPEVE_OPP_OD)
+#define DRA7_DSPEVE_OPPOPP_OD
+#else /* OPP_NOM default */
+#define DRA7_DSPEVE_OPPOPP_NOM
+#endif
+
+#if defined(CONFIG_DRA7_IVA_OPP_HIGH)
+#define DRA7_IVA_OPP   OPP_HIGH
+#elif defined(CONFIG_DRA7_IVA_OPP_OD)
+#define DRA7_IVA_OPP   OPP_OD
+#else /* OPP_NOM default */
+#define DRA7_IVA_OPP   OPP_NOM
+#endif
+
+#if defined(CONFIG_DRA7_GPU_OPP_HIGH)
+#define DRA7_GPU_OPP   OPP_HIGH
+#elif defined(CONFIG_DRA7_GPU_OPP_OD)
+#define DRA7_GPU_OPP   OPP_OD
+#else /* OPP_NOM default */
+#define DRA7_GPU_OPP   OPP_NOM
+#endif
 
 /* Standard offset is 0.5v expressed in uv */
 #define PALMAS_SMPS_BASE_VOLT_UV 50
diff --git a/arch/arm/mach-omap2/omap5/Kconfig 
b/arch/arm/mach-omap2/omap5/Kconfig
index 22259dc..018e584 100644
--- a/arch/arm/mach-omap2/omap5/Kconfig
+++ b/arch/arm/mach-omap2/omap5/Kconfig
@@ -86,6 +86,99 @@ config TI_SECURE_EMIF_PROTECTED_REGION_SIZE
  using hardware memory firewalls. This value must be smaller than the
  TI_SECURE_EMIF_TOTAL_REGION_SIZE value.
 
+if TARGET_DRA7XX_EVM || TARGET_AM57XX_EVM
+menu "Voltage Domain OPP selections"
+
+choice
+   prompt "MPU Voltage Domain"
+   default DRA7_MPU_OPP_NOM
+help
+ Select the Operating Performance Point(OPP) for the MPU voltage
+ domain on DRA7xx & AM57xx SoCs.
+
+config DRA7_MPU_OPP_NOM
+   bool "OPP NOM"
+   help
+ This config option enables Normal OPP for MPU. This is the safest
+ option for booting.
+
+endchoice
+
+choice
+   prompt "DSPEVE Voltage Domain"
+help
+ Select the Operating Performance Point(OPP) for the DSPEVE voltage
+ domain on DRA7xx & AM57xx SoCs.
+
+config DRA7_DSPEVE_OPP_NOM
+   bool "OPP NOM"
+   help
+ This config option enables Normal OPP for DSPEVE. This is the safest
+ option for booting and choose this when unsure about other OPPs .
+
+config DRA7_DSPEVE_OPP_OD
+   bool "OPP OD"
+   help
+ This config option enables Over drive OPP for DSPEVE.
+
+config DRA7_DSPEVE_OPP_HIGH
+   bool "OPP HIGH"
+   help
+ This config option enables High OPP for DSPEVE.
+

[U-Boot] [PATCH v2 3/3] ARM: DRA7: Fixup DSPEVE, IVA and GPU clock frequencies based on OPP

[Lokesh Vutla]

From: Suman Anna 

This patch adds support to update the device-tree blob to adjust the
DSP and IVA DPLL clocks pertinent to the selected OPP choice, with
the default being OPP_NOM. The voltage settings are done in u-boot,
but the actual clock configuration itself is done in kernel because
of the following reasons:
1. SoC definition constraints us to NOT to do dynamic voltage
   scaling ever after the initial avs0 setting in bootloader
   - so the voltage must be set in bootloader.
2. The voltage level must be set even if the IP blocks like
   GPU/DSP are unused.
3. The IVA, GPU and DSP DPLLs are not essential for u-boot functionality,
   and similar DPLL clock configuration code has been cleaned up in
   v2014.10 u-boot release. See commit, 02c41535b6a4 ("ARM: OMAP4/5:
   Remove dead code against CONFIG_SYS_CLOCKS_ENABLE_ALL").

The non-essential DPLLs are configured within the kernel during
the clock init step when parsing the device tree and creating
the clock devices. This approach meets both the u-boot and kernel
needs.

Signed-off-by: Suman Anna 
Signed-off-by: Subhajit Paul 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-omap2/omap5/fdt.c | 136 
 1 file changed, 136 insertions(+)

diff --git a/arch/arm/mach-omap2/omap5/fdt.c b/arch/arm/mach-omap2/omap5/fdt.c
index da8d59b..1cc516c 100644
--- a/arch/arm/mach-omap2/omap5/fdt.c
+++ b/arch/arm/mach-omap2/omap5/fdt.c
@@ -233,6 +233,141 @@ static void ft_hs_fixups(void *fdt, bd_t *bd)
 }
 #endif /* #ifdef CONFIG_TI_SECURE_DEVICE */
 
+#if defined(CONFIG_TARGET_DRA7XX_EVM) || defined(CONFIG_TARGET_AM57XX_EVM)
+#define OPP_DSP_CLK_NUM3
+#define OPP_IVA_CLK_NUM2
+#define OPP_GPU_CLK_NUM2
+
+const char *dra7_opp_dsp_clk_names[OPP_DSP_CLK_NUM] = {
+   "dpll_dsp_ck",
+   "dpll_dsp_m2_ck",
+   "dpll_dsp_m3x2_ck",
+};
+
+const char *dra7_opp_iva_clk_names[OPP_IVA_CLK_NUM] = {
+   "dpll_iva_ck",
+   "dpll_iva_m2_ck",
+};
+
+const char *dra7_opp_gpu_clk_names[OPP_GPU_CLK_NUM] = {
+   "dpll_gpu_ck",
+   "dpll_gpu_m2_ck",
+};
+
+/* DSPEVE voltage domain */
+u32 dra7_opp_dsp_clk_rates[NUM_OPPS][OPP_DSP_CLK_NUM] = {
+   {}, /*OPP_LOW */
+   {6, 6, 4}, /* OPP_NOM */
+   {7, 7, 46667}, /* OPP_OD */
+   {75000, 75000, 5}, /* OPP_HIGH */
+};
+
+/* IVA voltage domain */
+u32 dra7_opp_iva_clk_rates[NUM_OPPS][OPP_IVA_CLK_NUM] = {
+   {}, /* OPP_LOW */
+   {116500, 38834}, /* OPP_NOM */
+   {86000, 43000}, /* OPP_OD */
+   {106400, 53200}, /* OPP_HIGH */
+};
+
+/* GPU voltage domain */
+u32 dra7_opp_gpu_clk_rates[NUM_OPPS][OPP_GPU_CLK_NUM] = {
+   {}, /* OPP_LOW */
+   {127700, 42567}, /* OPP_NOM */
+   {10, 5}, /* OPP_OD */
+   {106400, 53200}, /* OPP_HIGH */
+};
+
+static int ft_fixup_clocks(void *fdt, const char **names, u32 *rates, int num)
+{
+   int offs, node_offs, ret, i;
+   uint32_t phandle;
+
+   offs = fdt_path_offset(fdt, "/ocp/l4@4a00/cm_core_aon@5000/clocks");
+   if (offs < 0) {
+   debug("Could not find cm_core_aon clocks node path offset : 
%s\n",
+ fdt_strerror(offs));
+   return offs;
+   }
+
+   for (i = 0; i < num; i++) {
+   node_offs = fdt_subnode_offset(fdt, offs, names[i]);
+   if (node_offs < 0) {
+   debug("Could not find clock sub-node %s: %s\n",
+ names[i], fdt_strerror(node_offs));
+   return offs;
+   }
+
+   phandle = fdt_get_phandle(fdt, node_offs);
+   if (!phandle) {
+   debug("Could not find phandle for clock %s\n",
+ names[i]);
+   return -1;
+   }
+
+   ret = fdt_setprop_u32(fdt, node_offs, "assigned-clocks",
+ phandle);
+   if (ret < 0) {
+   debug("Could not add assigned-clocks property to clock 
node %s: %s\n",
+ names[i], fdt_strerror(ret));
+   return ret;
+   }
+
+   ret = fdt_setprop_u32(fdt, node_offs, "assigned-clock-rates",
+ rates[i]);
+   if (ret < 0) {
+   debug("Could not add assigned-clock-rates property to 
clock node %s: %s\n",
+ names[i], fdt_strerror(ret));
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
+static void ft_opp_clock_fixups(void *fdt, bd_t *bd)
+{
+   const char **clk_names;
+   u32 *clk_rates;
+   int ret;
+
+   if (!is_dra72x() && !is_dra7xx())
+   return;
+
+   /* fixup DSP clocks */
+   

[U-Boot] [PATCH v2 0/3] ARM: DRA7: Add Kconfig support for selecting OPPs

[Lokesh Vutla]

This series adds support for selecting DSPEVE, IVA, GPU OPPs via Kconfig
and fixup DT clock nodes as required.

Changes since v1:
- Added help option for Kconfig entries.

Lokesh Vutla (1):
  ARM: OMAP4+: Add support for dynamically selecting OPPs

Suman Anna (2):
  ARM: DRA7: Redefine voltage and efuse macros per OPP using Kconfig
  ARM: DRA7: Fixup DSPEVE, IVA and GPU clock frequencies based on OPP

 arch/arm/include/asm/arch-omap5/clock.h |  47 ---
 arch/arm/include/asm/omap_common.h  |  23 +-
 arch/arm/mach-omap2/clocks-common.c | 116 ---
 arch/arm/mach-omap2/omap4/hw_data.c |  24 +++---
 arch/arm/mach-omap2/omap5/Kconfig   |  93 ++
 arch/arm/mach-omap2/omap5/fdt.c | 136 
 arch/arm/mach-omap2/omap5/hw_data.c |  12 +--
 board/ti/am57xx/board.c |  92 -
 board/ti/dra7xx/evm.c   |  91 -
 9 files changed, 517 insertions(+), 117 deletions(-)

-- 
2.10.1

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

Re: [U-Boot] flashair and u-boot hooks script

[Michal Simek]

On 23.11.2016 00:25, Stephen Warren wrote:
> On 11/22/2016 07:33 AM, Michal Simek wrote:
>> On 22.11.2016 15:12, Michal Simek wrote:
>>> Hi guys,
>>>
>>> did you see this problem before?
>>>
>>> [bin]$ ./u-boot-test-flash xilinx_zynqmp_zcu102  zcu102
>>> 192.168.0.103 push:/tmp/tmp.I2MxPKltj7
>>> PUSH DIR: /tmp/tmp.I2MxPKltj7
>>> ..PUSH FILE: u-boot.bin
>>>  200
>>> [bin]$ ./u-boot-test-flash xilinx_zynqmp_zcu102  zcu102
>>> ./flashair.zynqmp: line 42: : No such file or directory
>>> [bin]$ ./u-boot-test-flash xilinx_zynqmp_zcu102  zcu102
>>> 192.168.0.103 rmlist:/tmp/tmp.UuwcmCDprT push:/tmp/tmp.tmM0rQ89CJ
>>> RM LIST: /tmp/tmp.UuwcmCDprT
>>> Traceback (most recent call last):
>>>   File "/home/monstr/bin/uboot-test-hooks/bin/push-flashair.py", line
>>> 118, in 
>>> main()
>>>   File "/home/monstr/bin/uboot-test-hooks/bin/push-flashair.py", line
>>> 115, in main
>>> func(args.host, param)
>>>   File "/home/monstr/bin/uboot-test-hooks/bin/push-flashair.py", line
>>> 61, in op_rm_list
>>> response = requests.get('http://%s/command.cgi' % host, params)
>>> TypeError: get() takes 1 positional argument but 2 were given
>>>
>>>
>>> Pushing files is fine but removing note. Is there any setting which
>>> needs to be done on flashair to support removing files?
>>
>> After playing with this I found that this is fixing it.
>> Why - I have no idea. Can you please make a commit message and test this?
>>
>>  diff --git a/bin/push-flashair.py b/bin/push-flashair.py
> 
>>   def op_rm_list(host, rm_list_file):
>>   print('RM LIST: ' + rm_list_file)
>>   params = {'op': 100, 'DIR': '/'}
>>  -response = requests.get('http://%s/command.cgi' % host, params)
>>  +response = requests.get('http://%s/command.cgi' % host,
>> params=params)
> 
> The docs agree with this change, so I've pushed it to the repo. I
> haven't tested it though; I figure your testing is enough given that the
> docs state params should indeed be a keyword argument.

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

[U-Boot] Query on qspi driver

[Siva Durga Prasad Paladugu]

Hi Jagan,

I am planning to send ZynqMP qspi driver to mainline. As per your recent 
patches, I can see that, you are moving qspi flash stuff to spi-nor and these 
are not in main tree yet.
As you said earlier, I have seen u-boot-spi.git and there are few branches on 
which you have spi-nor related changes. Could you please let me know branch to 
work for sending my ZynqMP qspi driver patches.
Also, could you let me know your plan or target release for spi-nor changes, so 
that I will work on it accordingly.

Regards,
Siva

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

Re: [U-Boot] [PATCH v2] powerpc: mpc512x: Add support for get_svr() for mpc512x devices

[york sun]

On 10/13/2016 11:36 PM, Sriram Dash wrote:
> Defines get_svr() for mpc512x devices
>
> Signed-off-by: Sriram Dash 
> Reviewed-by: Bin Meng 
> ---
> Changes in v2:
>   - cosmetic changes



Applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH] defconfig: am43xx_evm: Enable DM_SPI and DM_SPI_FLASH

[Mugunthan V N]

On Tuesday 22 November 2016 02:42 PM, Vignesh R wrote:
> Commit 4c4e3b37750f3("ARM: AM43xx: Enable FIT") accidentally disabled
> DM_SPI and DM_SPI_FLASH. Add back DM_SPI and DM_SPI_FLASH to
> am43xx_evm_defconfig in order to make use of DM framework for QSPI.
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Mugunthan V N 

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

Re: [U-Boot] [PATCH] configs: ls2080ardb: Enable DSPI flash support

[york sun]

On 10/10/2016 09:26 PM, Yuan Yao wrote:
> From: Yuan Yao 
>
> There is the stmicro DSPI flash on LS12080ARDB.
> Enable DSPI flash related configure options.
>
> Signed-off-by: Yuan Yao 
> ---


Applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH 2/3] ARM: DRA7: Redefine voltage and efuse macros per OPP using Kconfig

[Lokesh Vutla]

On Tuesday 22 November 2016 08:32 PM, Tom Rini wrote:
> On Tue, Nov 22, 2016 at 11:51:38AM +0530, Lokesh Vutla wrote:
>> From: Suman Anna 
>>

[..snip..]

>> +if TARGET_DRA7XX_EVM || TARGET_AM57XX_EVM
>> +menu "Voltage Domain OPP selections"
>> +
>> +choice
>> +prompt "MPU Voltage Domain"
>> +default DRA7_MPU_OPP_NOM
>> +help
>> +  Select the OPP for the MPU voltage domain on DRA7xx & AM57xx SoCs
>> +
>> +config DRA7_MPU_OPP_NOM
>> +bool "OPP NOM"
>> +
>> +endchoice
>> +
>> +choice
>> +prompt "DSPEVE Voltage Domain"
>> +help
>> +  Select the OPP for the DSPEVE voltage domain on DRA7xx and AM57xx SoCs
> 
> Can we please add some text about what NOM, OD and so forth mean in the

Sure will add it and repost.

> help text?  Also, the rest of the series is missing, thanks!

I can see it in patchworks. Am I missing something?
http://patchwork.ozlabs.org/patch/697824/
http://patchwork.ozlabs.org/patch/697823/

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

Re: [U-Boot] [PATCH] arm: exynos7420: remove custome low level init function

[york sun]

On 11/16/2016 05:44 PM, Alison Wang wrote:
>> From: Thomas Abraham 
>>
>> Remove the custom low-level initialization function and reuse the
>> default low-level initialization function. But this requires the
>> ARMV8_MULTIENTRY config option to be enabled for Exynos7420.
>>
>> On Exynos7420, the boot CPU belongs to the second cluster and so
>> with ARMV8_MULTIENTRY config option enabled, the 'branch_if_master'
>> macro fails to detect the CPU as boot CPU. As a temporary workaround
>> the CPU_RELEASE_ADDR is set to point to '_main'.
>>
>> Cc: Minkyu Kang 
>> Cc: Alison Wang 
>> Signed-off-by: Thomas Abraham 
>> ---


Applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH] ls2080: efi_loader: Move EL2 switch to function call based version

[york sun]

On 11/22/2016 09:31 AM, Alexander Graf wrote:
> We moved the EL2 switch to be function call based rather than implicit.
> This patch changes the EL3 -> EL2 switch to the new way of doing things.
>
> I've tested and verified this patch on LS2085ARDB.
>
> Signed-off-by: Alexander Graf 
>
> ---
>
> York, feel free to squash this in with the EL2 switch.

Squashed with Alison's "armv8: Support loading 32-bit OS in AArch32 
execution state", awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH] armv8/fsl-layerscape: Update CONFIG_LS2080A to CONFIG_FSL_LSCH3

[york sun]

On 11/11/2016 02:24 AM, Shengzhou Liu wrote:
> Update CONFIG_LS2080A to CONFIG_FSL_LSCH3 to make those workaround
> implementing of erratum reusable for more SoCs.
>
> Signed-off-by: Shengzhou Liu 
> ---


Applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

[U-Boot] FDT retrived raspberry pi bootargs length > 350 characters cause setenv errors, sequemce fdt get/ set/ get truncates at the first blank in the string.

[dh]

 

Imove the fdt to 0x100
fdt move ${fdt_addr}  100
fdt addr 100
 
then
fdt get value bootargs /chosen bootargs
printenv bootargs 

8250.nr_uarts=0 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=3840 
bcm2708_fb.fbheight=2160 bcm2709.boardrev=0xa02082 bcm2709.serial=0x998f552d 
smsc95xx.macaddr=B8:27:EB:8F:55:2D bcm2708_fb.fbswap=1 
bcm2709.uart_clock=4800 vc_mem.mem_base=0x3dc0 
vc_mem.mem_size=0x3f00  dwc_otg.lpm_enable=0 console=ttyS0,115200 
console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline 
fsck.repair=yes rootwait
1 ) Note: bootargs is over 480 characters long

setenv abc $bootargs fails...when bootargs is over 350 (approx) characters 
long. 
fdt set bootargs /chosen bootargs 
fdt get value bootargs /chosen bootargsbootargs=8250.nr_uarts=0Bootargs is 
truncated
The PI firmware generated bootargs parameters have blanks in the bootargs line. 
nvalue.c implements setenv in the _do_env_set()  routine, but I cannot find a 
length limit in that routine.
I'm willing to make the changes and test them.

Thanks Duncan 


   

   

 

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

Re: [U-Boot] [PATCH][v2] armv8: ls2080a: Update serdes protocol support

[york sun]

On 11/03/2016 05:30 AM, Priyanka Jain wrote:
> Add serdes protocol support for
> Serdes1 protocol: 0x39, 0x4B, 0x4C, 0x4D
> Serdes2 protocol: 0x47, 0x57
>
> Signed-off-by: Priyanka Jain 
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> ---
> Changes for v2:
>  Added signed-off-by
>

Revised commit message slightly. Applied to fsl-qoriq, awaiting 
upstream. Thanks.

York

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

Re: [U-Boot] [PATCH V2] Add support of ls1021a-iot

[york sun]

On 11/02/2016 11:23 PM, feng.l...@nxp.com wrote:
> From: Feng Li 
>
> The patch add support ls1021a-iot.
> It supports I2C, MMC, PCIe, eTSEC, SATA,
> EEPROM, CPLD, HDMI, Serial port, HXCI,
> DSPI, SD boot, QSPI boot, Broadcom wifi
> card, QCA wifi card.
>
> Signed-off-by: Feng Li 
> Cc: York Sun 
> Cc: Alison Wang 
> ---
> Changes for V2:
>   - CPU_V7_HAS_NONSEC and CPU_V7_HAS_VIRT are moved to Kconfig
>   to correctly select ARMV7_PSCI.
>   - CONFIG_ARMV7_PSCI_1_0 and CONFIG_ARMV7_PSCI_GTE_1_0 are
>   deleted.
>

Write commit message. Applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH][v2] driver: net: ldpaa_eth: Fix missing bracket issue

[york sun]

On 11/03/2016 05:45 AM, Priyanka Jain wrote:
> Signed-off-by: Priyanka Jain 
> Signed-off-by: Prabhakar Kushwaha 
> Signed-off-by: Ashish Kumar 
> ---
> Changes for v2:
>  Added signed-off-by
>


Applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH 1/2][v2] lpuart: add a get_lpuart_clk function

[york sun]

On 10/27/2016 11:36 PM, shh@gmail.com wrote:
> From: Shaohui Xie 
>
> It's not always true that LPUART clock is CONFIG_SYS_CLK_FREQ, this
> patch provides a weak function get_lpuart_clk, so that the clock can be
> ovreride on a specific board which uses different clock for LPUART.
>
> Signed-off-by: Shaohui Xie 
> ---

Reformat commit message. Applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

[U-Boot] Please pull u-boot-fsl-qoriq master

[york sun]

Tom,

The following changes since commit 693d4c9f1dc40fcf24ced459bc4d1b46db33298a:

   spl: Remove CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS (2016-11-18 21:20:59 
-0500)

are available in the git repository at:

   git://git.denx.de/u-boot-fsl-qoriq.git

for you to fetch changes up to 3db86f4bbd7a723421c8c9bf9bd09d58e17e9736:

   armv8: fsl-layerscape: Support loading 32-bit OS with PSCI enabled 
(2016-11-22 11:40:24 -0800)


Alison Wang (3):
   armv8: Support loading 32-bit OS in AArch32 execution state
   armv8: fsl-layerscape: SMP support for loading 32-bit OS
   armv8: fsl-layerscape: Support loading 32-bit OS with PSCI enabled

Feng Li (1):
   armv7: Add support of ls1021a-iot board

Hou Zhiqiang (1):
   fsl: serdes: fix a deadloop issue for P4080

Pratiyush Srivastava (1):
   armv8:ls1012a: Update bootargs for fast-boot

Priyanka Jain (8):
   armv8: ls2080a: Update serdes protocol support
   driver: net: ldpaa_eth: Fix missing bracket issue
   armv8: lsch3: Add generic get_svr() in assembly
   armv8: lsch3: Use SVR based timer base address detection
   armv8: fsl-layerscape: Update TZASC registers type
   armv8: fsl-layerscape : Check SVR for initializing TZASC
   armv8: fsl-layerscape: Add NXP LS2088A SoC support
   armv8/fsl-lsch3: Update code to release secondary cores

Shaohui Xie (3):
   lpuart: add a get_lpuart_clk function
   armv8: ls1046aqds: add lpuart support
   armv8: ls2080aqds: fix SGMII repeater settings

Shengzhou Liu (1):
   armv8/fsl-layerscape: Update CONFIG_LS2080A to CONFIG_FSL_LSCH3

Sriram Dash (1):
   powerpc: mpc512x: Add support for get_svr() for mpc512x devices

Thomas Abraham (1):
   arm: exynos7420: remove custome low level init function

Yuan Yao (3):
   configs: ls2080ardb: Enable DSPI flash support
   arm: ls1021a: improve the core frequency to 1.2GHZ
   armv8: fsl-layerscape: Add README for deploying QSPI image

  arch/arm/Kconfig   |  21 ++
  arch/arm/cpu/armv8/fsl-layerscape/cpu.c|  13 +-
  arch/arm/cpu/armv8/fsl-layerscape/cpu.h|   1 +
  arch/arm/cpu/armv8/fsl-layerscape/doc/README.qspi  |  42 +++
  arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc   |  58 
  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   | 111 +--
  arch/arm/cpu/armv8/fsl-layerscape/ls2080a_serdes.c |   6 +
  arch/arm/cpu/armv8/fsl-layerscape/mp.c |  78 -
  arch/arm/cpu/armv8/fsl-layerscape/soc.c|  13 +-
  arch/arm/cpu/armv8/sec_firmware_asm.S  |  23 ++
  arch/arm/cpu/armv8/start.S |   8 +
  arch/arm/cpu/armv8/transition.S|  35 +-
  arch/arm/dts/Makefile  |   4 +-
  arch/arm/dts/fsl-ls1046a-qds-lpuart.dts|  16 +
  arch/arm/dts/fsl-ls1046a-qds.dtsi  |   4 +
  arch/arm/dts/fsl-ls1046a.dtsi  |  54 +++
  arch/arm/dts/ls1021a-iot-duart.dts |  16 +
  arch/arm/dts/ls1021a-iot.dtsi  | 103 ++
  arch/arm/include/asm/arch-fsl-layerscape/config.h  |   1 +
  arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   4 +
  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |   9 +-
  arch/arm/include/asm/arch-fsl-layerscape/mp.h  |   6 +
  arch/arm/include/asm/arch-fsl-layerscape/soc.h |  12 +-
  arch/arm/include/asm/macro.h   | 176 +++---
  arch/arm/include/asm/system.h  | 121 ++-
  arch/arm/lib/bootm.c   |  45 ++-
  arch/arm/mach-exynos/Kconfig   |   1 +
  arch/arm/mach-exynos/soc.c |  18 +-
  arch/arm/mach-rmobile/lowlevel_init_gen3.S |   9 +-
  arch/powerpc/cpu/mpc512x/start.S   |   5 +
  arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c  |   6 +-
  board/freescale/ls1021aiot/Kconfig |  15 +
  board/freescale/ls1021aiot/MAINTAINERS |   7 +
  board/freescale/ls1021aiot/Makefile|   9 +
  board/freescale/ls1021aiot/README  |  58 
  board/freescale/ls1021aiot/dcu.c   |  47 +++
  board/freescale/ls1021aiot/ls1021aiot.c| 259 +++
  board/freescale/ls1021aiot/ls102xa_pbi.cfg |  14 +
  board/freescale/ls1021aiot/ls102xa_rcw_sd.cfg  |  27 ++
  board/freescale/ls1021aiot/psci.S  |  28 ++
  board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg|   2 +-
  board/freescale/ls1021aqds/ls102xa_rcw_sd_ifc.cfg  |   4 +-
  board/freescale/ls1021aqds/ls102xa_rcw_sd_qspi.cfg |   4 +-
  board/freescale/ls1021atwr/ls102xa_rcw_sd_ifc.cfg  |   2 +-
  board/freescale/ls1021atwr/ls102xa_rcw_sd_qspi.cfg |   2 +-
  board/freescale/ls1046aqds/ls1046aqds.c|  18 +
  board/freescale/ls2080a/MAINTAINERS|   2 +-
  

Re: [U-Boot] [PATCH V2] Add support of ls1021a-iot

[york sun]

On 11/22/2016 04:51 PM, york@nxp.com wrote:
> On 11/02/2016 11:23 PM, feng.l...@nxp.com wrote:
>> From: Feng Li 
>>
>> The patch add support ls1021a-iot.
>> It supports I2C, MMC, PCIe, eTSEC, SATA,
>> EEPROM, CPLD, HDMI, Serial port, HXCI,
>> DSPI, SD boot, QSPI boot, Broadcom wifi
>> card, QCA wifi card.
>>
>> Signed-off-by: Feng Li 
>> Cc: York Sun 
>> Cc: Alison Wang 
>> ---
>> Changes for V2:
>> - CPU_V7_HAS_NONSEC and CPU_V7_HAS_VIRT are moved to Kconfig
>> to correctly select ARMV7_PSCI.
>> - CONFIG_ARMV7_PSCI_1_0 and CONFIG_ARMV7_PSCI_GTE_1_0 are
>> deleted.
>>
>
> Write commit message. Applied to fsl-qoriq, awaiting upstream. Thanks.
>

Oops, typo. I meant "Rewrote commit message".

York

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

Re: [U-Boot] [PATCH v8 0/3] armv8: Support loading 32-bit OS in AArch32 execution state

[york sun]

On 11/09/2016 07:02 PM, Alison Wang wrote:
> This series is to support loading a 32-bit OS, the execution state will 
> change from AArch64 to AArch32 when jumping to kernel. The architecture 
> information will be got through checking FIT image, then U-Boot will load 
> 32-bit OS or 64-bit OS automatically.
>
> Spin-table method is used for secondary cores to load 32-bit OS.
> The architecture information will be got through checking FIT image and saved 
> in the os_arch element of spin-table, then the secondary cores will check 
> os_arch and jump to 32-bit OS or 64-bit OS automatically.
>
> PSCI method can also be used for secondary cores to load 32-bit OS.
> As PSCI and secure monitor firmware framework are enabled, loading 32-bit OS 
> is supported in such case. The default target exception level returned to 
> U-Boot is EL2, so the corresponding work to switch to AArch32 EL2 and jump to 
> 32-bit OS are done in U-Boot and secure firmware together.
>
> ---
> Changes in v8:
> - Fix the issue when U-Boot is running in EL2 or EL1.
> - Support loading 32-bit OS with PSCI enabled.
>
> Changes in v7:
> - Move the call for armv8_switch_to_el2_m into the first patch.
>
> Changes in v6:
> - Modified armv8_switch_to_el1(). It will always jump to ep when switching to 
> AArch64 or AArch32 modes.
> - Make other platforms compatible with the new armv8_switch_to_el2() and 
> armv8_switch_to_el1().
> - Make secondary_switch_to_el1() always jump to ep when switching to AArch64 
> or AArch32 modes.
>
> Changes in v5:
> - Modified armv8_switch_to_el2(). It will always jump to ep when switching to 
> AArch64 or AArch32 modes.
> - Make secondary_switch_to_el2() always jump to ep when switching to AArch64 
> or AArch32 modes.
>
> Changes in v4:
> - Correct config ARM64_SUPPORT_AARCH32.
> - Omit arch and ftaddr arguments.
> - Rename "xreg5" to "tmp".
> - Use xxx_RES1 to combine all RES1 fields in xxx register.
> - Use an immediate cmp directly.
> - Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32.
>
> Changes in v3:
> - Comments the functions and the arguments.
> - Rename the real parameters.
> - Use the macros instead of the magic values.
> - Remove the redundant codes.
> - Clean up all of the mess in boot_jump_linux().
> - Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system doesn't 
> support AArch32 state.
> - Adjust the arguments for armv8_switch_to_el2_m and armv8_switch_to_el1_m.
>
> Changes in v2:
> - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used
>   to switch to AArch64 EL2 or AArch32 Hyp.
> - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used
>   to switch to AArch64 EL1 or AArch32 SVC.
> - Support to call armv8_switch_to_el2_m and armv8_switch_to_el1_m.
>
> 
> Alison Wang (3):
>   armv8: Support loading 32-bit OS in AArch32 execution state

Squashed with Alex Graf's patch "ls2080: efi_loader: Move EL2 switch to 
function call based version".

>   armv8: fsl-layerscape: SMP support for loading 32-bit OS
>   armv8: fsl-layerscape: Support loading 32-bit OS with PSCI enabled
>

This set is applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH 0/6][v4] Update LS2080A SoC code to support LS2088A SoC

[york sun]

On 11/16/2016 11:00 PM, Priyanka Jain wrote:
> From: Priyanka Jain 
>
> LS2088A is similar to LS2080A SoC with some differences like
> 1)Timer controller offset is different
> 2)It has A72 cores
> 3)Process to release secondary cores is different
> 4)LS2088A SoC has TZASC controller
>
> In preparation of using same binary for LS2088A and LS2080A as both
> are using same development boards. code is update to detect difference
> based on SVR at runtime
>
>
>
> Priyanka Jain (6):
>   armv8: lsch3: Add generic get_svr() in assembly
>   armv8: lsch3: Use SVR based timer base address detection
>   armv8: fsl-layerscape: Update TZASC registers type
>   armv8: fsl-layerscape : Check SVR for initializing TZASC
>   armv8: fsl-layerscape: Add NXP LS2088A SoC support
>   armv8/fsl-lsch3: Update code to release secondary cores

Remove "inline" from declaration of initiator_type().

>

This set is applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH v3] armv8: fsl-layerscape: Add Readme for deploy QSPI image

[york sun]

On 11/08/2016 08:03 PM, Yuan Yao wrote:
> From: Yuan Yao 
>
> Signed-off-by: Yuan Yao 
> ---
> Changed in v3:
>   Rename README.deploy to README.qspi
> Changed in v2:
>   Move the readme for QSPI deploy out of only for ls2080aqds.
> ---


Revised commit subject slightly. Applied to fsl-qoriq, awaiting 
upstream. Thanks.

York

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

Re: [U-Boot] [PATCH v2] arm: ls1021a: improve the core frequency to 1.2GHZ

[york sun]

On 11/08/2016 07:32 PM, Yuan Yao wrote:
> From: Yuan Yao 
>
> Change core clock to 1.2GHz in the configurations for SD and NAND boot.
>
> Signed-off-by: Yuan Yao 
> ---
> Changed in v2:
>   Updated the commit message.


Applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH] armv8: ls2080aqds: fix SGMII repeater settings

[york sun]

On 10/17/2016 01:33 AM, shh@gmail.com wrote:
> From: Shaohui Xie 
>
> The current value to check whether the PHY was configured has dependency
> on MC, it expects MC to start PCS AN, this is not true during boot up,
> so it should be changed to remove the dependency.
>
> The PHY's register space should be restore to default after accessing
> extended space.
>
> Signed-off-by: Shaohui Xie 
> ---


Applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH] fsl: serdes: fix a deadloop issue for P4080

[york sun]

On 10/30/2016 08:12 PM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> This deadloop is introduced by commit:
> 71fe222 fsl: serdes: ensure accessing the initialized maps of serdes protocol
>
> deadloop detail:
> cpu_init_r => fsl_serdes_init => p4080_erratum_serdes_a005 =>
> is_serdes_configured => fsl_serdes_init
>
> Signed-off-by: Hou Zhiqiang 
> ---


Applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH 2/2][v2] armv8: ls1046aqds: add lpuart support

[york sun]

On 10/27/2016 11:36 PM, shh@gmail.com wrote:
> From: Shaohui Xie 
>
> LPUART0 is used by default, and it's using platform clock.
>
> Signed-off-by: Shaohui Xie 
> ---
> changes in v2:
> 1. dropped CONFIG_LPUART_CLK.
> 2. uses CONFIG_SYS_FSL_DDR4 in defconfig.
>


Applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

Re: [U-Boot] [PATCH] armv8:ls1012a: Update bootargs for fast-boot

[york sun]

On 10/10/2016 12:36 AM, Pratiyush Srivastava wrote:
> Add optimization parameters like "quiet" in bootargs to reduce the system
> boot time
>
> Signed-off-by: Pratiyush Mohan Srivastava 
> Signed-off-by: Harninder Rai 
> ---

Applied to fsl-qoriq, awaiting upstream. Thanks.

York

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

[U-Boot] [PATCH u-boot 2/5] aspeed: Fixed incosistency in some SCU registers naming.

[maxims]

From: Maxim Sloyko 

Basically fixed FUC/FUN typo that went out of hand.

Signed-off-by: Maxim Sloyko 
---
 arch/arm/include/asm/arch-aspeed/regs-scu.h | 73 -
 arch/arm/mach-aspeed/ast-scu.c  |  2 +-
 2 files changed, 42 insertions(+), 33 deletions(-)

diff --git a/arch/arm/include/asm/arch-aspeed/regs-scu.h 
b/arch/arm/include/asm/arch-aspeed/regs-scu.h
index b714fa9..6cb4d0d 100644
--- a/arch/arm/include/asm/arch-aspeed/regs-scu.h
+++ b/arch/arm/include/asm/arch-aspeed/regs-scu.h
@@ -830,49 +830,53 @@
 /* AST_SCU_FUN_PIN_CTRL5   0x90 - Multi-function Pin Control#5 */
 #define SCU_FUN_PIN_SPICS1 (0x1 << 31)
 #define SCU_FUN_PIN_LPC_PLUS   (0x1 << 30)
-#define SCU_FUC_PIN_USB20_HOST (0x1 << 29)
-#define SCU_FUC_PIN_USB11_PORT4(0x1 << 28)
-#define SCU_FUC_PIN_I2C14  (0x1 << 27)
-#define SCU_FUC_PIN_I2C13  (0x1 << 26)
-#define SCU_FUC_PIN_I2C12  (0x1 << 25)
-#define SCU_FUC_PIN_I2C11  (0x1 << 24)
-#define SCU_FUC_PIN_I2C10  (0x1 << 23)
-#define SCU_FUC_PIN_I2C9   (0x1 << 22)
-#define SCU_FUC_PIN_I2C8   (0x1 << 21)
-#define SCU_FUC_PIN_I2C7   (0x1 << 20)
-#define SCU_FUC_PIN_I2C6   (0x1 << 19)
-#define SCU_FUC_PIN_I2C5   (0x1 << 18)
-#define SCU_FUC_PIN_I2C4   (0x1 << 17)
-#define SCU_FUC_PIN_I2C3   (0x1 << 16)
-#define SCU_FUC_PIN_MII2_RX_DWN_DIS(0x1 << 15)
-#define SCU_FUC_PIN_MII2_TX_DWN_DIS(0x1 << 14)
-#define SCU_FUC_PIN_MII1_RX_DWN_DIS(0x1 << 13)
-#define SCU_FUC_PIN_MII1_TX_DWN_DIS(0x1 << 12)
-
-#define SCU_FUC_PIN_MII2_TX_DRIV(x)(x << 10)
-#define SCU_FUC_PIN_MII2_TX_DRIV_MASK  (0x3 << 10)
-#define SCU_FUC_PIN_MII1_TX_DRIV(x)(x << 8)
-#define SCU_FUC_PIN_MII1_TX_DRIV_MASK  (0x3 << 8)
+#define SCU_FUN_PIN_USB20_HOST (0x1 << 29)
+#define SCU_FUN_PIN_USB11_PORT4(0x1 << 28)
+#define SCU_FUN_PIN_I2C14  (0x1 << 27)
+#define SCU_FUN_PIN_I2C13  (0x1 << 26)
+#define SCU_FUN_PIN_I2C12  (0x1 << 25)
+#define SCU_FUN_PIN_I2C11  (0x1 << 24)
+#define SCU_FUN_PIN_I2C10  (0x1 << 23)
+#define SCU_FUN_PIN_I2C9   (0x1 << 22)
+#define SCU_FUN_PIN_I2C8   (0x1 << 21)
+#define SCU_FUN_PIN_I2C7   (0x1 << 20)
+#define SCU_FUN_PIN_I2C6   (0x1 << 19)
+#define SCU_FUN_PIN_I2C5   (0x1 << 18)
+#define SCU_FUN_PIN_I2C4   (0x1 << 17)
+#define SCU_FUN_PIN_I2C3   (0x1 << 16)
+#define SCU_FUN_PIN_I2C(n) (0x1 << (16 + (n) - 3))
+#define SCU_FUN_PIN_MII2_RX_DWN_DIS(0x1 << 15)
+#define SCU_FUN_PIN_MII2_TX_DWN_DIS(0x1 << 14)
+#define SCU_FUN_PIN_MII1_RX_DWN_DIS(0x1 << 13)
+#define SCU_FUN_PIN_MII1_TX_DWN_DIS(0x1 << 12)
+
+#define SCU_I2C_MIN_BUS_NUM(1)
+#define SCU_I2C_MAX_BUS_NUM(14)
+
+#define SCU_FUN_PIN_MII2_TX_DRIV(x)(x << 10)
+#define SCU_FUN_PIN_MII2_TX_DRIV_MASK  (0x3 << 10)
+#define SCU_FUN_PIN_MII1_TX_DRIV(x)(x << 8)
+#define SCU_FUN_PIN_MII1_TX_DRIV_MASK  (0x3 << 8)
 
 #define MII_NORMAL_DRIV0x0
 #define MII_HIGH_DRIV  0x2
 
-#define SCU_FUC_PIN_UART6  (0x1 << 7)
-#define SCU_FUC_PIN_ROM_16BIT  (0x1 << 6)
-#define SCU_FUC_PIN_DIGI_V_OUT(x)  (x)
-#define SCU_FUC_PIN_DIGI_V_OUT_MASK(0x3)
+#define SCU_FUN_PIN_UART6  (0x1 << 7)
+#define SCU_FUN_PIN_ROM_16BIT  (0x1 << 6)
+#define SCU_FUN_PIN_DIGI_V_OUT(x)  (x)
+#define SCU_FUN_PIN_DIGI_V_OUT_MASK(0x3)
 
 #define VIDEO_DISABLE  0x0
 #define VIDEO_12BITS   0x1
 #define VIDEO_24BITS   0x2
 //#define VIDEO_DISABLE0x3
 
-#define SCU_FUC_PIN_USB11_PORT2(0x1 << 3)
-#define SCU_FUC_PIN_SD1_8BIT   (0x1 << 3)
+#define SCU_FUN_PIN_USB11_PORT2(0x1 << 3)
+#define SCU_FUN_PIN_SD1_8BIT   (0x1 << 3)
 
-#define SCU_FUC_PIN_MAC1_MDIO  (0x1 << 2)
-#define SCU_FUC_PIN_SD2(0x1 << 1)
-#define SCU_FUC_PIN_SD1(0x1 << 0)
+#define SCU_FUN_PIN_MAC1_MDIO  (0x1 << 2)
+#define SCU_FUN_PIN_SD2(0x1 << 1)
+#define SCU_FUN_PIN_SD1(0x1 << 0)
 
 
 /* AST_SCU_FUN_PIN_CTRL6   0x94 - Multi-function Pin Control#6*/
@@ -914,6 +918,11 @@
 #define SCU_FUN_PIN_ROMA4  (0x1 << 18)
 #define SCU_FUN_PIN_ROMA3  (0x1 << 17)
 #define SCU_FUN_PIN_ROMA2  (0x1 << 16)
+/* AST2500 only */
+#define SCU_FUN_PIN_SDA2   (0x1 << 15)
+#define SCU_FUN_PIN_SCL2   (0x1 << 14)
+#define SCU_FUN_PIN_SDA1   (0x1 << 13)
+#define SCU_FUN_PIN_SCL1   (0x1 << 12)
 
 /* AST_SCU_FUN_PIN_CTRL9   

[U-Boot] [PATCH u-boot 4/5] aspeed: Added function to configure pins for I2C devices.

[maxims]

From: Maxim Sloyko 

In the absence of pinmux driver, I2C driver will be
configuring pins directly.

Signed-off-by: Maxim Sloyko 
---
 arch/arm/include/asm/arch-aspeed/ast_scu.h |  5 +
 arch/arm/mach-aspeed/ast-scu.c | 28 
 2 files changed, 33 insertions(+)

diff --git a/arch/arm/include/asm/arch-aspeed/ast_scu.h 
b/arch/arm/include/asm/arch-aspeed/ast_scu.h
index eb5aaa2..80ebd6f 100644
--- a/arch/arm/include/asm/arch-aspeed/ast_scu.h
+++ b/arch/arm/include/asm/arch-aspeed/ast_scu.h
@@ -46,4 +46,9 @@ extern void ast_scu_init_eth(u8 num);
 extern void ast_scu_multi_func_eth(u8 num);
 extern void ast_scu_multi_func_romcs(u8 num);
 
+/* Enable I2C controller and pins for a particular device.
+ * Device numbering starts at 1
+ */
+extern void ast_scu_enable_i2c(u8 num);
+
 #endif
diff --git a/arch/arm/mach-aspeed/ast-scu.c b/arch/arm/mach-aspeed/ast-scu.c
index e00dbe2..b5aa8bf 100644
--- a/arch/arm/mach-aspeed/ast-scu.c
+++ b/arch/arm/mach-aspeed/ast-scu.c
@@ -507,3 +507,31 @@ void ast_scu_get_who_init_dram(void)
break;
}
 }
+
+void ast_scu_enable_i2c(u8 bus_num)
+{
+   if (bus_num > SCU_I2C_MAX_BUS_NUM) {
+   debug("%s: bus_num is out of range, must be [%d - %d]\n",
+ __func__, SCU_I2C_MIN_BUS_NUM, SCU_I2C_MAX_BUS_NUM);
+   return;
+   }
+
+   if (bus_num == 0) {
+   /* Enable I2C Controllers */
+   clrbits_le32(AST_SCU_BASE + AST_SCU_RESET, SCU_RESET_I2C);
+   } else if (bus_num >= 3) {
+   setbits_le32(AST_SCU_BASE + AST_SCU_FUN_PIN_CTRL5,
+SCU_FUN_PIN_I2C(bus_num));
+   /* In earlier versions of the SoC these pins are always assigned to
+* respective I2C buses and require no configuration.
+*/
+#ifdef AST_SOC_G5
+   } else if (bus_num == 1) {
+   setbits_le32(AST_SCU_BASE + AST_SCU_FUN_PIN_CTRL8,
+SCU_FUN_PIN_SDA1 | SCU_FUN_PIN_SCL1);
+   } else if (bus_num == 2) {
+   setbits_le32(AST_SCU_BASE + AST_SCU_FUN_PIN_CTRL8,
+SCU_FUN_PIN_SDA2 | SCU_FUN_PIN_SCL2);
+#endif
+   }
+}
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH u-boot 1/5] aspeed/g5: Device Tree for ast2500, copied from openbmc/linux (include file), plus minimal device tree configuration for ast2500 eval board.

[maxims]

From: Maxim Sloyko 

aspeed-g5.dtsi include file is copied from
https://github.com/openbmc/linux/blob/c5682cb/arch/arm/boot/dts/aspeed-g5.dtsi

Signed-off-by: Maxim Sloyko 
---
 arch/arm/dts/Makefile  |2 +
 arch/arm/dts/aspeed-g5-evb.dts |   28 +
 arch/arm/dts/aspeed-g5.dtsi| 1278 
 3 files changed, 1308 insertions(+)
 create mode 100644 arch/arm/dts/aspeed-g5-evb.dts
 create mode 100644 arch/arm/dts/aspeed-g5.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ef573ec..333bf3b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -262,6 +262,8 @@ dtb-$(CONFIG_SOC_KEYSTONE) += k2hk-evm.dtb \
k2e-evm.dtb \
k2g-evm.dtb
 
+dtb-$(CONFIG_TARGET_AST_G5) += aspeed-g5-evb.dtb
+
 targets += $(dtb-y)
 
 # Add any required device tree compiler flags here
diff --git a/arch/arm/dts/aspeed-g5-evb.dts b/arch/arm/dts/aspeed-g5-evb.dts
new file mode 100644
index 000..95dc77a
--- /dev/null
+++ b/arch/arm/dts/aspeed-g5-evb.dts
@@ -0,0 +1,28 @@
+/dts-v1/;
+
+#include "aspeed-g5.dtsi"
+
+/ {
+   memory {
+   device_type = "memory";
+   reg = <0x8000 0x2000>;
+   };
+
+   aliases {
+   i2c1 = 
+   i2c4 = 
+   i2c8 = 
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/dts/aspeed-g5.dtsi b/arch/arm/dts/aspeed-g5.dtsi
new file mode 100644
index 000..eb87728
--- /dev/null
+++ b/arch/arm/dts/aspeed-g5.dtsi
@@ -0,0 +1,1278 @@
+/* This device tree is copied from
+ * 
https://github.com/openbmc/linux/blob/c5682cb/arch/arm/boot/dts/aspeed-g5.dtsi
+ */
+
+#include "skeleton.dtsi"
+
+/ {
+   model = "Aspeed BMC";
+   compatible = "aspeed,ast2500";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   interrupt-parent = <>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   compatible = "arm,arm1176jzf-s";
+   device_type = "cpu";
+   reg = <0>;
+   };
+   };
+
+   ahb {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   fmc: flash-controller@1e62 {
+   reg = < 0x1e62 0xc4
+   0x2000 0x1000 >;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "aspeed,ast2500-fmc";
+   status = "disabled";
+   aspeed,fmc-has-dma;
+   interrupts = <19>;
+   flash@0 {
+   reg = < 0 >;
+   compatible = "jedec,spi-nor";
+   status = "disabled";
+   };
+   flash@1 {
+   reg = < 1 >;
+   compatible = "jedec,spi-nor";
+   status = "disabled";
+   };
+   flash@2 {
+   reg = < 2 >;
+   compatible = "jedec,spi-nor";
+   // compatible = "cfi,flash", "jedec,flash";
+   status = "disabled";
+   };
+   };
+
+   spi1: flash-controller@1e63 {
+   reg = < 0x1e63 0xc4
+   0x3000 0x0800 >;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "aspeed,ast2500-smc";
+   status = "disabled";
+   flash@0 {
+   reg = < 0 >;
+   compatible = "jedec,spi-nor";
+   status = "disabled";
+   };
+   flash@1 {
+   reg = < 1 >;
+   compatible = "jedec,spi-nor";
+   status = "disabled";
+   };
+   };
+
+   spi2: flash-controller@1e631000 {
+   reg = < 0x1e631000 0xc4
+   0x3800 0x0800 >;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "aspeed,ast2500-smc";
+   status = "disabled";
+   flash@0 {
+   reg = < 0 >;
+   compatible = "jedec,spi-nor";
+   status = "disabled";
+   };
+   

Re: [U-Boot] flashair and u-boot hooks script

[Stephen Warren]

On 11/22/2016 07:33 AM, Michal Simek wrote:

On 22.11.2016 15:12, Michal Simek wrote:

Hi guys,

did you see this problem before?

[bin]$ ./u-boot-test-flash xilinx_zynqmp_zcu102  zcu102
192.168.0.103 push:/tmp/tmp.I2MxPKltj7
PUSH DIR: /tmp/tmp.I2MxPKltj7
..PUSH FILE: u-boot.bin
 200
[bin]$ ./u-boot-test-flash xilinx_zynqmp_zcu102  zcu102
./flashair.zynqmp: line 42: : No such file or directory
[bin]$ ./u-boot-test-flash xilinx_zynqmp_zcu102  zcu102
192.168.0.103 rmlist:/tmp/tmp.UuwcmCDprT push:/tmp/tmp.tmM0rQ89CJ
RM LIST: /tmp/tmp.UuwcmCDprT
Traceback (most recent call last):
  File "/home/monstr/bin/uboot-test-hooks/bin/push-flashair.py", line
118, in 
main()
  File "/home/monstr/bin/uboot-test-hooks/bin/push-flashair.py", line
115, in main
func(args.host, param)
  File "/home/monstr/bin/uboot-test-hooks/bin/push-flashair.py", line
61, in op_rm_list
response = requests.get('http://%s/command.cgi' % host, params)
TypeError: get() takes 1 positional argument but 2 were given


Pushing files is fine but removing note. Is there any setting which
needs to be done on flashair to support removing files?


After playing with this I found that this is fixing it.
Why - I have no idea. Can you please make a commit message and test this?

 diff --git a/bin/push-flashair.py b/bin/push-flashair.py



  def op_rm_list(host, rm_list_file):
  print('RM LIST: ' + rm_list_file)
  params = {'op': 100, 'DIR': '/'}
 -response = requests.get('http://%s/command.cgi' % host, params)
 +response = requests.get('http://%s/command.cgi' % host, params=params)


The docs agree with this change, so I've pushed it to the repo. I 
haven't tested it though; I figure your testing is enough given that the 
docs state params should indeed be a keyword argument.

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

Re: [U-Boot] [RFC PATCH v2 4/7] env: Introduce "transient" and "system" access flags

[Simon Glass]

Hi Bernhard,

On 22 November 2016 at 11:54, Bernhard Nortmann
 wrote:
> Hi Simon!
>
> Am 19.11.2016 um 14:47 schrieb Simon Glass:
>>
>> Hi Bernhard,
>>
>> On 16 November 2016 at 03:29, Bernhard Nortmann
>>  wrote:
>>>
>>> "transient" (='t') is like "any", but requests that a variable
>>> should not be exported (ENV_FLAGS_VARACCESS_PREVENT_EXPORT).
>>>
>>> "system" (='S') is meant for 'internal' variables that
>>> aren't supposed to be changed by the user. It corresponds
>>> to "transient" plus "read-only".
>>>
>>> Signed-off-by: Bernhard Nortmann 
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Fixed outdated "env_flags_varaccess_lock" to the correct
>>>"env_flags_varaccess_system"
>>>
>>>   common/env_flags.c  | 11 +--
>>>   include/env_flags.h |  2 ++
>>>   2 files changed, 11 insertions(+), 2 deletions(-)
>>
>> Reviewed-by: Simon Glass 
>>
>> Please see below.
>>
>> [...]
>> Can these flags be shortened? This is not Java :-) Also it might be
>> helpful to use the
>>
>>[index] = value
>>
>> syntax so you can see which value it corresponds to?
>>
>> [...]
>> Regards,
>> Simon
>
>
>
> I like the [index] suggestion, which already gives a version that I find a
> lot easier to read:
>
>
> diff --git a/common/env_flags.c b/common/env_flags.c
> index f39d952..6dea70c 100644
> --- a/common/env_flags.c
> +++ b/common/env_flags.c
> @@ -28,16 +28,22 @@
>  #endif
>
>  static const char env_flags_vartype_rep[] = "sdxb"
> ENV_FLAGS_NET_VARTYPE_REPS;
> -static const char env_flags_varaccess_rep[] = "aroc";
> +static const char env_flags_varaccess_rep[] = "aroctS";
>  static const int env_flags_varaccess_mask[] = {
> -   0,
> -   ENV_FLAGS_VARACCESS_PREVENT_DELETE |
> -   ENV_FLAGS_VARACCESS_PREVENT_CREATE |
> -   ENV_FLAGS_VARACCESS_PREVENT_OVERWR,
> -   ENV_FLAGS_VARACCESS_PREVENT_DELETE |
> -   ENV_FLAGS_VARACCESS_PREVENT_OVERWR,
> -   ENV_FLAGS_VARACCESS_PREVENT_DELETE |
> -   ENV_FLAGS_VARACCESS_PREVENT_NONDEF_OVERWR};
> +   [0] =   0, /* no restrictions */
> +   [1] =   ENV_FLAGS_VARACCESS_PREVENT_DELETE
> +   | ENV_FLAGS_VARACCESS_PREVENT_CREATE
> +   | ENV_FLAGS_VARACCESS_PREVENT_OVERWR,
> +   [2] =   ENV_FLAGS_VARACCESS_PREVENT_DELETE
> +   | ENV_FLAGS_VARACCESS_PREVENT_OVERWR,
> +   [3] =   ENV_FLAGS_VARACCESS_PREVENT_DELETE
> +   | ENV_FLAGS_VARACCESS_PREVENT_NONDEF_OVERWR,
> +   [4] =   ENV_FLAGS_VARACCESS_PREVENT_EXPORT,
> +   [5] =   ENV_FLAGS_VARACCESS_PREVENT_DELETE
> +   | ENV_FLAGS_VARACCESS_PREVENT_CREATE
> +   | ENV_FLAGS_VARACCESS_PREVENT_OVERWR
> +   | ENV_FLAGS_VARACCESS_PREVENT_EXPORT
> +   };
>
>  #ifdef CONFIG_CMD_ENV_FLAGS
>  static const char * const env_flags_vartype_names[] = {
>
> As for the shortening of the various flags: The only one I'm introducing
> is ENV_FLAGS_VARACCESS_PREVENT_EXPORT (in patch 3/7), following along the
> spirit of existing ones - so I might not be the right person to bust them
> all?

Well you could add a separate patch before this one which renames
everything. I don't think anyone else is working in this area.

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

[U-Boot] [PATCH] net/phy/vitesse: Rework RGMII skew configuration for VSC8601

[Alexandru Gagniuc]

The VSC8601 config tried to add an RGMII skew based on #defines that
no config defines. That's quite an ugly way to do it. Since the skew
is only needed on RGMII interfaces, check the interface mode at
runtime, and apply the settings accordingly.

Tested on custom board with AM3352 SOC and VSC801 PHY.

Signed-off-by: Alexandru Gagniuc 
---
I've tried to make this as close as possible to the similar patch we recently
submitted for linux [1].

This patch does remove the configuration for individual RX and TX skews,
VSC8601_SKEW_(TX|RC), but I think that is safe, given that no board uses it.
That should be easy to add as a runtime check, but I'm not doing it in this
patch because I don't have a means of testing it.

The datasheet for the PHY is publicly available [2].

[1] 
https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/drivers/net/phy/vitesse.c?id=955e16026d08a601d02b961d13b6db9d6c13c8c9
[2] http://media.digikey.com/pdf/Data%20Sheets/Vitesse%20PDFs/VSC8601.pdf

 drivers/net/phy/vitesse.c | 43 ---
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 2635b82..a077b98 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -30,9 +30,8 @@
 #define MIIM_CIS8204_SLEDCON_INIT  0x1115
 
 /* Vitesse VSC8601 Extended PHY Control Register 1 */
-#define MIIM_VSC8601_EPHY_CON  0x17
-#define MIIM_VSC8601_EPHY_CON_INIT_SKEW0x1120
-#define MIIM_VSC8601_SKEW_CTRL 0x1c
+#define MII_VSC8601_EPHY_CTL   0x17
+#define MII_VSC8601_EPHY_CTL_RGMII_SKEW(1 << 8)
 
 #define PHY_EXT_PAGE_ACCESS0x1f
 #define PHY_EXT_PAGE_ACCESS_GENERAL0x10
@@ -142,26 +141,32 @@ static int cis8204_config(struct phy_device *phydev)
 }
 
 /* Vitesse VSC8601 */
+/* This adds a skew for both TX and RX clocks, so the skew should only be
+ * applied to "rgmii-id" interfaces. It may not work as expected
+ * on "rgmii-txid", "rgmii-rxid" or "rgmii" interfaces. */
+static int vsc8601_add_skew(struct phy_device *phydev)
+{
+   int ret;
+
+   ret = phy_read(phydev, MDIO_DEVAD_NONE, MII_VSC8601_EPHY_CTL);
+   if (ret < 0)
+   return ret;
+
+   ret |= MII_VSC8601_EPHY_CTL_RGMII_SKEW;
+   return phy_write(phydev, MDIO_DEVAD_NONE, MII_VSC8601_EPHY_CTL, ret);
+}
+
 static int vsc8601_config(struct phy_device *phydev)
 {
-   /* Configure some basic stuff */
-#ifdef CONFIG_SYS_VSC8601_SKEWFIX
-   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8601_EPHY_CON,
-   MIIM_VSC8601_EPHY_CON_INIT_SKEW);
-#if defined(CONFIG_SYS_VSC8601_SKEW_TX) && defined(CONFIG_SYS_VSC8601_SKEW_RX)
-   phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS, 1);
-#define VSC8101_SKEW \
-   ((CONFIG_SYS_VSC8601_SKEW_TX << 14) \
-   | (CONFIG_SYS_VSC8601_SKEW_RX << 12))
-   phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8601_SKEW_CTRL,
-   VSC8101_SKEW);
-   phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS, 0);
-#endif
-#endif
+   int ret = 0;
 
-   genphy_config_aneg(phydev);
+   if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+   ret = vsc8601_add_skew(phydev);
 
-   return 0;
+   if (ret < 0)
+   return ret;
+
+   return genphy_config_aneg(phydev);
 }
 
 static int vsc8574_config(struct phy_device *phydev)
-- 
2.7.4

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

Re: [U-Boot] [RFC PATCH v2 7/7] env: Automatically mark dynamic configuration info as "do not export"

[Bernhard Nortmann]

Hi Simon!

Am 19.11.2016 um 14:47 schrieb Simon Glass:

Hi Bernhard,

On 16 November 2016 at 03:30, Bernhard Nortmann
 wrote:

This is an attempt to prevent such information from ending up
in exported environment data, especially when doing "saveenv".
(http://lists.denx.de/pipermail/u-boot/2015-September/227611.html)

The patch makes use of the new setenv_transient() helper for
environment variables that get updated via network configuration:
BOOTP/DHCP (netboot_update_env), CDP (cdp_update_env) and
link-local protocol (do_link_local).

Signed-off-by: Bernhard Nortmann 
---

Changes in v2: None

  cmd/net.c | 34 +-
  1 file changed, 17 insertions(+), 17 deletions(-)

Reviewed-by: Simon Glass 

How would you make these variables non-transient? Does the transient
nature show up in 'printenv'?

Regards,
Simon


I think it's best to consider a practical example. I'm firing up my 
sunxi-based
device with these patches applied on top of U-Boot v2016.11, and 
interrupt the

autoboot.

The standard way to examine variables that have non-default flags is the 
"env
flags" command. In my case this outputs (discarding the explanations 
near the

top):

Static flags:
Variable NameVariable TypeVariable Access
-----
eth\d?addr   MAC address  write-once
ipaddr   IP address   any
gatewayipIP address   any
netmask  IP address   any
serverip IP address   any
nvlandecimal  any
vlan decimal  any
dnsipIP address   any
serial#  string   write-once
fel_booted   boolean  system
fel_scriptaddr   hexadecimal  system

Active flags:
Variable NameVariable TypeVariable Access
-----
serial#  string   write-once
ethaddr  MAC address  write-once
fel_booted   boolean  system

As you can see, patch 5/7 has sneaked in two new "system" flags and 
since I've
booted using the FEL mechanism, the "fel_booted" one is in effect 
("active").


Okay, now I use the command "setenv autoload no; dhcp" to auto-configure
networking. Let's check "env flags" again. The "Static flags" section is
unchanged, but at the bottom there's now:

Active flags:
Variable NameVariable TypeVariable Access
-----
ipaddr   IP address   transient
serial#  string   write-once
hostname string   transient
ethaddr  MAC address  write-once
netmask  IP address   transient
serverip IP address   transient
fel_booted   boolean  system
dnsipIP address   transient
gatewayipIP address   transient

>Does the transient nature show up in 'printenv'?

No, it doesn't. "printenv" will give output that looks as usual / perfectly
normal. You're also not restricted in modifying "transient" variables, for
example I can do "ipaddr 10.11.12.13" with no problems.

But: The differences will become apparent when trying to export the 
environment

with something like "saveenv" or "env export":
=> env export 0x4000
## Don't export "ipaddr"
## Don't export "hostname"
## Don't export "netmask"
## Don't export "serverip"
## Don't export "fel_booted"
## Don't export "dnsip"
## Don't export "gatewayip"

U-Boot refuses to store the 'volatile' information for those variables that
have been flagged accordingly, and informs the user about it. This is 
checked

individually per variable, i.e. the other ones will get exported normally.

At this point I decide that I want to set up a *static* IP configuration and
make it persistent with "saveenv". Houston, we have a problem!

>How would you make these variables non-transient?

Well, again there's a standard U-Boot mechanism for this. The README 
mentions
it in the description of CONFIG_ENV_FLAGS_LIST_STATIC: "To override a 
setting

in the static list, simply add an entry for the same variable name to the
'.flags' variable.".

So we could do "setenv .flags ipaddr:i,netmask:i,gatewayip.i" to reset the
variables to access level "any", meaning they'll get exported again.

Admittedly, there's a slight inconsistency here. Due to the fact that
setenv_transient() only sets a temporary flag, and U-Boot will rebuild the
access flags list (from the "static" 

[U-Boot] U-Boot vulnerable to CVE-2014-4607 (LZO)?

[Thomas Deutschmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

could you please help me to determine if U-Boot was or still is
vulnerable to CVE-2014-4607?

The project uses LZO decompression in

  lib/lzo/lzo1x_decompress.c


I found the following applied patch set

http://lists.denx.de/pipermail/u-boot/2014-December/197547.html

but I am not sure.

Thanks for any help!


- -- 
Regards,
Thomas
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0

iQJ8BAEBCgBmBQJYNLCXXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQzM0M1ODQ4MkM0MDIyOTJEMkUzQzVDMDY5
NzA5RjkwQzNDOTZGRkM4AAoJEJcJ+Qw8lv/IWjEP/0sl5PHukqI+aKhDtVripPU5
67QUsepFnzPTXWmaz4a4ZVYngnSaxSbrn7l12BBr5KA3h9ffkvMpP7OWy2C7+MVO
+eTOzDzMjGk5G3XLkSu3O7nnK2qqwNaoM4S+jZGrttpNXWmEVfHu3/K9vonM7WvQ
B/HDf/FpAl400HWQtbCw2uz84/J8ApHjLalhPgUxS0EF5ndhmYZGaeoioaYMXXcK
2KNbS2eydBneDuoyQJAjveDqwhRVNhqKNaBZFFq1cKVBpAVVWJy1yyQFSMwYp8st
/mLzFJ+3zBULrMbgoLGbgk5A9GGWVEMt1Z+OPhjExJDAe/zFfzr0BcdP9z5895nN
E9TfBicVTIDNlXm4T9LVa992dJKyKD599ziU8sMsL4c7SU7G0bJp+1I1IP/LaMGZ
TZ6Jcvoq/bIdfMoiY6RYjLJy1R48zwUC3BfIOz7UjhJX3WRObMXaNX9LCyih5TP3
FJVy1UB3w0zDQ53LZTvsJghQlbkEwHUaLA9ePjlnugeS5oLrtnrDR+jQYsvifRCB
QMYkFloNUjNBuOIe/gTrNzfZCwk8M2zGB4efYPhVBnWUdH/fiETGC8PdzwL54uQk
lvXuBWGprQXHqdjwMUblDUm3CucAFsB38y31ax3D062UySB2KO5xfb48pxe0inZX
/WuG9EAxfcK7PzQYcOVw
=fgWw
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it

[Alexander Graf]

On 22/11/2016 18:50, Simon Glass wrote:

Hi Alex,

On 19 November 2016 at 17:13, Alexander Graf  wrote:




Am 20.11.2016 um 00:56 schrieb Simon Glass :

Hi Alex,


On 19 November 2016 at 14:47, Alexander Graf  wrote:



Am 19.11.2016 um 21:02 schrieb Simon Glass :

Hi Alex,


On 19 November 2016 at 07:13, Alexander Graf  wrote:



On 19/11/2016 14:48, Simon Glass wrote:

Hi Alex,


On 17 November 2016 at 10:31, Alexander Graf  wrote:

Today we can compile a self-contained hello world efi test binary that
allows us to quickly verify whether the EFI loader framwork works.

We can use that binary outside of the self-contained test case though,
by providing it to a to-be-tested system via tftp.

This patch separates compilation of the helloworld.efi file from
including it in the u-boot binary for "bootefi hello". It also modifies
the efi_loader test case to enable travis to pick up the compiled file.
Because we're now no longer bloating the resulting u-boot binary, we
can enable compilation always, giving us good travis test coverage.

Signed-off-by: Alexander Graf 
---
arch/arm/lib/Makefile|  2 +-
arch/x86/config.mk   |  2 +-
arch/x86/lib/Makefile|  2 +-
cmd/Kconfig  | 15 ++-
configs/qemu-x86_efi_payload64_defconfig |  1 +
lib/efi_loader/Makefile  |  3 +++
test/py/tests/test_efi_loader.py |  2 +-
7 files changed, 22 insertions(+), 5 deletions(-)



Ick.

Can you not achieve the same effect just by copying the file somewhere?



Sure, we could. But the file is only defined inside the env of the
particular test case. So if you want to test against non-travis, you can
copy it wherever you like.

This way the travis description simplifies a lot, because we can just expose
the build directory as tftp root.


Or use .PRECIOUS on the existing file? You could copy it into the root
directory of the build, perhaps? It just seems like a lot of extra
stuff for a file that is already built.


I want to make sure that by default we never compile the hello world efi 
example into the u-boot binary, but still have the file build tested and 
available for travis.


So how about just having two cases:

1. Compile hello world and produce it as an output
2. As 1 but also build it into the U-Boot binary


Yes, that's precisely what this patch does :). I'm glad we agree.


Except that I don't think we need the extra CONFIG.


If that's the only disagreement we have, then let's have the extra 
CONFIG. Having more usually shouldn't hurt.



The first one could be controlled by EFI_LOADER,


Unfortunately the hello world binary doesn't build on stm32 while there is no 
reason to disable EFI_LOADER on that platform, so I want to keep the options 
separately.


Well if no one can compile for stm32 then it is unlikely to work
anyway. Does anyone actually use Thumb 1 with EFI?


I've verified thumb 1 back in the day when I did the setjmp/longjmp 
implementation, yeah.



Also, if someone comes in and enables a new architecture, I would like to make 
the bar as low as I can for that. For that reason too, I would prefer to keep 
it as a separate config option.


I think you might have it backwards. As someone who just enabled a new
architecture (x86) I can tell you that the best approach by far was to
use the embedded hello world test. In fact that is why I wrote it. It
provides a fast and easy to test to allow things to be brought up.
Using something like grub is so much more painful.


I think you might have it backwards :). Different people have different 
approaches to problems. If someone wants to port the hello world example 
first, I'm more than happy to have them do it. But if their flow is 
different, I'm not going to be the one standing in their way.


My goal is to have EFI support enabled and working well for as many 
devices as we can. The path to get there doesn't matter that much to me.







the second with the
existing option for the 'bootefi hello' command.


Yes, that too is what the patch does :).


So I think we should disable the one stm32 board until someone
actually gets it working, at least with the hello world test.


Can you prove that it doesn't work? So far the only thing that breaks is 
your new hello world test code.



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

Re: [U-Boot] [PATCH] arm: exynos7420: remove custome low level init function

[york sun]

On 11/16/2016 05:44 PM, Alison Wang wrote:
>> From: Thomas Abraham 
>>

> Reviewed-by: Alison Wang 
>

I will merge this patch.

York

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

Re: [U-Boot] [RFC PATCH v2 6/7] env: Introduce setenv_transient() helper function

[Bernhard Nortmann]

Hi Simon!

Am 19.11.2016 um 14:47 schrieb Simon Glass:

Hi Bernhard,

On 16 November 2016 at 03:30, Bernhard Nortmann
 wrote:

Like setenv(), but automatically marks the entry as "don't export".

Signed-off-by: Bernhard Nortmann 
---

Changes in v2: None

  cmd/nvedit.c | 21 +
  include/common.h |  1 +
  2 files changed, 22 insertions(+)


Reviewed-by: Simon Glass 

But see below.

[...]
I think returning the error right away is better here.

   if (rc)
return rc;

[...]
return 0;


Makes sense, I'll change that.


[...]
Please add a function comment and parameter names.


There are inconsistent coding styles here. getenv_hex() has a documentation
comment in include/common.h, getenv_yesno() only a standard comment. The
inline function setenv_addr() is both documented and implemented there.
setenv() has no comments at all. Other functions have their documentation
(next to their implementation) in cmd/nvedit.c - which is what I usually
prefer over 'inflating' the header, too.

For setenv_transient() I oriented myself at the 'parent' function setenv(),
but added a documentation comment in cmd/nvedit.c. I'm fine with adding
@param and @return descriptions, and parameter names to include/common.h.
If you insist, I could also move the description over there.

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

Re: [U-Boot] [RFC PATCH v2 4/7] env: Introduce "transient" and "system" access flags

[Bernhard Nortmann]

Hi Simon!

Am 19.11.2016 um 14:47 schrieb Simon Glass:

Hi Bernhard,

On 16 November 2016 at 03:29, Bernhard Nortmann
 wrote:

"transient" (='t') is like "any", but requests that a variable
should not be exported (ENV_FLAGS_VARACCESS_PREVENT_EXPORT).

"system" (='S') is meant for 'internal' variables that
aren't supposed to be changed by the user. It corresponds
to "transient" plus "read-only".

Signed-off-by: Bernhard Nortmann 

---

Changes in v2:
- Fixed outdated "env_flags_varaccess_lock" to the correct
   "env_flags_varaccess_system"

  common/env_flags.c  | 11 +--
  include/env_flags.h |  2 ++
  2 files changed, 11 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 

Please see below.

[...]
Can these flags be shortened? This is not Java :-) Also it might be
helpful to use the

   [index] = value

syntax so you can see which value it corresponds to?

[...]
Regards,
Simon



I like the [index] suggestion, which already gives a version that I find 
a lot easier to read:



diff --git a/common/env_flags.c b/common/env_flags.c
index f39d952..6dea70c 100644
--- a/common/env_flags.c
+++ b/common/env_flags.c
@@ -28,16 +28,22 @@
 #endif

 static const char env_flags_vartype_rep[] = "sdxb" 
ENV_FLAGS_NET_VARTYPE_REPS;

-static const char env_flags_varaccess_rep[] = "aroc";
+static const char env_flags_varaccess_rep[] = "aroctS";
 static const int env_flags_varaccess_mask[] = {
-   0,
-   ENV_FLAGS_VARACCESS_PREVENT_DELETE |
-   ENV_FLAGS_VARACCESS_PREVENT_CREATE |
-   ENV_FLAGS_VARACCESS_PREVENT_OVERWR,
-   ENV_FLAGS_VARACCESS_PREVENT_DELETE |
-   ENV_FLAGS_VARACCESS_PREVENT_OVERWR,
-   ENV_FLAGS_VARACCESS_PREVENT_DELETE |
-   ENV_FLAGS_VARACCESS_PREVENT_NONDEF_OVERWR};
+   [0] =   0, /* no restrictions */
+   [1] =   ENV_FLAGS_VARACCESS_PREVENT_DELETE
+   | ENV_FLAGS_VARACCESS_PREVENT_CREATE
+   | ENV_FLAGS_VARACCESS_PREVENT_OVERWR,
+   [2] =   ENV_FLAGS_VARACCESS_PREVENT_DELETE
+   | ENV_FLAGS_VARACCESS_PREVENT_OVERWR,
+   [3] =   ENV_FLAGS_VARACCESS_PREVENT_DELETE
+   | ENV_FLAGS_VARACCESS_PREVENT_NONDEF_OVERWR,
+   [4] =   ENV_FLAGS_VARACCESS_PREVENT_EXPORT,
+   [5] =   ENV_FLAGS_VARACCESS_PREVENT_DELETE
+   | ENV_FLAGS_VARACCESS_PREVENT_CREATE
+   | ENV_FLAGS_VARACCESS_PREVENT_OVERWR
+   | ENV_FLAGS_VARACCESS_PREVENT_EXPORT
+   };

 #ifdef CONFIG_CMD_ENV_FLAGS
 static const char * const env_flags_vartype_names[] = {

As for the shortening of the various flags: The only one I'm introducing
is ENV_FLAGS_VARACCESS_PREVENT_EXPORT (in patch 3/7), following along the
spirit of existing ones - so I might not be the right person to bust them
all?

Regards, B. Nortmann

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

Re: [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it

[Alexander Graf]

> Am 22.11.2016 um 19:27 schrieb Tom Rini :
> 
>> On Tue, Nov 22, 2016 at 10:50:50AM -0700, Simon Glass wrote:
>> Hi Alex,
>> 
>> On 19 November 2016 at 17:13, Alexander Graf  wrote:
> [snip]
>>> Unfortunately the hello world binary doesn't build on stm32 while there is 
>>> no reason to disable EFI_LOADER on that platform, so I want to keep the 
>>> options separately.
>> 
>> Well if no one can compile for stm32 then it is unlikely to work
>> anyway. Does anyone actually use Thumb 1 with EFI?
> 
> On just this point, maybe the right answer is to say we turn off EFI for
> STM32 as no, that sounds a bit overkill.

EFI support should work just fine with Thumb 1. the hello world crt0 is what's 
breaking.

Alex

> 
> -- 
> Tom

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

Re: [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it

[Tom Rini]

On Tue, Nov 22, 2016 at 10:50:50AM -0700, Simon Glass wrote:
> Hi Alex,
> 
> On 19 November 2016 at 17:13, Alexander Graf  wrote:
[snip]
> > Unfortunately the hello world binary doesn't build on stm32 while there is 
> > no reason to disable EFI_LOADER on that platform, so I want to keep the 
> > options separately.
> 
> Well if no one can compile for stm32 then it is unlikely to work
> anyway. Does anyone actually use Thumb 1 with EFI?

On just this point, maybe the right answer is to say we turn off EFI for
STM32 as no, that sounds a bit overkill.

-- 
Tom


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

Re: [U-Boot] [PATCH v2 4/4] davinci: omapl138_lcdk: add u-boot sector for mmc/sd boot

[Tom Rini]

On Tue, Nov 22, 2016 at 06:13:33PM +0100, Fabien Parent wrote:

> Set the correct CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR value in order
> to be able to boot from MMC/SD.
> 
> The SPL is stored at sector 0x75, while u-boot will follow at
> sector 0xb5.
> 
> Signed-off-by: Fabien Parent 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 2/4] davinci: omapl138_lcdk: configure ddr2

[Tom Rini]

On Tue, Nov 22, 2016 at 06:13:31PM +0100, Fabien Parent wrote:

> The SPL is unable to load u-boot because the DDR2 is not configured.
> Configure the DDR2.
> 
> Signed-off-by: Fabien Parent 
> ---
> 
> V1 -> V2
> 
> * New patch
> 
> ---
>  include/configs/omapl138_lcdk.h | 42 
> +
>  1 file changed, 42 insertions(+)
> 
> diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h
> index ce3a8f4..2cdf892 100644
> --- a/include/configs/omapl138_lcdk.h
> +++ b/include/configs/omapl138_lcdk.h
> @@ -31,6 +31,7 @@
>  #define CONFIG_SYS_HZ_CLOCK  clk_get(DAVINCI_AUXCLK_CLKID)
>  #define CONFIG_SYS_HZ1000
>  #define CONFIG_SYS_DA850_PLL_INIT
> +#define CONFIG_SYS_DA850_DDR_INIT
>  #define CONFIG_SKIP_LOWLEVEL_INIT
>  #define CONFIG_SYS_TEXT_BASE 0xc108

This would be "easy" to move to Kconfig, so please do.

> @@ -80,6 +81,47 @@
>  #define CONFIG_SYS_DA850_PLL1_PLLM 21
>  
>  /*
> + * DDR2 memory configuration
> + */
> +#define CONFIG_SYS_DA850_DDR2_DDRPHYCR (DV_DDR_PHY_PWRDNEN | \
> + DV_DDR_PHY_EXT_STRBEN | \
> + (0x5 << DV_DDR_PHY_RD_LATENCY_SHIFT))
> +
> +#define CONFIG_SYS_DA850_DDR2_SDBCR (  \
> + (1 << DV_DDR_SDCR_DDR2EN_SHIFT) | \
> + (1 << DV_DDR_SDCR_DDREN_SHIFT)  | \
> + (1 << DV_DDR_SDCR_SDRAMEN_SHIFT)| \
> + (1 << DV_DDR_SDCR_BUS_WIDTH_SHIFT)  | \
> + (4 << DV_DDR_SDCR_CL_SHIFT) | \
> + (3 << DV_DDR_SDCR_IBANK_SHIFT)  | \
> + (2 << DV_DDR_SDCR_PAGESIZE_SHIFT))
> +
> +/* SDBCR2 is only used if IBANK_POS bit in SDBCR is set */
> +#define CONFIG_SYS_DA850_DDR2_SDBCR2 0
> +
> +#define CONFIG_SYS_DA850_DDR2_SDTIMR ( \
> + (19 << DV_DDR_SDTMR1_RFC_SHIFT) | \
> + (1 << DV_DDR_SDTMR1_RP_SHIFT)   | \
> + (1 << DV_DDR_SDTMR1_RCD_SHIFT)  | \
> + (2 << DV_DDR_SDTMR1_WR_SHIFT)   | \
> + (6 << DV_DDR_SDTMR1_RAS_SHIFT)  | \
> + (8 << DV_DDR_SDTMR1_RC_SHIFT)   | \
> + (1 << DV_DDR_SDTMR1_RRD_SHIFT)  | \
> + (1 << DV_DDR_SDTMR1_WTR_SHIFT))
> +
> +#define CONFIG_SYS_DA850_DDR2_SDTIMR2 (\
> + (7 << DV_DDR_SDTMR2_RASMAX_SHIFT)   | \
> + (2 << DV_DDR_SDTMR2_XP_SHIFT)   | \
> + (0 << DV_DDR_SDTMR2_ODT_SHIFT)  | \
> + (10 << DV_DDR_SDTMR2_XSNR_SHIFT)| \
> + (199 << DV_DDR_SDTMR2_XSRD_SHIFT)   | \
> + (1 << DV_DDR_SDTMR2_RTP_SHIFT)  | \
> + (2 << DV_DDR_SDTMR2_CKE_SHIFT))
> +
> +#define CONFIG_SYS_DA850_DDR2_SDRCR0x0492
> +#define CONFIG_SYS_DA850_DDR2_PBBPR0x30

This is a little harder.  I think this should be done more like
arch/arm/include/asm/arch-omap3/mem.h:#define where we name-space the
values that we construct based on the part (maker and size/speed).  Do
you have time to look into this migration?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v8 1/3] armv8: Support loading 32-bit OS in AArch32 execution state

[york sun]

On 11/22/2016 09:32 AM, Alexander Graf wrote:
> On 11/21/2016 10:48 PM, york sun wrote:
>> Alex,
>>
>> Since you are most familiar with EFI boot code, can you send a patch to
>> address this? I can squash it with Alison's patch after testing. My
>> current test branch is
>> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.denx.de%2F%3Fp%3Du-boot%2Fu-boot-fsl-qoriq.git%3Ba%3Dshortlog%3Bh%3Drefs%2Fheads%2Ftest_qoriq=01%7C01%7Cyork.sun%40nxp.com%7C822c0a7505844c4f759408d412fd7f66%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=4OCWr5ZP%2B1ufIO%2FgZo69qgfMW%2F3YUb5ibJvOhhOOlEI%3D=0.
>
> Ok, you should have a patch now :). I was still able to boot SLES with it.
>

Great! Thanks.

York

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

Re: [U-Boot] [PATCH v2 1/4] davinci: omapl138_lcdk: configure pll0

[Tom Rini]

On Tue, Nov 22, 2016 at 06:13:30PM +0100, Fabien Parent wrote:

> The SPL is not able to boot properly because the PLL0 is not
> configured. Configure it.
> 
> Signed-off-by: Fabien Parent 
> ---
> 
> V1 -> V2
>  * New patch
> 
> ---
>  include/configs/omapl138_lcdk.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h
> index 854fc47..ce3a8f4 100644
> --- a/include/configs/omapl138_lcdk.h
> +++ b/include/configs/omapl138_lcdk.h
> @@ -30,6 +30,7 @@
>  #define CONFIG_SYS_TIMERBASE DAVINCI_TIMER0_BASE
>  #define CONFIG_SYS_HZ_CLOCK  clk_get(DAVINCI_AUXCLK_CLKID)
>  #define CONFIG_SYS_HZ1000
> +#define CONFIG_SYS_DA850_PLL_INIT
>  #define CONFIG_SKIP_LOWLEVEL_INIT
>  #define CONFIG_SYS_TEXT_BASE 0xc108

OK, but.. can you move this to Kconfig and migrate the small handful of
platforms that use it?  That'll be real good progress here, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v2 5/6] efi_loader: Allow to compile helloworld.efi w/o bundling it

[Simon Glass]

Hi Alex,

On 19 November 2016 at 17:13, Alexander Graf  wrote:
>
>
>> Am 20.11.2016 um 00:56 schrieb Simon Glass :
>>
>> Hi Alex,
>>
>>> On 19 November 2016 at 14:47, Alexander Graf  wrote:
>>>
>>>
 Am 19.11.2016 um 21:02 schrieb Simon Glass :

 Hi Alex,

> On 19 November 2016 at 07:13, Alexander Graf  wrote:
>
>
>> On 19/11/2016 14:48, Simon Glass wrote:
>>
>> Hi Alex,
>>
>>> On 17 November 2016 at 10:31, Alexander Graf  wrote:
>>>
>>> Today we can compile a self-contained hello world efi test binary that
>>> allows us to quickly verify whether the EFI loader framwork works.
>>>
>>> We can use that binary outside of the self-contained test case though,
>>> by providing it to a to-be-tested system via tftp.
>>>
>>> This patch separates compilation of the helloworld.efi file from
>>> including it in the u-boot binary for "bootefi hello". It also modifies
>>> the efi_loader test case to enable travis to pick up the compiled file.
>>> Because we're now no longer bloating the resulting u-boot binary, we
>>> can enable compilation always, giving us good travis test coverage.
>>>
>>> Signed-off-by: Alexander Graf 
>>> ---
>>> arch/arm/lib/Makefile|  2 +-
>>> arch/x86/config.mk   |  2 +-
>>> arch/x86/lib/Makefile|  2 +-
>>> cmd/Kconfig  | 15 ++-
>>> configs/qemu-x86_efi_payload64_defconfig |  1 +
>>> lib/efi_loader/Makefile  |  3 +++
>>> test/py/tests/test_efi_loader.py |  2 +-
>>> 7 files changed, 22 insertions(+), 5 deletions(-)
>>
>>
>> Ick.
>>
>> Can you not achieve the same effect just by copying the file somewhere?
>
>
> Sure, we could. But the file is only defined inside the env of the
> particular test case. So if you want to test against non-travis, you can
> copy it wherever you like.
>
> This way the travis description simplifies a lot, because we can just 
> expose
> the build directory as tftp root.

 Or use .PRECIOUS on the existing file? You could copy it into the root
 directory of the build, perhaps? It just seems like a lot of extra
 stuff for a file that is already built.
>>>
>>> I want to make sure that by default we never compile the hello world efi 
>>> example into the u-boot binary, but still have the file build tested and 
>>> available for travis.
>>
>> So how about just having two cases:
>>
>> 1. Compile hello world and produce it as an output
>> 2. As 1 but also build it into the U-Boot binary
>
> Yes, that's precisely what this patch does :). I'm glad we agree.

Except that I don't think we need the extra CONFIG.

>
>>
>> The first one could be controlled by EFI_LOADER,
>
> Unfortunately the hello world binary doesn't build on stm32 while there is no 
> reason to disable EFI_LOADER on that platform, so I want to keep the options 
> separately.

Well if no one can compile for stm32 then it is unlikely to work
anyway. Does anyone actually use Thumb 1 with EFI?

>
> Also, if someone comes in and enables a new architecture, I would like to 
> make the bar as low as I can for that. For that reason too, I would prefer to 
> keep it as a separate config option.

I think you might have it backwards. As someone who just enabled a new
architecture (x86) I can tell you that the best approach by far was to
use the embedded hello world test. In fact that is why I wrote it. It
provides a fast and easy to test to allow things to be brought up.
Using something like grub is so much more painful.

>
>> the second with the
>> existing option for the 'bootefi hello' command.
>
> Yes, that too is what the patch does :).

So I think we should disable the one stm32 board until someone
actually gets it working, at least with the hello world test.

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

[U-Boot] [PATCH 3/3] ARM: DRA7: Fixup DSPEVE, IVA and GPU clock frequencies based on OPP

[Lokesh Vutla]

From: Suman Anna 

This patch adds support to update the device-tree blob to adjust the
DSP and IVA DPLL clocks pertinent to the selected OPP choice, with
the default being OPP_NOM. The voltage settings are done in u-boot,
but the actual clock configuration itself is done in kernel because
of the following reasons:
1. SoC definition constraints us to NOT to do dynamic voltage
   scaling ever after the initial avs0 setting in bootloader
   - so the voltage must be set in bootloader.
2. The voltage level must be set even if the IP blocks like
   GPU/DSP are unused.
3. The IVA, GPU and DSP DPLLs are not essential for u-boot functionality,
   and similar DPLL clock configuration code has been cleaned up in
   v2014.10 u-boot release. See commit, 02c41535b6a4 ("ARM: OMAP4/5:
   Remove dead code against CONFIG_SYS_CLOCKS_ENABLE_ALL").

The non-essential DPLLs are configured within the kernel during
the clock init step when parsing the device tree and creating
the clock devices. This approach meets both the u-boot and kernel
needs.

Signed-off-by: Suman Anna 
Signed-off-by: Subhajit Paul 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/mach-omap2/omap5/fdt.c | 136 
 1 file changed, 136 insertions(+)

diff --git a/arch/arm/mach-omap2/omap5/fdt.c b/arch/arm/mach-omap2/omap5/fdt.c
index da8d59b..1cc516c 100644
--- a/arch/arm/mach-omap2/omap5/fdt.c
+++ b/arch/arm/mach-omap2/omap5/fdt.c
@@ -233,6 +233,141 @@ static void ft_hs_fixups(void *fdt, bd_t *bd)
 }
 #endif /* #ifdef CONFIG_TI_SECURE_DEVICE */
 
+#if defined(CONFIG_TARGET_DRA7XX_EVM) || defined(CONFIG_TARGET_AM57XX_EVM)
+#define OPP_DSP_CLK_NUM3
+#define OPP_IVA_CLK_NUM2
+#define OPP_GPU_CLK_NUM2
+
+const char *dra7_opp_dsp_clk_names[OPP_DSP_CLK_NUM] = {
+   "dpll_dsp_ck",
+   "dpll_dsp_m2_ck",
+   "dpll_dsp_m3x2_ck",
+};
+
+const char *dra7_opp_iva_clk_names[OPP_IVA_CLK_NUM] = {
+   "dpll_iva_ck",
+   "dpll_iva_m2_ck",
+};
+
+const char *dra7_opp_gpu_clk_names[OPP_GPU_CLK_NUM] = {
+   "dpll_gpu_ck",
+   "dpll_gpu_m2_ck",
+};
+
+/* DSPEVE voltage domain */
+u32 dra7_opp_dsp_clk_rates[NUM_OPPS][OPP_DSP_CLK_NUM] = {
+   {}, /*OPP_LOW */
+   {6, 6, 4}, /* OPP_NOM */
+   {7, 7, 46667}, /* OPP_OD */
+   {75000, 75000, 5}, /* OPP_HIGH */
+};
+
+/* IVA voltage domain */
+u32 dra7_opp_iva_clk_rates[NUM_OPPS][OPP_IVA_CLK_NUM] = {
+   {}, /* OPP_LOW */
+   {116500, 38834}, /* OPP_NOM */
+   {86000, 43000}, /* OPP_OD */
+   {106400, 53200}, /* OPP_HIGH */
+};
+
+/* GPU voltage domain */
+u32 dra7_opp_gpu_clk_rates[NUM_OPPS][OPP_GPU_CLK_NUM] = {
+   {}, /* OPP_LOW */
+   {127700, 42567}, /* OPP_NOM */
+   {10, 5}, /* OPP_OD */
+   {106400, 53200}, /* OPP_HIGH */
+};
+
+static int ft_fixup_clocks(void *fdt, const char **names, u32 *rates, int num)
+{
+   int offs, node_offs, ret, i;
+   uint32_t phandle;
+
+   offs = fdt_path_offset(fdt, "/ocp/l4@4a00/cm_core_aon@5000/clocks");
+   if (offs < 0) {
+   debug("Could not find cm_core_aon clocks node path offset : 
%s\n",
+ fdt_strerror(offs));
+   return offs;
+   }
+
+   for (i = 0; i < num; i++) {
+   node_offs = fdt_subnode_offset(fdt, offs, names[i]);
+   if (node_offs < 0) {
+   debug("Could not find clock sub-node %s: %s\n",
+ names[i], fdt_strerror(node_offs));
+   return offs;
+   }
+
+   phandle = fdt_get_phandle(fdt, node_offs);
+   if (!phandle) {
+   debug("Could not find phandle for clock %s\n",
+ names[i]);
+   return -1;
+   }
+
+   ret = fdt_setprop_u32(fdt, node_offs, "assigned-clocks",
+ phandle);
+   if (ret < 0) {
+   debug("Could not add assigned-clocks property to clock 
node %s: %s\n",
+ names[i], fdt_strerror(ret));
+   return ret;
+   }
+
+   ret = fdt_setprop_u32(fdt, node_offs, "assigned-clock-rates",
+ rates[i]);
+   if (ret < 0) {
+   debug("Could not add assigned-clock-rates property to 
clock node %s: %s\n",
+ names[i], fdt_strerror(ret));
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
+static void ft_opp_clock_fixups(void *fdt, bd_t *bd)
+{
+   const char **clk_names;
+   u32 *clk_rates;
+   int ret;
+
+   if (!is_dra72x() && !is_dra7xx())
+   return;
+
+   /* fixup DSP clocks */
+   

[U-Boot] [PATCH 1/3] ARM: OMAP4+: Add support for dynamically selecting OPPs

[Lokesh Vutla]

It can be expected that different paper spins of a SoC can have
different definitions for OPP and can have their own constraints
on the boot up OPP for each voltage rail. In order to have this
flexibility, add support for dynamically selecting the OPP voltage
based on the board to handle any such exceptions.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/include/asm/omap_common.h  |  23 ++-
 arch/arm/mach-omap2/clocks-common.c | 116 ++--
 arch/arm/mach-omap2/omap4/hw_data.c |  24 
 arch/arm/mach-omap2/omap5/hw_data.c |  12 ++--
 board/ti/am57xx/board.c |  92 +---
 board/ti/dra7xx/evm.c   |  91 +---
 6 files changed, 254 insertions(+), 104 deletions(-)

diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 605c549..00bd9fc 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -539,18 +539,26 @@ struct pmic_data {
int (*pmic_write)(u8 sa, u8 reg_addr, u8 reg_data);
 };
 
+enum {
+   OPP_LOW,
+   OPP_NOM,
+   OPP_OD,
+   OPP_HIGH,
+   NUM_OPPS,
+};
+
 /**
  * struct volts_efuse_data - efuse definition for voltage
  * @reg:   register address for efuse
  * @reg_bits:  Number of bits in a register address, mandatory.
  */
 struct volts_efuse_data {
-   u32 reg;
+   u32 reg[NUM_OPPS];
u8 reg_bits;
 };
 
 struct volts {
-   u32 value;
+   u32 value[NUM_OPPS];
u32 addr;
struct volts_efuse_data efuse;
struct pmic_data *pmic;
@@ -558,6 +566,16 @@ struct volts {
u32 abb_tx_done_mask;
 };
 
+enum {
+   VOLT_MPU,
+   VOLT_CORE,
+   VOLT_MM,
+   VOLT_GPU,
+   VOLT_EVE,
+   VOLT_IVA,
+   NUM_VOLT_RAILS,
+};
+
 struct vcores_data {
struct volts mpu;
struct volts core;
@@ -612,6 +630,7 @@ void enable_usb_clocks(int index);
 void disable_usb_clocks(int index);
 
 void scale_vcores(struct vcores_data const *);
+int get_voltrail_opp(int rail_offset);
 u32 get_offset_code(u32 volt_offset, struct pmic_data *pmic);
 void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct pmic_data *pmic);
 void abb_setup(u32 fuse, u32 ldovbb, u32 setup, u32 control,
diff --git a/arch/arm/mach-omap2/clocks-common.c 
b/arch/arm/mach-omap2/clocks-common.c
index 9b97583..84f93e7 100644
--- a/arch/arm/mach-omap2/clocks-common.c
+++ b/arch/arm/mach-omap2/clocks-common.c
@@ -477,35 +477,45 @@ void do_scale_vcore(u32 vcore_reg, u32 volt_mv, struct 
pmic_data *pmic)
gpio_direction_output(pmic->gpio, 1);
 }
 
-static u32 optimize_vcore_voltage(struct volts const *v)
+int __weak get_voltrail_opp(int rail_offset)
+{
+   /*
+* By default return OPP_NOM for all voltage rails.
+*/
+   return OPP_NOM;
+}
+
+static u32 optimize_vcore_voltage(struct volts const *v, int opp)
 {
u32 val;
-   if (!v->value)
+
+   if (!v->value[opp])
return 0;
-   if (!v->efuse.reg)
-   return v->value;
+   if (!v->efuse.reg[opp])
+   return v->value[opp];
 
switch (v->efuse.reg_bits) {
case 16:
-   val = readw(v->efuse.reg);
+   val = readw(v->efuse.reg[opp]);
break;
case 32:
-   val = readl(v->efuse.reg);
+   val = readl(v->efuse.reg[opp]);
break;
default:
printf("Error: efuse 0x%08x bits=%d unknown\n",
-  v->efuse.reg, v->efuse.reg_bits);
-   return v->value;
+  v->efuse.reg[opp], v->efuse.reg_bits);
+   return v->value[opp];
}
 
if (!val) {
printf("Error: efuse 0x%08x bits=%d val=0, using %d\n",
-  v->efuse.reg, v->efuse.reg_bits, v->value);
-   return v->value;
+  v->efuse.reg[opp], v->efuse.reg_bits, v->value[opp]);
+   return v->value[opp];
}
 
debug("%s:efuse 0x%08x bits=%d Vnom=%d, using efuse value %d\n",
- __func__, v->efuse.reg, v->efuse.reg_bits, v->value, val);
+ __func__, v->efuse.reg[opp], v->efuse.reg_bits, v->value[opp],
+ val);
return val;
 }
 
@@ -529,16 +539,19 @@ void __weak recalibrate_iodelay(void)
  */
 void scale_vcores(struct vcores_data const *vcores)
 {
-   int i;
+   int i, opp, j, ol;
struct volts *pv = (struct volts *)vcores;
struct volts *px;
 
for (i=0; i<(sizeof(struct vcores_data)/sizeof(struct volts)); i++) {
-   debug("%d -> ", pv->value);
-   if (pv->value) {
+   opp = get_voltrail_opp(i);
+   debug("%d -> ", pv->value[opp]);
+
+   if (pv->value[opp]) {
/* Handle non-empty members only */
-   pv->value = optimize_vcore_voltage(pv);
+  

Re: [U-Boot] [PATCH v8 1/3] armv8: Support loading 32-bit OS in AArch32 execution state

[Alexander Graf]

On 11/21/2016 10:48 PM, york sun wrote:

Alex,

Since you are most familiar with EFI boot code, can you send a patch to
address this? I can squash it with Alison's patch after testing. My
current test branch is
http://git.denx.de/?p=u-boot/u-boot-fsl-qoriq.git;a=shortlog;h=refs/heads/test_qoriq.


Ok, you should have a patch now :). I was still able to boot SLES with it.


Alex

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

[U-Boot] [PATCH] ls2080: efi_loader: Move EL2 switch to function call based version

[Alexander Graf]

We moved the EL2 switch to be function call based rather than implicit.
This patch changes the EL3 -> EL2 switch to the new way of doing things.

I've tested and verified this patch on LS2085ARDB.

Signed-off-by: Alexander Graf 

---

York, feel free to squash this in with the EL2 switch.
---
 cmd/bootefi.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index ca41170..97a0fc9 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -141,6 +141,18 @@ static void *copy_fdt(void *fdt)
return new_fdt;
 }
 
+#ifdef CONFIG_ARM64
+static unsigned long efi_run_in_el2(ulong (*entry)(void *image_handle,
+   struct efi_system_table *st), void *image_handle,
+   struct efi_system_table *st)
+{
+   /* Enable caches again */
+   dcache_enable();
+
+   return entry(image_handle, st);
+}
+#endif
+
 /*
  * Load an EFI payload into a newly allocated piece of memory, register all
  * EFI objects it would want to access and jump to it.
@@ -231,9 +243,14 @@ static unsigned long do_bootefi_exec(void *efi, void *fdt)
if (current_el() == 3) {
smp_kick_all_cpus();
dcache_disable();   /* flush cache before switch to EL2 */
-   armv8_switch_to_el2();
-   /* Enable caches again */
-   dcache_enable();
+
+   /* Move into EL2 and keep running there */
+   armv8_switch_to_el2((ulong)entry, (ulong)_image_info,
+   (ulong), (ulong)efi_run_in_el2,
+   ES_TO_AARCH64);
+
+   /* Should never reach here, efi exits with longjmp */
+   while (1) { }
}
 #endif
 
-- 
1.8.5.6

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

Re: [U-Boot] Pull request: u-boot-spi/master

[Tom Rini]

On Sun, Nov 20, 2016 at 05:29:41PM +0530, Jagan Teki wrote:
> Hi Tom,
> 
> On Sat, Nov 19, 2016 at 6:27 AM, Tom Rini  wrote:
> > On Fri, Nov 18, 2016 at 04:46:03PM +0530, Jagan Teki wrote:
> >
> >> Hi Tom,
> >>
> >> Please pull this PR.
> >>
> >> thanks!
> >> Jagan.
> >>
> >> The following changes since commit 
> >> c2cbd164ea5b5f564fcf03447c7bf9ec4a9f5699:
> >>
> >>   Merge branch 'master' of http://git.denx.de/u-boot-mmc (2016-11-17 
> >> 11:46:56 -0500)
> >>
> >> are available in the git repository at:
> >>
> >>
> >>   git://git.denx.de/u-boot-spi.git master
> >>
> >> for you to fetch changes up to 84cdc6e27aede7d87322842d262f0414824bb126:
> >>
> >>   sf: Fix s25fs512s id table (2016-11-18 13:04:55 +0530)
> >>
> >
> > NAK, this has a build failure that travis-ci catches:
> > https://travis-ci.org/trini/u-boot/jobs/177155166
> 
> Fixed the same, please consider the same PR again.

Applied, but in the future please send a new PR out, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,v2] MAINTAINERS: SUNXI: Update maintainership

[Tom Rini]

On Tue, Nov 22, 2016 at 05:14:06PM +0530, Jagan Teki wrote:

> Add Jagan and Maxime as Maintainers for SUNXI
> 
> Signed-off-by: Jagan Teki 
> Acked-by: Maxime Ripard 

Applied to u-boot/master, thanks!

-- 
Tom


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

[U-Boot] [PATCH v2 4/4] davinci: omapl138_lcdk: add u-boot sector for mmc/sd boot

[Fabien Parent]

Set the correct CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR value in order
to be able to boot from MMC/SD.

The SPL is stored at sector 0x75, while u-boot will follow at
sector 0xb5.

Signed-off-by: Fabien Parent 
---

v1 -> v2

* Rebased on Sam's patches, i.e. use new Kconfig option instead of setting
the value inside the config header file

---
 configs/omapl138_lcdk_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/omapl138_lcdk_defconfig b/configs/omapl138_lcdk_defconfig
index bcd1acb..4a5f435 100644
--- a/configs/omapl138_lcdk_defconfig
+++ b/configs/omapl138_lcdk_defconfig
@@ -9,6 +9,7 @@ CONFIG_VERSION_VARIABLE=y
 # CONFIG_DISPLAY_CPUINFO is not set
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0xb5
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="U-Boot > "
 # CONFIG_CMD_IMLS is not set
-- 
2.10.2

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

[U-Boot] [PATCH v2 3/4] davinci: da850evm: fix empty boot method list in the SPL

[Fabien Parent]

The list of available boot method is not part of the binary which
prevent the SPL from booting u-boot or Linux.

Add the missing .u_boot_list* sections to the binary to fix it.

Signed-off-by: Fabien Parent 
Reviewed-by: Tom Rini 
---

v1 -> v2:

* No change

---
 board/davinci/da8xxevm/u-boot-spl-da850evm.lds | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/board/davinci/da8xxevm/u-boot-spl-da850evm.lds 
b/board/davinci/da8xxevm/u-boot-spl-da850evm.lds
index ab4f50c..85a6be9 100644
--- a/board/davinci/da8xxevm/u-boot-spl-da850evm.lds
+++ b/board/davinci/da8xxevm/u-boot-spl-da850evm.lds
@@ -34,6 +34,9 @@ SECTIONS
.data : { *(SORT_BY_ALIGNMENT(.data*)) } >.sram
 
. = ALIGN(4);
+   .u_boot_list : { KEEP(*(SORT(.u_boot_list*))); } >.sram
+
+   . = ALIGN(4);
.rel.dyn : {
__rel_dyn_start = .;
*(.rel*)
-- 
2.10.2

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

[U-Boot] [PATCH v2 1/4] davinci: omapl138_lcdk: configure pll0

[Fabien Parent]

The SPL is not able to boot properly because the PLL0 is not
configured. Configure it.

Signed-off-by: Fabien Parent 
---

V1 -> V2
 * New patch

---
 include/configs/omapl138_lcdk.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h
index 854fc47..ce3a8f4 100644
--- a/include/configs/omapl138_lcdk.h
+++ b/include/configs/omapl138_lcdk.h
@@ -30,6 +30,7 @@
 #define CONFIG_SYS_TIMERBASE   DAVINCI_TIMER0_BASE
 #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID)
 #define CONFIG_SYS_HZ  1000
+#define CONFIG_SYS_DA850_PLL_INIT
 #define CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_SYS_TEXT_BASE   0xc108
 
-- 
2.10.2

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

[U-Boot] [PATCH v2 0/4] davinci: omapl138_lcdk: fix a few bugs for SPL boot

[Fabien Parent]

This patchset tries to fix the SPL on omapl138_lcdk. With this patchset, the SPL
will be able to boot from EMMC/SPI.

The NAND support is still broken so the default u-boot.ais image still has a SPL
that is unable to load u-boot. 

Change v1 .. v2:
* Don't add an AIS config file but instead configure the PLL and DDR in
the SPL. This follow what other boards are doing.
* Use new kconfig option to support EMMC boot.

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

[U-Boot] [PATCH v2 2/4] davinci: omapl138_lcdk: configure ddr2

[Fabien Parent]

The SPL is unable to load u-boot because the DDR2 is not configured.
Configure the DDR2.

Signed-off-by: Fabien Parent 
---

V1 -> V2

* New patch

---
 include/configs/omapl138_lcdk.h | 42 +
 1 file changed, 42 insertions(+)

diff --git a/include/configs/omapl138_lcdk.h b/include/configs/omapl138_lcdk.h
index ce3a8f4..2cdf892 100644
--- a/include/configs/omapl138_lcdk.h
+++ b/include/configs/omapl138_lcdk.h
@@ -31,6 +31,7 @@
 #define CONFIG_SYS_HZ_CLOCKclk_get(DAVINCI_AUXCLK_CLKID)
 #define CONFIG_SYS_HZ  1000
 #define CONFIG_SYS_DA850_PLL_INIT
+#define CONFIG_SYS_DA850_DDR_INIT
 #define CONFIG_SKIP_LOWLEVEL_INIT
 #define CONFIG_SYS_TEXT_BASE   0xc108
 
@@ -80,6 +81,47 @@
 #define CONFIG_SYS_DA850_PLL1_PLLM 21
 
 /*
+ * DDR2 memory configuration
+ */
+#define CONFIG_SYS_DA850_DDR2_DDRPHYCR (DV_DDR_PHY_PWRDNEN | \
+   DV_DDR_PHY_EXT_STRBEN | \
+   (0x5 << DV_DDR_PHY_RD_LATENCY_SHIFT))
+
+#define CONFIG_SYS_DA850_DDR2_SDBCR (\
+   (1 << DV_DDR_SDCR_DDR2EN_SHIFT) | \
+   (1 << DV_DDR_SDCR_DDREN_SHIFT)  | \
+   (1 << DV_DDR_SDCR_SDRAMEN_SHIFT)| \
+   (1 << DV_DDR_SDCR_BUS_WIDTH_SHIFT)  | \
+   (4 << DV_DDR_SDCR_CL_SHIFT) | \
+   (3 << DV_DDR_SDCR_IBANK_SHIFT)  | \
+   (2 << DV_DDR_SDCR_PAGESIZE_SHIFT))
+
+/* SDBCR2 is only used if IBANK_POS bit in SDBCR is set */
+#define CONFIG_SYS_DA850_DDR2_SDBCR2 0
+
+#define CONFIG_SYS_DA850_DDR2_SDTIMR (   \
+   (19 << DV_DDR_SDTMR1_RFC_SHIFT) | \
+   (1 << DV_DDR_SDTMR1_RP_SHIFT)   | \
+   (1 << DV_DDR_SDTMR1_RCD_SHIFT)  | \
+   (2 << DV_DDR_SDTMR1_WR_SHIFT)   | \
+   (6 << DV_DDR_SDTMR1_RAS_SHIFT)  | \
+   (8 << DV_DDR_SDTMR1_RC_SHIFT)   | \
+   (1 << DV_DDR_SDTMR1_RRD_SHIFT)  | \
+   (1 << DV_DDR_SDTMR1_WTR_SHIFT))
+
+#define CONFIG_SYS_DA850_DDR2_SDTIMR2 (  \
+   (7 << DV_DDR_SDTMR2_RASMAX_SHIFT)   | \
+   (2 << DV_DDR_SDTMR2_XP_SHIFT)   | \
+   (0 << DV_DDR_SDTMR2_ODT_SHIFT)  | \
+   (10 << DV_DDR_SDTMR2_XSNR_SHIFT)| \
+   (199 << DV_DDR_SDTMR2_XSRD_SHIFT)   | \
+   (1 << DV_DDR_SDTMR2_RTP_SHIFT)  | \
+   (2 << DV_DDR_SDTMR2_CKE_SHIFT))
+
+#define CONFIG_SYS_DA850_DDR2_SDRCR0x0492
+#define CONFIG_SYS_DA850_DDR2_PBBPR0x30
+
+/*
  * Serial Driver info
  */
 #define CONFIG_SYS_NS16550_SERIAL
-- 
2.10.2

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

Re: [U-Boot] [PATCH] arm: exynos: Use the generic lowlevel_init instead of the specific one

[york sun]

On 11/21/2016 09:25 PM, Alison Wang wrote:
>
>
> 2016년 11월 16일 (수) 19:44, Alison Wang  >님이작성:
>
> Hi, Thomas,
>
> I didn't see your patch. Maybe it isn't CC'ing me. Could you send me
> and york the link?
>
> Minkyu Kang,
>
> Could you add review-by and assign this patch
> http://patchwork.ozlabs.org/patch/667948/ to York? So he can merge
> this patch and Thomas's patch together.
>
>
>
> It's OK.
>
> York means yorksun?
>
> *[Alison Wang] Yes.*
>
>
>
> Reviewed-by: Minkyu Kang  >
>
>

I think we have a newer version http://patchwork.ozlabs.org/patch/695560/

York

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

Re: [U-Boot] [PATCH v8 1/3] armv8: Support loading 32-bit OS in AArch32 execution state

[Alexander Graf]

On 11/22/2016 06:07 PM, york sun wrote:

On 11/22/2016 09:02 AM, Alexander Graf wrote:

On 11/21/2016 10:48 PM, york sun wrote:

On 11/21/2016 01:07 PM, Alexander Graf wrote:

On 21/11/2016 21:45, york sun wrote:

On 11/21/2016 12:40 PM, Alexander Graf wrote:

On 21/11/2016 21:23, york sun wrote:

On 11/09/2016 07:02 PM, Alison Wang wrote:

To support loading a 32-bit OS, the execution state will change from
AArch64 to AArch32 when jumping to kernel.

The architecture information will be got through checking FIT image,
then U-Boot will load 32-bit OS or 64-bit OS automatically.

Signed-off-by: Ebony Zhu 
Signed-off-by: Alison Wang 
Signed-off-by: Chenhui Zhao 
---
Changes in v8:
- Fix the issue when U-Boot is running in EL2 or EL1.


Alison,

There is a conflict when merging with upstream code. Alex Graf merged
his change to support EFI booting. See commit
69bd459d343fe1e5a68a6f187d8c99c78c6fc6ce. Specifically these lines


   if (current_el() == 3) {
   smp_kick_all_cpus();
   dcache_disable();
   armv8_switch_to_el2();
   dcache_enable();
   }

Function armv8_switch_to_el2() didn't take any argument before you
change. With your proposed change to support 32-bit OS, you added
arguments to this function, and presume this function always load OS.
This may be flawed. Would it be possible to keep armv8_switch_to_el2()
but introduce another function to carry out switching EL while loading OS?

Alison introduced it based on my comments - and I'd prefer if we only
have the function call based version :).

It should be reasonably straight forward to move to it here. Just create
a new helper stub that enables the dcache and calls entry().


Alex,

Do you always load OS when calling armv8_switch_to_el2()? In this case
of efi booting, kernel entry point needs to be passed to the new
armv8_switch_to_el2 function. The new armv8_switch_to_el2 function
doesn't return, so you cannot continue to run the code.

We always call some random function pointer in the new flow. That can be
a kernel entry point, but it can also just be a function pointer. In
this case, the code would basically look like this:

static ulong efi_run_in_el2(ulong (*entry), void *arg1, void *arg2)
{
   dcache_enable();
   return entry(arg1, arg2);
}

if (current_el() == 3) {
   ...
   return armv8_switch_to_el2(efi_run_in_el2, entry,
_image_info, );
}


Alex,

Since you are most familiar with EFI boot code, can you send a patch to
address this? I can squash it with Alison's patch after testing. My
current test branch is
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.denx.de%2F%3Fp%3Du-boot%2Fu-boot-fsl-qoriq.git%3Ba%3Dshortlog%3Bh%3Drefs%2Fheads%2Ftest_qoriq=01%7C01%7Cyork.sun%40nxp.com%7C0b9b6fdb53c94e1a953d08d412f9502f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=ALW8GdHxkPJghve%2BxbKQ1E9ssjFxSOf35PvVuY34ZiA%3D=0.

While trying to fix this up, I ran across another compile breakage:

arch/arm/cpu/armv8/fsl-layerscape/mp.c:114: undefined reference to
`initiator_type'
arch/arm/cpu/armv8/fsl-layerscape/mp.c:123: undefined reference to
`initiator_type'


Possibly cause by a new set of patches sent by Priyanka for LS2088A.
Let's use upstream master branch plus Alison's three patches.


No worries, the patch below fixes it. Just wanted to let you know.

Alex


diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c

index 59b0870..d6ee546 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -191,7 +191,7 @@ void enable_caches(void)
 }
 #endif

-inline u32 initiator_type(u32 cluster, int init_id)
+u32 initiator_type(u32 cluster, int init_id)
 {
struct ccsr_gur *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
u32 idx = (cluster >> (init_id * 8)) & TP_CLUSTER_INIT_MASK;

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

Re: [U-Boot] [PATCH v8 1/3] armv8: Support loading 32-bit OS in AArch32 execution state

[york sun]

On 11/22/2016 09:02 AM, Alexander Graf wrote:
> On 11/21/2016 10:48 PM, york sun wrote:
>> On 11/21/2016 01:07 PM, Alexander Graf wrote:
>>>
>>> On 21/11/2016 21:45, york sun wrote:
 On 11/21/2016 12:40 PM, Alexander Graf wrote:
>
> On 21/11/2016 21:23, york sun wrote:
>> On 11/09/2016 07:02 PM, Alison Wang wrote:
>>> To support loading a 32-bit OS, the execution state will change from
>>> AArch64 to AArch32 when jumping to kernel.
>>>
>>> The architecture information will be got through checking FIT image,
>>> then U-Boot will load 32-bit OS or 64-bit OS automatically.
>>>
>>> Signed-off-by: Ebony Zhu 
>>> Signed-off-by: Alison Wang 
>>> Signed-off-by: Chenhui Zhao 
>>> ---
>>> Changes in v8:
>>> - Fix the issue when U-Boot is running in EL2 or EL1.
>>>
>> Alison,
>>
>> There is a conflict when merging with upstream code. Alex Graf merged
>> his change to support EFI booting. See commit
>> 69bd459d343fe1e5a68a6f187d8c99c78c6fc6ce. Specifically these lines
>>
>>
>>   if (current_el() == 3) {
>>   smp_kick_all_cpus();
>>   dcache_disable();
>>   armv8_switch_to_el2();
>>   dcache_enable();
>>   }
>>
>> Function armv8_switch_to_el2() didn't take any argument before you
>> change. With your proposed change to support 32-bit OS, you added
>> arguments to this function, and presume this function always load OS.
>> This may be flawed. Would it be possible to keep armv8_switch_to_el2()
>> but introduce another function to carry out switching EL while loading 
>> OS?
> Alison introduced it based on my comments - and I'd prefer if we only
> have the function call based version :).
>
> It should be reasonably straight forward to move to it here. Just create
> a new helper stub that enables the dcache and calls entry().
>
 Alex,

 Do you always load OS when calling armv8_switch_to_el2()? In this case
 of efi booting, kernel entry point needs to be passed to the new
 armv8_switch_to_el2 function. The new armv8_switch_to_el2 function
 doesn't return, so you cannot continue to run the code.
>>> We always call some random function pointer in the new flow. That can be
>>> a kernel entry point, but it can also just be a function pointer. In
>>> this case, the code would basically look like this:
>>>
>>> static ulong efi_run_in_el2(ulong (*entry), void *arg1, void *arg2)
>>> {
>>>   dcache_enable();
>>>   return entry(arg1, arg2);
>>> }
>>>
>>> if (current_el() == 3) {
>>>   ...
>>>   return armv8_switch_to_el2(efi_run_in_el2, entry,
>>> _image_info, );
>>> }
>>>
>> Alex,
>>
>> Since you are most familiar with EFI boot code, can you send a patch to
>> address this? I can squash it with Alison's patch after testing. My
>> current test branch is
>> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.denx.de%2F%3Fp%3Du-boot%2Fu-boot-fsl-qoriq.git%3Ba%3Dshortlog%3Bh%3Drefs%2Fheads%2Ftest_qoriq=01%7C01%7Cyork.sun%40nxp.com%7C0b9b6fdb53c94e1a953d08d412f9502f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0=ALW8GdHxkPJghve%2BxbKQ1E9ssjFxSOf35PvVuY34ZiA%3D=0.
>
> While trying to fix this up, I ran across another compile breakage:
>
> arch/arm/cpu/armv8/fsl-layerscape/mp.c:114: undefined reference to
> `initiator_type'
> arch/arm/cpu/armv8/fsl-layerscape/mp.c:123: undefined reference to
> `initiator_type'
>

Possibly cause by a new set of patches sent by Priyanka for LS2088A. 
Let's use upstream master branch plus Alison's three patches.

York

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

Re: [U-Boot] [PATCH v8 1/3] armv8: Support loading 32-bit OS in AArch32 execution state

[Alexander Graf]

On 11/21/2016 10:48 PM, york sun wrote:

On 11/21/2016 01:07 PM, Alexander Graf wrote:


On 21/11/2016 21:45, york sun wrote:

On 11/21/2016 12:40 PM, Alexander Graf wrote:


On 21/11/2016 21:23, york sun wrote:

On 11/09/2016 07:02 PM, Alison Wang wrote:

To support loading a 32-bit OS, the execution state will change from
AArch64 to AArch32 when jumping to kernel.

The architecture information will be got through checking FIT image,
then U-Boot will load 32-bit OS or 64-bit OS automatically.

Signed-off-by: Ebony Zhu 
Signed-off-by: Alison Wang 
Signed-off-by: Chenhui Zhao 
---
Changes in v8:
- Fix the issue when U-Boot is running in EL2 or EL1.


Alison,

There is a conflict when merging with upstream code. Alex Graf merged
his change to support EFI booting. See commit
69bd459d343fe1e5a68a6f187d8c99c78c6fc6ce. Specifically these lines


  if (current_el() == 3) {
  smp_kick_all_cpus();
  dcache_disable();
  armv8_switch_to_el2();
  dcache_enable();
  }

Function armv8_switch_to_el2() didn't take any argument before you
change. With your proposed change to support 32-bit OS, you added
arguments to this function, and presume this function always load OS.
This may be flawed. Would it be possible to keep armv8_switch_to_el2()
but introduce another function to carry out switching EL while loading OS?

Alison introduced it based on my comments - and I'd prefer if we only
have the function call based version :).

It should be reasonably straight forward to move to it here. Just create
a new helper stub that enables the dcache and calls entry().


Alex,

Do you always load OS when calling armv8_switch_to_el2()? In this case
of efi booting, kernel entry point needs to be passed to the new
armv8_switch_to_el2 function. The new armv8_switch_to_el2 function
doesn't return, so you cannot continue to run the code.

We always call some random function pointer in the new flow. That can be
a kernel entry point, but it can also just be a function pointer. In
this case, the code would basically look like this:

static ulong efi_run_in_el2(ulong (*entry), void *arg1, void *arg2)
{
  dcache_enable();
  return entry(arg1, arg2);
}

if (current_el() == 3) {
  ...
  return armv8_switch_to_el2(efi_run_in_el2, entry,
_image_info, );
}


Alex,

Since you are most familiar with EFI boot code, can you send a patch to
address this? I can squash it with Alison's patch after testing. My
current test branch is
http://git.denx.de/?p=u-boot/u-boot-fsl-qoriq.git;a=shortlog;h=refs/heads/test_qoriq.


While trying to fix this up, I ran across another compile breakage:

arch/arm/cpu/armv8/fsl-layerscape/mp.c:114: undefined reference to 
`initiator_type'
arch/arm/cpu/armv8/fsl-layerscape/mp.c:123: undefined reference to 
`initiator_type'



Alex

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

Re: [U-Boot] [PATCH v2 9/14] sunxi: Enable UBI and NAND support

[Tom Rini]

On Tue, Nov 22, 2016 at 04:54:53PM +0100, Maxime Ripard wrote:
> Hi Tom,
> 
> On Tue, Nov 22, 2016 at 10:24:27AM -0500, Tom Rini wrote:
> > On Tue, Nov 22, 2016 at 01:38:39PM +0100, Maxime Ripard wrote:
> > > From: Hans de Goede 
> > > 
> > > Enable the NAND and UBI support in the configuration header so that we can
> > > (finally) use it.
> > > 
> > > Signed-off-by: Hans de Goede 
> > > Signed-off-by: Maxime Ripard 
> > > ---
> > >  board/sunxi/Kconfig|  8 
> > >  include/configs/sunxi-common.h | 14 ++
> > >  2 files changed, 22 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> > > index e1d4ab148f08..c6a620a20167 100644
> > > --- a/board/sunxi/Kconfig
> > > +++ b/board/sunxi/Kconfig
> > > @@ -460,6 +460,14 @@ config AXP_GPIO
> > >   ---help---
> > >   Say Y here to enable support for the gpio pins of the axp PMIC ICs.
> > >  
> > > +if NAND_SUNXI
> > > +config CMD_NAND
> > > + default y
> > > +
> > > +config CMD_UBI
> > > + default y
> > > +endif
> > 
> > We want to move away from adding 'default y' to board/*/Kconfig and
> > instead have 'default y if ...' where the option is declared.
> 
> Yeah, I wasn't really sure about this. You can find the two
> constructs in there. But ok, that's noted :)
> 
> > In this particular case we have a TODO of adding a NAND option that
> > would be used to hide things like CMD_NAND and other sub-sections
> > rather than using CMD_NAND for everything.
> 
> Ok.
> 
> > That said, we've just got 2 sunxi boards with NAND today right?  Maybe
> > we shouldn't make this default for all sunxi boards yet, yes?  Thanks!
> 
> Not really. The huge majority of the rather old boards (basically
> everything older than a year or so) is using NAND. However, they're
> all using MLC NANDs, which are not supported into UBI right now.

Ah, good to know, OK.  So v2, default y if ARCH_SUNXI on cmd/Kconfig :)


-- 
Tom


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

Re: [U-Boot] [PATCH 3/3] davinci: omapl138_lcdk: add MMC/SD SPL boot support

[Sam Protsenko]

On Fri, Nov 18, 2016 at 12:23 AM, Tom Rini  wrote:
> On Wed, Nov 16, 2016 at 05:33:35PM +0100, Fabien Parent wrote:
>> Define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR in order to be able
>> to boot from MMC/SD.
>>
>> The SPL is stored at sector 0x75, while u-boot will follow at
>> sector 0xb5.
>>
>> Signed-off-by: Fabien Parent 
>> ---
>>  include/configs/omapl138_lcdk.h | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/include/configs/omapl138_lcdk.h 
>> b/include/configs/omapl138_lcdk.h
>> index 91ddbb1..0964176 100644
>> --- a/include/configs/omapl138_lcdk.h
>> +++ b/include/configs/omapl138_lcdk.h
>> @@ -272,6 +272,14 @@
>>  #define CONFIG_SPL_PAD_TO32768
>>  #endif
>>
>> +/* Load U-Boot Image From MMC */
>> +#ifdef CONFIG_SPL_MMC_LOAD
>> +#define SPL_SECTOR   0x75
>> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR  (SPL_SECTOR + \
>> + CONFIG_SPL_PAD_TO / 
>> 512)
>> +#undef CONFIG_SPL_SPI_LOAD
>> +#endif
>> +
>>  /* AIS Image */
>>  #define CONFIG_AIS_CONFIG_FILE   
>> "board/davinci/da8xxevm/omapl138_lcdk_ais.cfg"
>
> We need to do this on top of Sam's series, and we need to do this in
> Kconfig and not adding more stuff to the config header.
>

Just FYI: mentioned patch is [1]. For the Kconfig option itself see diif at [2].

[1] 
http://git.denx.de/?p=u-boot.git;a=commit;h=38fed8abe7d2e7ba90deb352d0e7aed4364c5236
[2] 
http://git.denx.de/?p=u-boot.git;a=blobdiff;f=common/spl/Kconfig;h=df9e0ce68f9ea2348af8aec3ebe5aea25456062e;hp=bb99f1fcff4b4ba3ae909be3d3134323741f6c84;hb=38fed8abe7d2e7ba90deb352d0e7aed4364c5236;hpb=c2cbd164ea5b5f564fcf03447c7bf9ec4a9f5699

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

[U-Boot] [PATCH] arm: armv7: add us timer for bootstage

[Patrick Delaunay]

From: Patrick Delaunay 

solve issue when bootstage is used with armV7 generic timer
first call of timer_get_boot_us() use the function get_timer()
before timer initialization (arch.timer_rate_hz = 0)
=> div by 0

Commit-notes

When I activate bootstage on ARMV7 architecture with platform
using the generic armv7 timer defined in file
./arch/arm/cpu/armv7m/timer.c

I have a issue because gd->arch.timer_rate_hz = 0

For me the get_timer() function should not used before timer_init
(which initialize gd->arch.timer_rate_hz) at least for the ARMV7
timer.

But in the init sequence, the first bootstage fucntion is called
before timer_init and this function use the timer function.

For me it is a error in the generic init sequence :
mark_bootstage is called before timer_init.

static init_fnc_t init_sequence_f[] = {

arch_cpu_init_dm,
mark_bootstage,/* need timer, go after init dm */
...
#if defined(CONFIG_ARM) || defined(CONFIG_MIPS) || \
defined(CONFIG_BLACKFIN) || defined(CONFIG_NDS32) || \
defined(CONFIG_SPARC)
timer_init,/* initialize timer */
#endif
...

To solve the issue for all the paltform, we can move timer_init()
call just before mark_bootstage() in this array...

It should be ok for ARMV7 but I don't sure for other platform
impacted
- the other ARM platform or ARMV7 wich don't use generic timer
- MIPS BLACKFIN NDS32 or SPARC

and I don't sure of impact for other function called
(board_early_init_f for example)

=> This patch solve issue only in timer armv7
   get_boot_us() can be called everytime without div by 0 issue
   (gd->arch.timer_rate_hz is not used)

END

Signed-off-by: Patrick Delaunay 
Signed-off-by: Patrick Delaunay 
---

 arch/arm/cpu/armv7/arch_timer.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv7/arch_timer.c b/arch/arm/cpu/armv7/arch_timer.c
index 0588e2b..30915d2 100644
--- a/arch/arm/cpu/armv7/arch_timer.c
+++ b/arch/arm/cpu/armv7/arch_timer.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -17,7 +18,6 @@ int timer_init(void)
gd->arch.tbu = 0;
 
gd->arch.timer_rate_hz = CONFIG_SYS_HZ_CLOCK / CONFIG_SYS_HZ;
-
return 0;
 }
 
@@ -39,6 +39,11 @@ ulong get_timer(ulong base)
return lldiv(get_ticks(), gd->arch.timer_rate_hz) - base;
 }
 
+ulong timer_get_boot_us(void)
+{
+   return lldiv(get_ticks(), CONFIG_SYS_HZ_CLOCK / (CONFIG_SYS_HZ * 1000));
+}
+
 void __udelay(unsigned long usec)
 {
unsigned long long endtime;
-- 
1.9.1

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

Re: [U-Boot] [PATCH v2 12/14] scripts: sunxi: Build an raw SPL image

[Heiko Schocher]

Hello Maxime,

Am 22.11.2016 um 13:38 schrieb Maxime Ripard:

Introduce a new sunxi-spl-with-ecc.bin image with already the right header,
ECC, randomizer and padding for the BROM to be able to read it.

It needs to be flashed using a raw access to the NAND so that the
controller doesn't change a thing to it, since we already have all the
right parameters.

Signed-off-by: Maxime Ripard 
Acked-by: Boris Brezillon 
---
  Makefile|  3 ++-
  board/sunxi/README.nand | 54 ++-
  scripts/Makefile.spl| 15 -
  3 files changed, 72 insertions(+), 0 deletions(-)
  create mode 100644 board/sunxi/README.nand


Thanks for adding a README.

Reviewed-by: Heiko Schocher 

bye,
Heiko


diff --git a/Makefile b/Makefile
index 37cbcb28f75e..12a248e297b5 100644
--- a/Makefile
+++ b/Makefile
@@ -1345,6 +1345,9 @@ spl/u-boot-spl: tools prepare \
  spl/sunxi-spl.bin: spl/u-boot-spl
@:

+spl/sunxi-spl-with-ecc.bin: spl/sunxi-spl.bin
+   @:
+
  spl/u-boot-spl.sfp: spl/u-boot-spl
@:

diff --git a/board/sunxi/README.nand b/board/sunxi/README.nand
new file mode 100644
index ..a5d4ff0e90a3
--- /dev/null
+++ b/board/sunxi/README.nand
@@ -0,0 +1,54 @@
+Allwinner NAND flashing
+===
+
+A lot of Allwinner devices, especially the older ones (pre-H3 era),
+comes with a NAND. NANDs storages are a pretty weak choice when it
+comes to the reliability, and it comes with a number of flaws like
+read and write disturbs, data retention issues, bloks becoming
+unusable, etc.
+
+In order to mitigate that, various strategies have been found to be
+able to recover from those issues like ECC, hardware randomization,
+and of course, redundancy for the critical parts.
+
+This is obviously something that we will take into account when
+creating our images. However, the BROM will use a quite weird pattern
+when accessing the NAND, and will access only at most 4kB per page,
+which means that we also have to split that binary accross several
+pages.
+
+In order to accomodate that, we create a tool that will generate an
+SPL image that is ready to be programmed directly embedding the ECCs,
+randomized, and with the necessary bits needed to reduce the number of
+bitflips. The U-Boot build system, when configured for the NAND will
+also generate the image sunxi-spl-with-ecc.bin that will have been
+generated by that tool.
+
+In order to flash your U-Boot image onto a board, assuming that the
+board is in FEL mode, you'll need the sunxi-tools that you can find at
+this repository: https://github.com/linux-sunxi/sunxi-tools
+
+Then, you'll need to first load an SPL to initialise the RAM:
+sunxi-fel spl spl/sunxi-spl.bin
+
+Load the binaries we'll flash into RAM:
+sunxi-fel write 0x4a00 u-boot-dtb.bin
+sunxi-fel write 0x4300 spl/sunxi-spl-with-ecc.bin
+
+And execute U-Boot
+sunxi-fel exe 0x4a00
+
+On your board, you'll now have all the needed binaries into RAM, so
+you only need to erase the NAND...
+
+nand erase.chip
+
+Then write the SPL and its backup:
+
+nand write.raw.noverify 0x4300 0 40
+nand write.raw.noverify 0x4300 0x40 40
+
+And finally write the U-Boot binary:
+nand write 0x4a00 0x80 0xc
+
+You can now reboot and enjoy your NAND.
\ No newline at end of file
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index e0b0117dc9b6..6a381f26d21a 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -168,6 +168,10 @@ endif

  ifdef CONFIG_ARCH_SUNXI
  ALL-y += $(obj)/sunxi-spl.bin
+
+ifdef CONFIG_NAND_SUNXI
+ALL-y  += $(obj)/sunxi-spl-with-ecc.bin
+endif
  endif

  ifeq ($(CONFIG_SYS_SOC),"at91")
@@ -276,6 +280,17 @@ cmd_mksunxiboot = $(objtree)/tools/mksunxiboot $< $@
  $(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mksunxiboot)

+quiet_cmd_sunxi_spl_image_builder = SUNXI_SPL_IMAGE_BUILDER $@
+cmd_sunxi_spl_image_builder = $(objtree)/tools/sunxi-spl-image-builder \
+   -c 
$(CONFIG_NAND_SUNXI_SPL_ECC_STRENGTH)/$(CONFIG_NAND_SUNXI_SPL_ECC_SIZE) \
+   -p $(CONFIG_SYS_NAND_PAGE_SIZE) \
+   -o $(CONFIG_SYS_NAND_OOBSIZE) \
+   -u $(CONFIG_NAND_SUNXI_SPL_USABLE_PAGE_SIZE) \
+   -e $(CONFIG_SYS_NAND_BLOCK_SIZE) \
+   -s -b $< $@
+$(obj)/sunxi-spl-with-ecc.bin: $(obj)/sunxi-spl.bin
+   $(call if_changed,sunxi_spl_image_builder)
+
  # Rule to link u-boot-spl
  # May be overridden by arch/$(ARCH)/config.mk
  quiet_cmd_u-boot-spl ?= LD  $@



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

Re: [U-Boot] [PATCH] vexpress64: Juno: Change PCI buss addresses for IO to start from zero.

[Sudeep Holla]

On 22/11/16 15:08, Tom Rini wrote:

On Tue, Nov 22, 2016 at 12:08:49PM +, Liviu Dudau wrote:

On Tue, Nov 22, 2016 at 11:29:20AM +, Sudeep Holla wrote:

Hi Liviu,

On Tue, Nov 22, 2016 at 11:19 AM, Liviu Dudau  wrote:

Juno uses a 1:1 mapping between CPU and PCI addresses for IO. First,
that will trip devices that cannot use more than 16 bits of addresses
for IO, second it is un-necessary as the system can handle zero-based
PCI addresses just fine.

Change the mapping to start IO bus addresses from zero.



I assume this require corresponding DT change, shout if that's not true.
If that's true, then does this patch not require patching of DT so
that systems not
running Uboot with this patch continue to work and we retain the
mainline DT as is ?


Yes, it does require DT changes, Jeremy Linton has a patch


So to be clear, what level of coordination do we need between the two
parts being merged?  It would not be ideal to have combinations of
U-Boot and Linux not work.  Thanks!



What I had in mind is U-Boot modifying/fixing up the DT to adapt to this
change so that we maintain compatibility and don't break anything. But I
was not sure how feasible is that solution with other bootloaders like UEFI.

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

[U-Boot] [PATCH v4 0/2] drivers: timer: inroduce ARC timer driver

[Vlad Zakharov]

This patch series replaces legacy approach to access ARC timer
via specific code in "arch/arc/lib/time.c" and uses timer
driver instead.

ARC cores may have up to 2 built-in timers: timer0 and timer1,
usually at least one of them exists.

They are controlled through auxiliary registers and so we
don't have to remap their control registers as we used to do
with MMIO registers of external peripheral devices.

Cc: Simon Glass 
---
Changes v3..v4:
 - Remove CONFIG_SYS_TIMER_RATE not only from "axs10x.h" but also
from "nsim.h" and "tb100.h".

Vlad Zakharov (2):
  drivers: timer: Introduce ARC timer driver
  arc: use timer driver instead of arch/arc/lib/timer.c

 arch/arc/dts/skeleton.dtsi   |  6 ++
 arch/arc/include/asm/arcregs.h   |  4 ++
 arch/arc/lib/Makefile|  1 -
 arch/arc/lib/timer.c | 24 ---
 configs/axs101_defconfig |  2 +
 configs/axs103_defconfig |  2 +
 configs/nsim_700_defconfig   |  2 +
 configs/nsim_700be_defconfig |  2 +
 configs/nsim_hs38_defconfig  |  2 +
 configs/nsim_hs38be_defconfig|  2 +
 configs/tb100_defconfig  |  2 +
 doc/device-tree-bindings/timer/arc_timer.txt | 24 +++
 drivers/timer/Kconfig|  7 ++
 drivers/timer/Makefile   |  1 +
 drivers/timer/arc_timer.c| 95 
 include/configs/axs10x.h |  2 -
 16 files changed, 151 insertions(+), 27 deletions(-)
 delete mode 100644 arch/arc/lib/timer.c
 create mode 100644 doc/device-tree-bindings/timer/arc_timer.txt
 create mode 100644 drivers/timer/arc_timer.c

-- 
2.7.4

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

[U-Boot] [PATCH v4 2/2] arc: use timer driver instead of arch/arc/lib/timer.c

[Vlad Zakharov]

This commit replaces legacy timer code with usage of arc timer
driver.

Also it adds timer0 device tree node with corresponding
"clock-frequency" property.

Therefore we remove legacy CONFIG_SYS_TIMER_RATE config symbol
that is not longer required.

Furthermore the commit selects CONFIG_TIMER and CONFIG_ARC_TIMER
by default when selecting ARC architecture.

Signed-off-by: Vlad Zakharov 
Reviewed-by: Simon Glass 
---
Changes v3..v4:
 - Remove CONFIG_SYS_TIMER_RATE not only from "axs10x.h" but also
from "nsim.h" and "tb100.h".

 arch/Kconfig   |  2 ++
 arch/arc/dts/skeleton.dtsi |  6 ++
 arch/arc/lib/Makefile  |  1 -
 arch/arc/lib/timer.c   | 24 
 include/configs/axs10x.h   |  2 --
 include/configs/nsim.h |  5 -
 include/configs/tb100.h|  5 -
 7 files changed, 8 insertions(+), 37 deletions(-)
 delete mode 100644 arch/arc/lib/timer.c

diff --git a/arch/Kconfig b/arch/Kconfig
index ffc7b45..56fa70e 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -12,6 +12,8 @@ config ARC
bool "ARC architecture"
select HAVE_PRIVATE_LIBGCC
select SUPPORT_OF_CONTROL
+   select TIMER
+   select ARC_TIMER
 
 config ARM
bool "ARM architecture"
diff --git a/arch/arc/dts/skeleton.dtsi b/arch/arc/dts/skeleton.dtsi
index b41d241..3e93d697 100644
--- a/arch/arc/dts/skeleton.dtsi
+++ b/arch/arc/dts/skeleton.dtsi
@@ -10,4 +10,10 @@
chosen { };
aliases { };
memory { device_type = "memory"; reg = <0 0>; };
+
+   timer@0 {
+   compatible = "snps,arc-timer";
+   clock-frequency = <1>;
+   reg = <0>;
+   };
 };
diff --git a/arch/arc/lib/Makefile b/arch/arc/lib/Makefile
index eb62b3c..12097bf 100644
--- a/arch/arc/lib/Makefile
+++ b/arch/arc/lib/Makefile
@@ -18,7 +18,6 @@ obj-y += memcmp.o
 obj-y += memcpy-700.o
 obj-y += memset.o
 obj-y += reset.o
-obj-y += timer.o
 obj-y += ints_low.o
 obj-y += init_helpers.o
 
diff --git a/arch/arc/lib/timer.c b/arch/arc/lib/timer.c
deleted file mode 100644
index a0acbbc..000
--- a/arch/arc/lib/timer.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * Copyright (C) 2013-2014 Synopsys, Inc. All rights reserved.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-
-#define NH_MODE(1 << 1)/* Disable timer if CPU is halted */
-
-int timer_init(void)
-{
-   write_aux_reg(ARC_AUX_TIMER0_CTRL, NH_MODE);
-   /* Set max value for counter/timer */
-   write_aux_reg(ARC_AUX_TIMER0_LIMIT, 0x);
-   /* Set initial count value and restart counter/timer */
-   write_aux_reg(ARC_AUX_TIMER0_CNT, 0);
-   return 0;
-}
-
-unsigned long timer_read_counter(void)
-{
-   return read_aux_reg(ARC_AUX_TIMER0_CNT);
-}
diff --git a/include/configs/axs10x.h b/include/configs/axs10x.h
index 3546c8d..0476223 100644
--- a/include/configs/axs10x.h
+++ b/include/configs/axs10x.h
@@ -11,8 +11,6 @@
 /*
  *  CPU configuration
  */
-#define CONFIG_SYS_TIMER_RATE  CONFIG_SYS_CLK_FREQ
-
 #define ARC_FPGA_PERIPHERAL_BASE   0xE000
 #define ARC_APB_PERIPHERAL_BASE0xF000
 #define ARC_DWMMC_BASE (ARC_FPGA_PERIPHERAL_BASE + 0x15000)
diff --git a/include/configs/nsim.h b/include/configs/nsim.h
index 1edc560..630d529 100644
--- a/include/configs/nsim.h
+++ b/include/configs/nsim.h
@@ -10,11 +10,6 @@
 #include 
 
 /*
- *  CPU configuration
- */
-#define CONFIG_SYS_TIMER_RATE  CONFIG_SYS_CLK_FREQ
-
-/*
  * Memory configuration
  */
 #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_TEXT_BASE
diff --git a/include/configs/tb100.h b/include/configs/tb100.h
index 39bb5b3..856f8cb 100644
--- a/include/configs/tb100.h
+++ b/include/configs/tb100.h
@@ -10,11 +10,6 @@
 #include 
 
 /*
- *  CPU configuration
- */
-#define CONFIG_SYS_TIMER_RATE  CONFIG_SYS_CLK_FREQ
-
-/*
  * Memory configuration
  */
 #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_TEXT_BASE
-- 
2.7.4

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

[U-Boot] [PATCH v4 1/2] drivers: timer: Introduce ARC timer driver

[Vlad Zakharov]

This commit introduces timer driver for ARC.

ARC timers are configured via ARC AUX registers so we use special
functions to access timer control registers.

This driver allows utilization of either timer0 or timer1
depending on which one is available in real hardware. Essentially
only existing timers should be mentioned in board's Device Tree
description.

Signed-off-by: Vlad Zakharov 
Reviewed-by: Simon Glass 
---
No changes compared to v3

 arch/arc/include/asm/arcregs.h   |   4 ++
 doc/device-tree-bindings/timer/arc_timer.txt |  24 +++
 drivers/timer/Kconfig|  10 +++
 drivers/timer/Makefile   |   1 +
 drivers/timer/arc_timer.c| 101 +++
 5 files changed, 140 insertions(+)
 create mode 100644 doc/device-tree-bindings/timer/arc_timer.txt
 create mode 100644 drivers/timer/arc_timer.c

diff --git a/arch/arc/include/asm/arcregs.h b/arch/arc/include/asm/arcregs.h
index cf999b0..54a9b00 100644
--- a/arch/arc/include/asm/arcregs.h
+++ b/arch/arc/include/asm/arcregs.h
@@ -33,6 +33,10 @@
 #define ARC_AUX_TIMER0_CTRL0x22/* Timer 0 control */
 #define ARC_AUX_TIMER0_LIMIT   0x23/* Timer 0 limit */
 
+#define ARC_AUX_TIMER1_CNT 0x100   /* Timer 1 count */
+#define ARC_AUX_TIMER1_CTRL0x101   /* Timer 1 control */
+#define ARC_AUX_TIMER1_LIMIT   0x102   /* Timer 1 limit */
+
 #define ARC_AUX_INTR_VEC_BASE  0x25
 
 /* Data cache related auxiliary registers */
diff --git a/doc/device-tree-bindings/timer/arc_timer.txt 
b/doc/device-tree-bindings/timer/arc_timer.txt
new file mode 100644
index 000..e25c6ae
--- /dev/null
+++ b/doc/device-tree-bindings/timer/arc_timer.txt
@@ -0,0 +1,24 @@
+ARC Timer
+
+Required properties:
+
+- compatible : should be "snps,arc-timer"
+- reg : Specifies timer ID, could be either 0 or 1.
+- clock-frequency : The frequency of the clock that drives the counter, in Hz.
+
+Examples:
+
+timer@0 {
+   compatible = "snps,arc-timer";
+   clock-frequency = <1>;
+   reg = <0>;
+};
+
+timer@1 {
+   compatible = "snps,arc-timer";
+   clock-frequency = <1>;
+   reg = <1>;
+};
+
+NOTE: if you specify both timers, frequencies should always be the same as 
both timers
+are driven by core clock.
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index cb18f12..d47c62d 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -46,4 +46,14 @@ config OMAP_TIMER
help
  Select this to enable an timer for Omap devices.
 
+config ARC_TIMER
+   bool "ARC timer support"
+   depends on TIMER
+   depends on ARC
+   help
+ Select this to enable built-in ARC timers.
+ ARC cores may have up to 2 built-in timers: timer0 and timer1,
+ usually at least one of them exists. Either of them is supported
+ in U-Boot.
+
 endmenu
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index f351fbb..e9624dd 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_ALTERA_TIMER)  += altera_timer.o
 obj-$(CONFIG_SANDBOX_TIMER)+= sandbox_timer.o
 obj-$(CONFIG_X86_TSC_TIMER)+= tsc_timer.o
 obj-$(CONFIG_OMAP_TIMER)   += omap-timer.o
+obj-$(CONFIG_ARC_TIMER)+= arc_timer.o
diff --git a/drivers/timer/arc_timer.c b/drivers/timer/arc_timer.c
new file mode 100644
index 000..9af2295
--- /dev/null
+++ b/drivers/timer/arc_timer.c
@@ -0,0 +1,101 @@
+/*
+ * Copyright (C) 2016 Synopsys, Inc. All rights reserved.
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define NH_MODE (1 << 1)
+
+/*
+ * ARC timer control registers are mapped to auxiliary address space.
+ * There are special ARC asm command to access that addresses.
+ * Therefore we use built-in functions to read from and write to timer
+ * control register.
+ */
+
+/* Driver private data. Contains AUX register number. */
+struct arc_timer_priv {
+   uint timer_id;
+};
+
+static int arc_timer_get_count(struct udevice *dev, u64 *count)
+{
+   u32 val;
+   struct arc_timer_priv *priv = dev_get_priv(dev);
+   switch (priv->timer_id) {
+   case 0:
+   val = read_aux_reg(ARC_AUX_TIMER0_CNT);
+   break;
+   case 1:
+   val = read_aux_reg(ARC_AUX_TIMER1_CNT);
+   break;
+   }
+   *count = timer_conv_64(val);
+
+   return 0;
+}
+
+static int arc_timer_probe(struct udevice *dev)
+{
+   int id;
+
+   struct arc_timer_priv *priv = dev_get_priv(dev);
+
+   /* Get registers offset and size */
+   id = fdtdec_get_int(gd->fdt_blob, dev->of_offset, "reg", -1);
+   if (id < 0)
+   return -EINVAL;
+   if (id > 1)
+   return -ENXIO;
+
+   priv->timer_id = (uint)id;
+
+   switch (priv->timer_id) {
+   case 0:
+   

Re: [U-Boot] [PATCH v2 9/14] sunxi: Enable UBI and NAND support

[Maxime Ripard]

Hi Tom,

On Tue, Nov 22, 2016 at 10:24:27AM -0500, Tom Rini wrote:
> On Tue, Nov 22, 2016 at 01:38:39PM +0100, Maxime Ripard wrote:
> > From: Hans de Goede 
> > 
> > Enable the NAND and UBI support in the configuration header so that we can
> > (finally) use it.
> > 
> > Signed-off-by: Hans de Goede 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  board/sunxi/Kconfig|  8 
> >  include/configs/sunxi-common.h | 14 ++
> >  2 files changed, 22 insertions(+), 0 deletions(-)
> > 
> > diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> > index e1d4ab148f08..c6a620a20167 100644
> > --- a/board/sunxi/Kconfig
> > +++ b/board/sunxi/Kconfig
> > @@ -460,6 +460,14 @@ config AXP_GPIO
> > ---help---
> > Say Y here to enable support for the gpio pins of the axp PMIC ICs.
> >  
> > +if NAND_SUNXI
> > +config CMD_NAND
> > +   default y
> > +
> > +config CMD_UBI
> > +   default y
> > +endif
> 
> We want to move away from adding 'default y' to board/*/Kconfig and
> instead have 'default y if ...' where the option is declared.

Yeah, I wasn't really sure about this. You can find the two
constructs in there. But ok, that's noted :)

> In this particular case we have a TODO of adding a NAND option that
> would be used to hide things like CMD_NAND and other sub-sections
> rather than using CMD_NAND for everything.

Ok.

> That said, we've just got 2 sunxi boards with NAND today right?  Maybe
> we shouldn't make this default for all sunxi boards yet, yes?  Thanks!

Not really. The huge majority of the rather old boards (basically
everything older than a year or so) is using NAND. However, they're
all using MLC NANDs, which are not supported into UBI right now.

The CHIP Pro is the only board with an Allwinner SoC and an SLC NAND,
hence why we can enable the NAND support.

However, in both cases (MLC and SLC), we'll need UBI. In the former
because other filesystems will not be reliable, in the latter because
the NAND is quite huge and the other filesystems would take an insane
amount of time to be accessed.

Maxime

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


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

Re: [U-Boot] [PATCH] vexpress64: Juno: Change PCI buss addresses for IO to start from zero.

[Ryan Harkin]

On 22 November 2016 at 15:08, Tom Rini  wrote:
> On Tue, Nov 22, 2016 at 12:08:49PM +, Liviu Dudau wrote:
>> On Tue, Nov 22, 2016 at 11:29:20AM +, Sudeep Holla wrote:
>> > Hi Liviu,
>> >
>> > On Tue, Nov 22, 2016 at 11:19 AM, Liviu Dudau  
>> > wrote:
>> > > Juno uses a 1:1 mapping between CPU and PCI addresses for IO. First,
>> > > that will trip devices that cannot use more than 16 bits of addresses
>> > > for IO, second it is un-necessary as the system can handle zero-based
>> > > PCI addresses just fine.
>> > >
>> > > Change the mapping to start IO bus addresses from zero.
>> > >
>> >
>> > I assume this require corresponding DT change, shout if that's not true.
>> > If that's true, then does this patch not require patching of DT so
>> > that systems not
>> > running Uboot with this patch continue to work and we retain the
>> > mainline DT as is ?
>>
>> Yes, it does require DT changes, Jeremy Linton has a patch
>
> So to be clear, what level of coordination do we need between the two
> parts being merged?  It would not be ideal to have combinations of
> U-Boot and Linux not work.  Thanks!
>

I was wondering that too.

However, I just tested the patch in my setup and everything still
seems to work for me.  I'll admit though that I only use the PCIe
network port, I don't have any extra PCIe devices and don't use SATA
drives in my setup.


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

Re: [U-Boot] [PATCH v2 9/14] sunxi: Enable UBI and NAND support

[Peter Robinson]

On Tue, Nov 22, 2016 at 3:24 PM, Tom Rini  wrote:
> On Tue, Nov 22, 2016 at 01:38:39PM +0100, Maxime Ripard wrote:
>> From: Hans de Goede 
>>
>> Enable the NAND and UBI support in the configuration header so that we can
>> (finally) use it.
>>
>> Signed-off-by: Hans de Goede 
>> Signed-off-by: Maxime Ripard 
>> ---
>>  board/sunxi/Kconfig|  8 
>>  include/configs/sunxi-common.h | 14 ++
>>  2 files changed, 22 insertions(+), 0 deletions(-)
>>
>> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
>> index e1d4ab148f08..c6a620a20167 100644
>> --- a/board/sunxi/Kconfig
>> +++ b/board/sunxi/Kconfig
>> @@ -460,6 +460,14 @@ config AXP_GPIO
>>   ---help---
>>   Say Y here to enable support for the gpio pins of the axp PMIC ICs.
>>
>> +if NAND_SUNXI
>> +config CMD_NAND
>> + default y
>> +
>> +config CMD_UBI
>> + default y
>> +endif
>
> We want to move away from adding 'default y' to board/*/Kconfig and
> instead have 'default y if ...' where the option is declared.  In this
> particular case we have a TODO of adding a NAND option that would be
> used to hide things like CMD_NAND and other sub-sections rather than
> using CMD_NAND for everything.
>
> That said, we've just got 2 sunxi boards with NAND today right?  Maybe
> we shouldn't make this default for all sunxi boards yet, yes?  Thanks!

There might be a few more (I think CubieTruck has onboard nand for
example) but at least in Fedora we don't support any of the devices
running nand because of the support in generally isn't great yet.

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

Re: [U-Boot] [PATCH v2 9/14] sunxi: Enable UBI and NAND support

[Tom Rini]

On Tue, Nov 22, 2016 at 01:38:39PM +0100, Maxime Ripard wrote:
> From: Hans de Goede 
> 
> Enable the NAND and UBI support in the configuration header so that we can
> (finally) use it.
> 
> Signed-off-by: Hans de Goede 
> Signed-off-by: Maxime Ripard 
> ---
>  board/sunxi/Kconfig|  8 
>  include/configs/sunxi-common.h | 14 ++
>  2 files changed, 22 insertions(+), 0 deletions(-)
> 
> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> index e1d4ab148f08..c6a620a20167 100644
> --- a/board/sunxi/Kconfig
> +++ b/board/sunxi/Kconfig
> @@ -460,6 +460,14 @@ config AXP_GPIO
>   ---help---
>   Say Y here to enable support for the gpio pins of the axp PMIC ICs.
>  
> +if NAND_SUNXI
> +config CMD_NAND
> + default y
> +
> +config CMD_UBI
> + default y
> +endif

We want to move away from adding 'default y' to board/*/Kconfig and
instead have 'default y if ...' where the option is declared.  In this
particular case we have a TODO of adding a NAND option that would be
used to hide things like CMD_NAND and other sub-sections rather than
using CMD_NAND for everything.

That said, we've just got 2 sunxi boards with NAND today right?  Maybe
we shouldn't make this default for all sunxi boards yet, yes?  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] mx6sx: Add initial support for Samtec VIN|ING 2000 board

[Marek Vasut]

On 11/22/2016 03:48 PM, Christoph Fritz wrote:
>
Commit message is missing

[...]

> diff --git a/board/samtec/vining2000/imximage.cfg 
> b/board/samtec/vining2000/imximage.cfg
> new file mode 100644
> index 000..4133dda
> --- /dev/null
> +++ b/board/samtec/vining2000/imximage.cfg
> @@ -0,0 +1,132 @@
> +/*
> + * Copyright (C) 2016 samtec automotive software & electronics gmbh
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#define __ASSEMBLY__
> +#include 

Is this needed at all ?

> +/* image version */
> +
> +IMAGE_VERSION 2

[...]

> diff --git a/board/samtec/vining2000/vining2000.c 
> b/board/samtec/vining2000/vining2000.c
> new file mode 100644
> index 000..e73e57b
> --- /dev/null
> +++ b/board/samtec/vining2000/vining2000.c


[...]

> +static iomux_v3_cfg_t const uart1_pads[] = {
> + MX6_PAD_GPIO1_IO04__UART1_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
> + MX6_PAD_GPIO1_IO05__UART1_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
> +};
> +
> +static iomux_v3_cfg_t const usdhc2_pads[] = {
> + MX6_PAD_SD2_CLK__USDHC2_CLK | MUX_PAD_CTRL(0x10059),

Use macros for this MUX_PAD_CTRL() argument, fix globally.

> + MX6_PAD_SD2_CMD__USDHC2_CMD | MUX_PAD_CTRL(0x17059),
> + MX6_PAD_SD2_DATA0__USDHC2_DATA0 | MUX_PAD_CTRL(0x17059),
> + MX6_PAD_SD2_DATA1__USDHC2_DATA1 | MUX_PAD_CTRL(0x17059),
> + MX6_PAD_SD2_DATA2__USDHC2_DATA2 | MUX_PAD_CTRL(0x17059),
> + MX6_PAD_SD2_DATA3__USDHC2_DATA3 | MUX_PAD_CTRL(0x17059),
> + MX6_PAD_LCD1_VSYNC__GPIO3_IO_28 | MUX_PAD_CTRL(0x8000),
> +};


[...]

> +int board_eth_init(bd_t *bis)
> +{
> + struct iomuxc *iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
> + int reg, ret;
> + unsigned char eth1addr[6];
> +
> + imx_iomux_v3_setup_multiple_pads(fec1_pads, ARRAY_SIZE(fec1_pads));
> + gpio_direction_output(IMX_GPIO_NR(5, 9) , 0);
> +
> + reg = readl(_regs->gpr[1]);
> + /* Generate phy reference clock via pin IOMUX ENET_REF_CLK1/2 by erasing
> +  * ENET1/2_TX_CLK_DIR gpr1[14:13], so that reference clock is driven by
> +  * ref_enetpll0/1.
> +  */

Multiline comment has this format:
/*
 * foo
 * bar
 */

> + reg &= ~(IOMUX_GPR1_FEC1_CLOCK_MUX2_SEL_MASK |
> + IOMUX_GPR1_FEC2_CLOCK_MUX2_SEL_MASK);
> +
> + /* Enable ENET1/2_TX_CLK output driver. */
> + reg |= IOMUX_GPR1_FEC1_CLOCK_MUX1_SEL_MASK |
> + IOMUX_GPR1_FEC2_CLOCK_MUX1_SEL_MASK;
> + writel(reg, _regs->gpr[1]);

clrsetbits_le32() here.

> + ret = enable_fec_anatop_clock(0, ENET_50MHZ);
> +
> + if (ret)
> + printf("FEC anatop MXC: %s:failed (%0x)\n",  __func__, ret);
> +
> + gpio_set_value(IMX_GPIO_NR(5, 9), 1);
> + mdelay(5);
> + gpio_direction_output(IMX_GPIO_NR(5, 9) , 0);
> + mdelay(5);
> + gpio_set_value(IMX_GPIO_NR(5, 9), 1);
> + mdelay(5);

What's this random GPIO poking for ?

> + ret = fecmxc_initialize_multi(bis, 0, CONFIG_FEC_MXC_PHYADDR,
> + IMX_FEC_BASE);
> + if (ret)
> + printf("FEC MXC: %s:failed\n", __func__);
> +
> + /* just to get secound mac address */
> + imx_get_mac_from_fuse(1, eth1addr);
> + if (is_valid_ethaddr(eth1addr))
> + if (!getenv("eth1addr"))

Wrap this into single conditional -- if (foo() && !bar)

> + eth_setenv_enetaddr("eth1addr", eth1addr);
> +
> + return ret;
> +}
> +
> +#define PC MUX_PAD_CTRL(I2C_PAD_CTRL)
> +/* I2C1 for PMIC */
> +static struct i2c_pads_info i2c_pad_info1 = {
> + .scl = {
> + .i2c_mode = MX6_PAD_GPIO1_IO00__I2C1_SCL | PC,
> + .gpio_mode = MX6_PAD_GPIO1_IO00__GPIO1_IO_0 | PC,
> + .gp = IMX_GPIO_NR(1, 0),
> + },
> + .sda = {
> + .i2c_mode = MX6_PAD_GPIO1_IO01__I2C1_SDA | PC,
> + .gpio_mode = MX6_PAD_GPIO1_IO01__GPIO1_IO_1 | PC,
> + .gp = IMX_GPIO_NR(1, 1),
> + },
> +};
> +
> +struct pmic *pfuze_init(unsigned char i2cbus)

static struct ?

> +{
> + struct pmic *p;
> + int ret;
> + unsigned int reg;
> +
> + ret = power_pfuze100_init(i2cbus);
> + if (ret)
> + return NULL;
> +
> + p = pmic_get("PFUZE100");
> + ret = pmic_probe(p);
> + if (ret)
> + return NULL;
> +
> + pmic_reg_read(p, PFUZE100_DEVICEID, );
> + printf("PMIC:  PFUZE100 ID=0x%02x\n", reg);
> +
> + /* Set SW1AB stanby volage to 0.975V */
> + pmic_reg_read(p, PFUZE100_SW1ABSTBY, );
> + reg &= ~SW1x_STBY_MASK;
> + reg |= SW1x_0_975V;
> + pmic_reg_write(p, PFUZE100_SW1ABSTBY, reg);
> +
> + /* Set SW1AB/VDDARM step ramp up time from 16us to 4us/25mV */
> + pmic_reg_read(p, PFUZE100_SW1ABCONF, );
> + reg &= ~SW1xCONF_DVSSPEED_MASK;
> + reg |= SW1xCONF_DVSSPEED_4US;
> + pmic_reg_write(p, PFUZE100_SW1ABCONF, reg);
> +
> + /* Set SW1C standby voltage to 0.975V */
> + pmic_reg_read(p, PFUZE100_SW1CSTBY, );
> + reg &= ~SW1x_STBY_MASK;
> + reg |= 

Re: [U-Boot] [PATCH v2 8/14] mtd: sunxi: Change U-Boot offset

[Tom Rini]

On Tue, Nov 22, 2016 at 01:38:38PM +0100, Maxime Ripard wrote:

> The default U-Boot offset for the Allwinner SoCs was set to 32kB.
> 
> This was probably to try to maintain some compatibility with the current
> image that we build for the MMC where the U-Boot binary is also located at
> a 32kB offset.
> 
> However, this causes a number of issues. The first one is that it prevents
> us from using a backup SPL entirely, which is troublesome in case where the
> first would be corrupt (especially on MLC which have a higher number of
> bitflips).
> 
> We also cannot use the original MMC image on the NAND, because we need to
> prepare the SPL image to include the ECCs and randomizer settings, which
> reduces the interest of setting it at that particular offset.
> 
> It also prevents us from upgrading and flashing the U-Boot and SPLs
> independantly, since it's very likely that it will fall in the same erase
> block.
> 
> Since that default wasn't used by any board, change it for 8MB, which will
> be in an erase block of its own, all the erase blocks being multiple of
> two. The highest erase block size we encountered is 4MB, which means that
> in this particular setup, the first and second erase blocks will be for the
> SPL and its backup, and the third for U-Boot.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 10/14] sunxi: Add the default mtdids and mtdparts to our env

[Tom Rini]

On Tue, Nov 22, 2016 at 01:38:40PM +0100, Maxime Ripard wrote:

> In order for the user to be able to see and modify them, add those
> variables to the default environment.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 5/14] common: Move environment choice to Kconfig

[Tom Rini]

On Tue, Nov 22, 2016 at 01:38:35PM +0100, Maxime Ripard wrote:

> The environment location is something that might change per board
> (depending on what storage options are availaible there) or depending on
> the user choice (when we have several options).
> 
> Instead of hardcoding it in our configuration header, create a Kconfig
> choice with the options we use for now, and the symbols that depend on it.
> 
> Once done, also remove the irrelevant sunxi defines.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v2 6/14] cmd: Add Kconfig option for CMD_MTDPARTS and related options

[Tom Rini]

On Tue, Nov 22, 2016 at 01:38:36PM +0100, Maxime Ripard wrote:

> CMD_MTDPARTS is something the user might or might not want to select, and
> might depends on (or be selected by) other options too.
> 
> This is even truer for the MTDIDS_DEFAULT and MTDPARTS_DEFAULT options that
> might change from one board to another, or from one user to the other,
> depending on what it expects and what storage devices are available.
> 
> In order to ease that configuration, add those options to Kconfig.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Tom Rini 

-- 
Tom


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

[U-Boot] [PATCH] net: usb: r8152: Use ALLOC_CACHE_ALIGN_BUFFER() to allocate the buffers

[Stefan Roese]

Testing on theadorable (Armada XP) has shown, that using this driver
results in many cache misaligned warning, such as:

CACHE: Misaligned operation at range [7fabd8fc, 7fabd900]

This patch now uses the ALLOC_CACHE_ALIGN_BUFFER() macro to allocate the
buffers on a cache aligned boundary. This fixes all warnings seen on the
Armada XP platform.

Signed-off-by: Stefan Roese 
Cc: Ted Chen 
Cc: Joe Hershberger 
---
 drivers/usb/eth/r8152.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/eth/r8152.c b/drivers/usb/eth/r8152.c
index 070aadf..ed441f3 100644
--- a/drivers/usb/eth/r8152.c
+++ b/drivers/usb/eth/r8152.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -71,17 +72,25 @@ static const struct r8152_version const r8152_versions[] = {
 static
 int get_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data)
 {
-   return usb_control_msg(tp->udev, usb_rcvctrlpipe(tp->udev, 0),
-  RTL8152_REQ_GET_REGS, RTL8152_REQT_READ,
-  value, index, data, size, 500);
+   ALLOC_CACHE_ALIGN_BUFFER(void *, tmp, size);
+   int ret;
+
+   ret = usb_control_msg(tp->udev, usb_rcvctrlpipe(tp->udev, 0),
+   RTL8152_REQ_GET_REGS, RTL8152_REQT_READ,
+   value, index, tmp, size, 500);
+   memcpy(data, tmp, size);
+   return ret;
 }
 
 static
 int set_registers(struct r8152 *tp, u16 value, u16 index, u16 size, void *data)
 {
+   ALLOC_CACHE_ALIGN_BUFFER(void *, tmp, size);
+
+   memcpy(tmp, data, size);
return usb_control_msg(tp->udev, usb_sndctrlpipe(tp->udev, 0),
   RTL8152_REQ_SET_REGS, RTL8152_REQT_WRITE,
-  value, index, data, size, 500);
+  value, index, tmp, size, 500);
 }
 
 int generic_ocp_read(struct r8152 *tp, u16 index, u16 size,
@@ -1216,7 +1225,8 @@ static int r8152_send_common(struct ueth_data *ueth, void 
*packet, int length)
u32 opts1, opts2 = 0;
int err;
int actual_len;
-   unsigned char msg[PKTSIZE + sizeof(struct tx_desc)];
+   ALLOC_CACHE_ALIGN_BUFFER(uint8_t, msg,
+PKTSIZE + sizeof(struct tx_desc));
struct tx_desc *tx_desc = (struct tx_desc *)msg;
 
debug("** %s(), len %d\n", __func__, length);
@@ -1257,7 +1267,7 @@ static int r8152_recv(struct eth_device *eth)
 {
struct ueth_data *dev = (struct ueth_data *)eth->priv;
 
-   static unsigned char  recv_buf[RTL8152_AGG_BUF_SZ];
+   ALLOC_CACHE_ALIGN_BUFFER(uint8_t, recv_buf, RTL8152_AGG_BUF_SZ);
unsigned char *pkt_ptr;
int err;
int actual_len;
-- 
2.10.2

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

Re: [U-Boot] [PATCH v2 3/14] bch: Allow to build for the host

[Tom Rini]

On Tue, Nov 22, 2016 at 01:38:33PM +0100, Maxime Ripard wrote:

> We will need the bch functions in the tool to generate the SPL images for
> the Allwinner SoCs.
> 
> Do the needed adjustments so that we can use it on the host.
> 
> Signed-off-by: Maxime Ripard 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH] vexpress64: Juno: Change PCI buss addresses for IO to start from zero.

[Tom Rini]

On Tue, Nov 22, 2016 at 12:08:49PM +, Liviu Dudau wrote:
> On Tue, Nov 22, 2016 at 11:29:20AM +, Sudeep Holla wrote:
> > Hi Liviu,
> > 
> > On Tue, Nov 22, 2016 at 11:19 AM, Liviu Dudau  
> > wrote:
> > > Juno uses a 1:1 mapping between CPU and PCI addresses for IO. First,
> > > that will trip devices that cannot use more than 16 bits of addresses
> > > for IO, second it is un-necessary as the system can handle zero-based
> > > PCI addresses just fine.
> > >
> > > Change the mapping to start IO bus addresses from zero.
> > >
> > 
> > I assume this require corresponding DT change, shout if that's not true.
> > If that's true, then does this patch not require patching of DT so
> > that systems not
> > running Uboot with this patch continue to work and we retain the
> > mainline DT as is ?
> 
> Yes, it does require DT changes, Jeremy Linton has a patch 

So to be clear, what level of coordination do we need between the two
parts being merged?  It would not be ideal to have combinations of
U-Boot and Linux not work.  Thanks!

-- 
Tom


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

Re: [U-Boot] [Resend RFC PATCH v1 0/3] GPT over MTD

[Ladislav Michl]

Hi,

On Tue, Nov 22, 2016 at 02:24:39PM +0100, Patrick Delaunay wrote:
> 
> I have a request to support GPT over MTD to be able to have dynamic
> MTD informations without u-Boot environment(CONFIG_ENV_IS_NOWHERE
> is a other requirement of my project).

I'm just curious, could you provide some reasoning, why this is a requirement?

> The idea is to use the GPT header to save partitioning information directly
> in flash device (NOR or NAND), then the MTD variables are rebuild from
> these GPT partitions and can be used by DISTRO to search bootable binary.

Ok, so you stored partitioning information on flash... That seems to be some
kind of limited environment saved :-)

> I make a first prototyping for this request but I want ask you if this
> feature is acceptable for u-boot and if this patches, after some update
> and cleanups, would be merged in u-boot mainline.
> Do you see already some blocking points ?

Is there any reason why you cannot use UBI?

> - added code is under a new CONFIG : CONFIG_EFI_PARTITION_MTD
> - for implementation details, see doc/README.gpt.mtd
> 
> TODO:
> - split patch between core impact (disk/part_efi.c)
>   and command update
> - full support for modified command
>   (today I limit the support for the command used by DISTRO macro)
> - DISTRO macro update for automatic boot on GPT bootable partition
>   found in MTD devices

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

Re: [U-Boot] [PATCH 2/3] ARM: DRA7: Redefine voltage and efuse macros per OPP using Kconfig

[Tom Rini]

On Tue, Nov 22, 2016 at 11:51:38AM +0530, Lokesh Vutla wrote:
> From: Suman Anna 
> 
> Redefine the macros used to define the voltage values and the
> efuse register offsets based on OPP for all the voltage domains.
> This is done using Kconfig macros that can be set in a defconfig
> or selected during a config step. This allows a voltage domain
> to be configured/set to a corresponding voltage value depending
> on the OPP selection choice.
> 
> The Kconfig choices have been added for MPU, DSPEVE, IVA and GPU
> voltage domains, with the MPU domain restricted to OPP_NOM. The
> OPP_OD and OPP_HIGH options will be added when the support for
> configuring the MPU clock frequency is added. The clock
> configuration for other voltage domains is out of scope in
> u-boot code.
> 
> The CORE voltage domain does not have separate voltage values
> and efuse register offset at different OPPs, while the MPU
> voltage domain only has different efuse register offsets for
> different OPPs, but uses the same voltage value. Any different
> choices of OPPs for voltage domains on common ganged-rails
> is automatically taken care to select the corresponding
> highest OPP voltage value.
> 
> Signed-off-by: Suman Anna 
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/include/asm/arch-omap5/clock.h | 47 +---
>  arch/arm/mach-omap2/omap5/Kconfig   | 65 
> +
>  2 files changed, 99 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm/include/asm/arch-omap5/clock.h 
> b/arch/arm/include/asm/arch-omap5/clock.h
> index 551c927..e8b286b 100644
> --- a/arch/arm/include/asm/arch-omap5/clock.h
> +++ b/arch/arm/include/asm/arch-omap5/clock.h
> @@ -286,19 +286,40 @@
>  /* STD_FUSE_OPP_VMIN_MPU_4 */
>  #define STD_FUSE_OPP_VMIN_MPU_HIGH   (DRA752_EFUSE_BASE + 0x1B28)
>  
> -/* Common voltage and Efuse register macros */
> -/* DRA74x/DRA75x/DRA72x */
> -#define VDD_MPU_DRA7 VDD_MPU_DRA7_NOM
> -#define VDD_CORE_DRA7VDD_CORE_DRA7_NOM
> -#define VDD_EVE_DRA7 VDD_EVE_DRA7_NOM
> -#define VDD_GPU_DRA7 VDD_GPU_DRA7_NOM
> -#define VDD_IVA_DRA7 VDD_IVA_DRA7_NOM
> -
> -#define STD_FUSE_OPP_VMIN_MPUSTD_FUSE_OPP_VMIN_MPU_NOM
> -#define STD_FUSE_OPP_VMIN_CORE   STD_FUSE_OPP_VMIN_CORE_NOM
> -#define STD_FUSE_OPP_VMIN_DSPEVE STD_FUSE_OPP_VMIN_DSPEVE_NOM
> -#define STD_FUSE_OPP_VMIN_GPUSTD_FUSE_OPP_VMIN_GPU_NOM
> -#define STD_FUSE_OPP_VMIN_IVASTD_FUSE_OPP_VMIN_IVA_NOM
> +#if defined(CONFIG_DRA7_MPU_OPP_HIGH)
> +#define DRA7_MPU_OPP OPP_HIGH
> +#elif defined(CONFIG_DRA7_MPU_OPP_OD)
> +#define DRA7_MPU_OPP OPP_OD
> +#else /* OPP_NOM default */
> +#define DRA7_MPU_OPP OPP_NOM
> +#endif
> +
> +/* OPP_NOM only available option for CORE */
> +#define DRA7_CORE_OPPOPP_NOM
> +
> +#if defined(CONFIG_DRA7_DSPEVE_OPP_HIGH)
> +#define DRA7_DSPEVE_OPP  OPP_HIGH
> +#elif defined(CONFIG_DRA7_DSPEVE_OPP_OD)
> +#define DRA7_DSPEVE_OPP  OPP_OD
> +#else /* OPP_NOM default */
> +#define DRA7_DSPEVE_OPP  OPP_NOM
> +#endif
> +
> +#if defined(CONFIG_DRA7_IVA_OPP_HIGH)
> +#define DRA7_IVA_OPP OPP_HIGH
> +#elif defined(CONFIG_DRA7_IVA_OPP_OD)
> +#define DRA7_IVA_OPP OPP_OD
> +#else /* OPP_NOM default */
> +#define DRA7_IVA_OPP OPP_NOM
> +#endif
> +
> +#if defined(CONFIG_DRA7_GPU_OPP_HIGH)
> +#define DRA7_GPU_OPP OPP_HIGH
> +#elif defined(CONFIG_DRA7_GPU_OPP_OD)
> +#define DRA7_GPU_OPP OPP_OD
> +#else /* OPP_NOM default */
> +#define DRA7_GPU_OPP OPP_NOM
> +#endif
>  
>  /* Standard offset is 0.5v expressed in uv */
>  #define PALMAS_SMPS_BASE_VOLT_UV 50
> diff --git a/arch/arm/mach-omap2/omap5/Kconfig 
> b/arch/arm/mach-omap2/omap5/Kconfig
> index 22259dc..6741149 100644
> --- a/arch/arm/mach-omap2/omap5/Kconfig
> +++ b/arch/arm/mach-omap2/omap5/Kconfig
> @@ -91,4 +91,69 @@ source "board/ti/omap5_uevm/Kconfig"
>  source "board/ti/dra7xx/Kconfig"
>  source "board/ti/am57xx/Kconfig"
>  
> +if TARGET_DRA7XX_EVM || TARGET_AM57XX_EVM
> +menu "Voltage Domain OPP selections"
> +
> +choice
> + prompt "MPU Voltage Domain"
> + default DRA7_MPU_OPP_NOM
> +help
> +   Select the OPP for the MPU voltage domain on DRA7xx & AM57xx SoCs
> +
> +config DRA7_MPU_OPP_NOM
> + bool "OPP NOM"
> +
> +endchoice
> +
> +choice
> + prompt "DSPEVE Voltage Domain"
> +help
> +   Select the OPP for the DSPEVE voltage domain on DRA7xx and AM57xx SoCs

Can we please add some text about what NOM, OD and so forth mean in the
help text?  Also, the rest of the series is missing, thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] board: topic: Detect RAM size at boot

[Mike Looijmans]

On 22-11-16 12:00, Michal Simek wrote:

On 21.11.2016 09:30, Mike Looijmans wrote:

Miami boards can have memory sizes of 256M, 512M or 1GB. To prevent requiring
separate bootloaders for each variant, just detect the RAM size at boot time
instead of relying on the devicetree information.

Signed-off-by: Mike Looijmans 
---
 board/topic/zynq/board.c  | 39 +++
 configs/topic_miami_defconfig |  1 +
 configs/topic_miamiplus_defconfig |  1 +
 3 files changed, 41 insertions(+)

diff --git a/board/topic/zynq/board.c b/board/topic/zynq/board.c
index a95c9d1..8a5765e 100644
--- a/board/topic/zynq/board.c
+++ b/board/topic/zynq/board.c
@@ -1 +1,40 @@
+/*
+ * (C) Copyright 2016 Topic Embedded Products
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * Miami boards can have memory sizes of 256M, 512M or 1GB. To prevent needing
+ * separate bootloaders for each variant, just detect the RAM size at boot time
+ * instead of relying on the devicetree information.
+ */
+#define CONFIG_SYS_SDRAM_BASE  0
+#define CONFIG_SYS_SDRAM_SIZE  topic_get_sdram_size()


I am not happy with this but I see where you go.


Of the several options I tried to "overload" the memory init functions, this 
was basically the lesser evil...


Maybe it would be possible to make some changes to the generic Zynq board.c 
file to facilitate overlaying the code?


Note that the memory detection would work on any board, not just the Topic 
boards. I agree that devicetree is considered the best thing since frozen 
pizza, but for the Zynq it looks as though detection is much simpler than 
static configuration.





+#define CONFIG_SYS_SDRAM_SIZE_MAX 0x4000u
+
+static unsigned int topic_get_sdram_size(void);
+
 #include "../../xilinx/zynq/board.c"
+
+#include 
+
+int ft_board_setup(void *blob, bd_t *bd)
+{
+   fdt_fixup_memory(blob, (u64)CONFIG_SYS_SDRAM_BASE, (u64)gd->ram_size);
+
+   return 0;
+}


This action is taken at arch_fixup_fdt(). Can you please confirm that
this is really needed? And it is not done there? That you don't
duplicate stuff here.


If I omitted this step, the Linux devicetree would not be adjusted (during 
bootm) and would still report its default. I needed both arch_fixup_fdt and 
this extra line to properly adjust the Linux devicetree for booting.






+
+void dram_init_banksize(void)
+{
+   gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+   gd->bd->bi_dram[0].size = gd->ram_size;
+}


This should be fine.



A note here, if you compile for Zynq with  CONFIG_SYS_SDRAM_BASE and 
CONFIG_SYS_SDRAM_SIZE set, there will be no implementation of 
'dram_init_banksize' and the system will fail to boot.


It might be wise to put this snippet into the zynq/board.c in the "#else" 
clause. I'll send a separate patch for that if you agree.




+
+unsigned int topic_get_sdram_size(void)
+{
+   /* Detect and fix ram size */
+   return get_ram_size((void *)CONFIG_SYS_SDRAM_BASE,
+  CONFIG_SYS_SDRAM_SIZE_MAX);


In the first look I didn't know that get_ram_size is u-boot function for
memsize detection.


Indeed, the name "get_ram_size" doesn't really match what it actually does, 
but the function's documentation is quite good.


I found "get_ram_size" and "ft_board_setup" while browsing the code of other 
boards to see how they handled dynamic configuration.



Thanks,
Michal






Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





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

[U-Boot] [PATCH] mx6sx: Add initial support for Samtec VIN|ING 2000 board

[Christoph Fritz]

Signed-off-by: Christoph Fritz 
---
 arch/arm/cpu/armv7/mx6/Kconfig   |   7 +
 board/samtec/vining2000/Kconfig  |  12 +
 board/samtec/vining2000/MAINTAINERS  |   6 +
 board/samtec/vining2000/Makefile |   6 +
 board/samtec/vining2000/imximage.cfg | 132 +
 board/samtec/vining2000/vining2000.c | 538 +++
 configs/vining2000_defconfig |  30 ++
 include/configs/vining2000.h | 171 +++
 8 files changed, 902 insertions(+)
 create mode 100644 board/samtec/vining2000/Kconfig
 create mode 100644 board/samtec/vining2000/MAINTAINERS
 create mode 100644 board/samtec/vining2000/Makefile
 create mode 100644 board/samtec/vining2000/imximage.cfg
 create mode 100644 board/samtec/vining2000/vining2000.c
 create mode 100644 configs/vining2000_defconfig
 create mode 100644 include/configs/vining2000.h

diff --git a/arch/arm/cpu/armv7/mx6/Kconfig b/arch/arm/cpu/armv7/mx6/Kconfig
index 762a581..eea7ce6 100644
--- a/arch/arm/cpu/armv7/mx6/Kconfig
+++ b/arch/arm/cpu/armv7/mx6/Kconfig
@@ -192,6 +192,12 @@ config TARGET_UDOO
bool "udoo"
select SUPPORT_SPL
 
+config TARGET_VINING2000
+   bool "VIN|ING 2000 Samtec board"
+   select MX6SX
+   select DM
+   select DM_THERMAL
+
 config TARGET_WANDBOARD
bool "wandboard"
select SUPPORT_SPL
@@ -247,6 +253,7 @@ source "board/freescale/mx6ullevk/Kconfig"
 source "board/phytec/pcm058/Kconfig"
 source "board/gateworks/gw_ventana/Kconfig"
 source "board/kosagi/novena/Kconfig"
+source "board/samtec/vining2000/Kconfig"
 source "board/seco/Kconfig"
 source "board/solidrun/mx6cuboxi/Kconfig"
 source "board/technexion/pico-imx6ul/Kconfig"
diff --git a/board/samtec/vining2000/Kconfig b/board/samtec/vining2000/Kconfig
new file mode 100644
index 000..aca91a4
--- /dev/null
+++ b/board/samtec/vining2000/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_VINING2000
+
+config SYS_BOARD
+   default "vining2000"
+
+config SYS_VENDOR
+   default "samtec"
+
+config SYS_CONFIG_NAME
+   default "vining2000"
+
+endif
diff --git a/board/samtec/vining2000/MAINTAINERS 
b/board/samtec/vining2000/MAINTAINERS
new file mode 100644
index 000..0efea87
--- /dev/null
+++ b/board/samtec/vining2000/MAINTAINERS
@@ -0,0 +1,6 @@
+VINING2000 BOARD
+M: Ingo Schroeck 
+S: Maintained
+F: board/samtec/vining2000/
+F: include/configs/vining2000.h
+F: configs/vining2000_defconfig
diff --git a/board/samtec/vining2000/Makefile b/board/samtec/vining2000/Makefile
new file mode 100644
index 000..b2be95d
--- /dev/null
+++ b/board/samtec/vining2000/Makefile
@@ -0,0 +1,6 @@
+# (C) Copyright 2016 samtec automotive software & electronics gmbh
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y  := vining2000.o
diff --git a/board/samtec/vining2000/imximage.cfg 
b/board/samtec/vining2000/imximage.cfg
new file mode 100644
index 000..4133dda
--- /dev/null
+++ b/board/samtec/vining2000/imximage.cfg
@@ -0,0 +1,132 @@
+/*
+ * Copyright (C) 2016 samtec automotive software & electronics gmbh
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#define __ASSEMBLY__
+#include 
+
+/* image version */
+
+IMAGE_VERSION 2
+
+/*
+ * Boot Device : one of
+ * spi/sd/nand/onenand, qspi/nor
+ */
+
+BOOT_FROM  sd
+
+/*
+ * Device Configuration Data (DCD)
+ *
+ * Each entry must have the format:
+ * Addr-type   AddressValue
+ *
+ * where:
+ * Addr-type register length (1,2 or 4 bytes)
+ * Address   absolute address of the register
+ * value value to be stored in the register
+ */
+
+/* Enable all clocks */
+DATA 4 0x020c4068 0x
+DATA 4 0x020c406c 0x
+DATA 4 0x020c4070 0x
+DATA 4 0x020c4074 0x
+DATA 4 0x020c4078 0x
+DATA 4 0x020c407c 0x
+DATA 4 0x020c4080 0x
+DATA 4 0x020c4084 0x
+
+/* IOMUX - DDR IO Type */
+DATA 4 0x020e0618 0x000c
+DATA 4 0x020e05fc 0x
+
+/* Clock */
+DATA 4 0x020e032c 0x0030
+
+/* Address */
+DATA 4 0x020e0300 0x0028
+DATA 4 0x020e02fc 0x0028
+DATA 4 0x020e05f4 0x0028
+
+/* Control */
+DATA 4 0x020e0340 0x0028
+
+DATA 4 0x020e0320 0x
+DATA 4 0x020e0310 0x0028
+DATA 4 0x020e0314 0x0028
+DATA 4 0x020e0614 0x0028
+
+/* Data Strobe */
+DATA 4 0x020e05f8 0x0002
+DATA 4 0x020e0330 0x0028
+DATA 4 0x020e0334 0x0028
+DATA 4 0x020e0338 0x0028
+DATA 4 0x020e033c 0x0028
+
+/* Data */
+DATA 4 0x020e0608 0x0002
+DATA 4 0x020e060c 0x0028
+DATA 4 0x020e0610 0x0028
+DATA 4 0x020e061c 0x0028
+DATA 4 0x020e0620 0x0028
+DATA 4 0x020e02ec 0x0028
+DATA 4 0x020e02f0 0x0028
+DATA 4 0x020e02f4 0x0028
+DATA 4 0x020e02f8 0x0028
+
+/* Calibrations - ZQ */
+DATA 4 0x021b0800 0xa1390003
+
+/* Write leveling */
+DATA 4 0x021b080c 0x00290025
+DATA 4 0x021b0810 0x00210022
+
+/* DQS Read Gate */
+DATA 4 0x021b083c 0x4142013a
+DATA 4 0x021b0840 0x012e0123
+
+/* Read/Write 

Re: [U-Boot] flashair and u-boot hooks script

[Michal Simek]

On 22.11.2016 15:33, Tom Rini wrote:
> On Tue, Nov 22, 2016 at 03:12:52PM +0100, Michal Simek wrote:
>> Hi guys,
>>
>> did you see this problem before?
>>
>> [bin]$ ./u-boot-test-flash xilinx_zynqmp_zcu102  zcu102
>> 192.168.0.103 push:/tmp/tmp.I2MxPKltj7
>> PUSH DIR: /tmp/tmp.I2MxPKltj7
>> ..PUSH FILE: u-boot.bin
>>  200
>> [bin]$ ./u-boot-test-flash xilinx_zynqmp_zcu102  zcu102
>> ./flashair.zynqmp: line 42: : No such file or directory
> 
> OK, what's at line 42 here?  I assume this is modeled on the rpi script
> since you're deleting thing.
> 
> I also assume that you have things similar to
> http://konsulko.com/developing-on-hardware-without-functional-networking/
> and I just re-checked and I have nothing special set on my RPi 3 that's
> not also listed in that example.  Thanks!
> 

It looks like there is a bug in the script at least for me where you
need to assigned params in requests.get.

Not a python guy that's why this needs to be checked by someone else.

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

Re: [U-Boot] flashair and u-boot hooks script

[Michal Simek]

On 22.11.2016 15:12, Michal Simek wrote:
> Hi guys,
> 
> did you see this problem before?
> 
> [bin]$ ./u-boot-test-flash xilinx_zynqmp_zcu102  zcu102
> 192.168.0.103 push:/tmp/tmp.I2MxPKltj7
> PUSH DIR: /tmp/tmp.I2MxPKltj7
> ..PUSH FILE: u-boot.bin
>  200
> [bin]$ ./u-boot-test-flash xilinx_zynqmp_zcu102  zcu102
> ./flashair.zynqmp: line 42: : No such file or directory
> [bin]$ ./u-boot-test-flash xilinx_zynqmp_zcu102  zcu102
> 192.168.0.103 rmlist:/tmp/tmp.UuwcmCDprT push:/tmp/tmp.tmM0rQ89CJ
> RM LIST: /tmp/tmp.UuwcmCDprT
> Traceback (most recent call last):
>   File "/home/monstr/bin/uboot-test-hooks/bin/push-flashair.py", line
> 118, in 
> main()
>   File "/home/monstr/bin/uboot-test-hooks/bin/push-flashair.py", line
> 115, in main
> func(args.host, param)
>   File "/home/monstr/bin/uboot-test-hooks/bin/push-flashair.py", line
> 61, in op_rm_list
> response = requests.get('http://%s/command.cgi' % host, params)
> TypeError: get() takes 1 positional argument but 2 were given
> 
> 
> Pushing files is fine but removing note. Is there any setting which
> needs to be done on flashair to support removing files?


After playing with this I found that this is fixing it.
Why - I have no idea. Can you please make a commit message and test this?

 diff --git a/bin/push-flashair.py b/bin/push-flashair.py
 index 1466f1586f33..b71149a4e603 100755
 --- a/bin/push-flashair.py
 +++ b/bin/push-flashair.py
 @@ -58,7 +58,7 @@ def op_push_dir(host, local_dir):
  def op_rm_list(host, rm_list_file):
  print('RM LIST: ' + rm_list_file)
  params = {'op': 100, 'DIR': '/'}
 -response = requests.get('http://%s/command.cgi' % host, params)
 +response = requests.get('http://%s/command.cgi' % host, params=params)
  response.raise_for_status()
  lines = response.text.splitlines()
  if lines[0] != 'WLANSD_FILELIST':
 @@ -78,7 +78,7 @@ def op_rm_list(host, rm_list_file):
  if fnmatch.fnmatch(remote_filename, rmspec):
  print('..DELETE: ' + remote_filename)
  params = {'DEL': '/' + remote_filename}
 -response = requests.get('http://%s/upload.cgi' %
host, params)
 +response = requests.get('http://%s/upload.cgi' %
host, params=params)
  print(' ' + str(response.status_code))
  response.raise_for_status()
  if 'SUCCESS' not in response.text:

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

Re: [U-Boot] flashair and u-boot hooks script

[Tom Rini]

On Tue, Nov 22, 2016 at 03:12:52PM +0100, Michal Simek wrote:
> Hi guys,
> 
> did you see this problem before?
> 
> [bin]$ ./u-boot-test-flash xilinx_zynqmp_zcu102  zcu102
> 192.168.0.103 push:/tmp/tmp.I2MxPKltj7
> PUSH DIR: /tmp/tmp.I2MxPKltj7
> ..PUSH FILE: u-boot.bin
>  200
> [bin]$ ./u-boot-test-flash xilinx_zynqmp_zcu102  zcu102
> ./flashair.zynqmp: line 42: : No such file or directory

OK, what's at line 42 here?  I assume this is modeled on the rpi script
since you're deleting thing.

I also assume that you have things similar to
http://konsulko.com/developing-on-hardware-without-functional-networking/
and I just re-checked and I have nothing special set on my RPi 3 that's
not also listed in that example.  Thanks!

-- 
Tom


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