date:20160709

Re: [U-Boot] [U-BOOT][PATCH v2] net:Add EMAC driver for H3/A83T/A64 SoCs.

2016-07-09 Thread Hans de Goede


Hi,

On 06-07-16 14:29, Amit Singh Tomar wrote:

This patch add EMAC driver support for H3/A83T/A64 SoCs.
Tested on Pine64(A64-External PHY) and Orangepipc(H3-Internal PHY).

BIG Thanks to Andre for providing some of the DT code.

Signed-off-by: Amit Singh Tomar 


Thank you, I've added this patch to u-boot-sunxi/next

Regards,

Hans



---
Changes since v1:
* Addressed LABBE's comments.
* Made it compatible with External PHY.
---
 arch/arm/dts/sun50i-a64-pine64-plus.dts   |   13 +
 arch/arm/dts/sun50i-a64.dtsi  |   33 ++
 arch/arm/dts/sun8i-h3-orangepi-2.dts  |   13 +
 arch/arm/dts/sun8i-h3-orangepi-pc.dts |   12 +
 arch/arm/dts/sun8i-h3.dtsi|   25 +
 arch/arm/include/asm/arch-sunxi/clock_sun6i.h |4 +-
 arch/arm/include/asm/arch-sunxi/cpu_sun4i.h   |3 +-
 configs/orangepi_pc_defconfig |1 +
 configs/pine64_plus_defconfig |1 +
 drivers/net/Kconfig   |9 +
 drivers/net/Makefile  |1 +
 drivers/net/sun8i_emac.c  |  789 +
 12 files changed, 902 insertions(+), 2 deletions(-)
 create mode 100644 drivers/net/sun8i_emac.c

diff --git a/arch/arm/dts/sun50i-a64-pine64-plus.dts 
b/arch/arm/dts/sun50i-a64-pine64-plus.dts
index 549dc15..389c609 100644
--- a/arch/arm/dts/sun50i-a64-pine64-plus.dts
+++ b/arch/arm/dts/sun50i-a64-pine64-plus.dts
@@ -57,3 +57,16 @@
reg = <0x4000 0x4000>;
};
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   phy-mode = "rgmii";
+   phy = <>;
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
+
diff --git a/arch/arm/dts/sun50i-a64.dtsi b/arch/arm/dts/sun50i-a64.dtsi
index 1bd436f..7d0dc76 100644
--- a/arch/arm/dts/sun50i-a64.dtsi
+++ b/arch/arm/dts/sun50i-a64.dtsi
@@ -506,6 +506,25 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   rmii_pins: rmii_pins {
+   allwinner,pins = "PD10", "PD11", "PD13", "PD14",
+"PD17", "PD18", "PD19", "PD20",
+"PD22", "PD23";
+   allwinner,function = "emac";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   rgmii_pins: rgmii_pins {
+   allwinner,pins = "PD8", "PD9", "PD10", "PD11",
+"PD12", "PD13", "PD15",
+"PD16", "PD17", "PD18", "PD19",
+"PD20", "PD21", "PD22", "PD23";
+   allwinner,function = "emac";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
};

ahb_rst: reset@1c202c0 {
@@ -620,5 +639,19 @@
#address-cells = <1>;
#size-cells = <0>;
};
+
+   emac: ethernet@01c3 {
+   compatible = "allwinner,sun50i-a64-emac";
+   reg = <0x01c3 0x2000>, <0x01c00030 0x4>;
+   reg-names = "emac", "syscon";
+   interrupts = ;
+   resets = <_rst 17>;
+   reset-names = "ahb";
+   clocks = <_gates 17>;
+   clock-names = "ahb";
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
};
 };
diff --git a/arch/arm/dts/sun8i-h3-orangepi-2.dts 
b/arch/arm/dts/sun8i-h3-orangepi-2.dts
index f93f5d1..d3f8f55 100644
--- a/arch/arm/dts/sun8i-h3-orangepi-2.dts
+++ b/arch/arm/dts/sun8i-h3-orangepi-2.dts
@@ -184,3 +184,16 @@
usb1_vbus-supply = <_usb1_vbus>;
status = "okay";
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   phy-mode = "rgmii";
+   phy = <>;
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
+
diff --git a/arch/arm/dts/sun8i-h3-orangepi-pc.dts 
b/arch/arm/dts/sun8i-h3-orangepi-pc.dts
index 30ccca0..0a74a91 100644
--- a/arch/arm/dts/sun8i-h3-orangepi-pc.dts
+++ b/arch/arm/dts/sun8i-h3-orangepi-pc.dts
@@ -173,3 +173,15 @@
/* USB VBUS is always on */
status = "okay";
 };
+
+ {
+   phy = <>;
+   phy-mode = "mii";
+   allwinner,use-internal-phy;
+   allwinner,leds-active-low;
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
diff --git

[U-Boot] [PATCH 3/4] sunxi: Sync sun8i-h3-orangepi-plus.dts with upstream

2016-07-09 Thread Hans de Goede

This enables extra USB controllers which enable use of the 3th USB
port on the new Orange Pi Plus 2E variant.

Signed-off-by: Hans de Goede 
---
 arch/arm/dts/sun8i-h3-orangepi-plus.dts | 127 +++-
 arch/arm/dts/sun8i-h3.dtsi  |  10 +++
 2 files changed, 37 insertions(+), 100 deletions(-)

diff --git a/arch/arm/dts/sun8i-h3-orangepi-plus.dts 
b/arch/arm/dts/sun8i-h3-orangepi-plus.dts
index 900ec4f..28f74f6 100644
--- a/arch/arm/dts/sun8i-h3-orangepi-plus.dts
+++ b/arch/arm/dts/sun8i-h3-orangepi-plus.dts
@@ -40,26 +40,13 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
-/dts-v1/;
-#include "sun8i-h3.dtsi"
-#include "sunxi-common-regulators.dtsi"
-
-#include 
-#include 
-#include 
+/* The Orange Pi Plus is an extended version of the Orange Pi 2 */
+#include "sun8i-h3-orangepi-2.dts"
 
 / {
-   model = "Xunlong Orange Pi Plus";
+   model = "Xunlong Orange Pi Plus / Plus 2 / Plus 2E";
compatible = "xunlong,orangepi-plus", "allwinner,sun8i-h3";
 
-   aliases {
-   serial0 = 
-   };
-
-   chosen {
-   stdout-path = "serial0:115200n8";
-   };
-
reg_usb3_vbus: usb3-vbus {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -71,75 +58,42 @@
enable-active-high;
gpio = < 6 11 GPIO_ACTIVE_HIGH>;
};
+};
 
-   leds {
-   compatible = "gpio-leds";
-   pinctrl-names = "default";
-   pinctrl-0 = <_opc>;
-
-   status_led {
-   label = "status:red:user";
-   gpios = < 0 15 GPIO_ACTIVE_HIGH>;
-   };
-   };
-
-   r_leds {
-   compatible = "gpio-leds";
-   pinctrl-names = "default";
-   pinctrl-0 = <_r_opc>;
-
-   tx {
-   label = "pwr:green:user";
-   gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>;
-   default-state = "on";
-   };
-   };
-
-   r_gpio_keys {
-   compatible = "gpio-keys";
-   input-name = "sw4";
-
-   pinctrl-names = "default";
-   pinctrl-0 = <_r_opc>;
+ {
+   status = "okay";
+};
 
-   sw4@0 {
-   label = "sw4";
-   linux,code = ;
-   gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
-   };
-   };
+ {
+   status = "okay";
 };
 
- {
-   leds_opc: led_pins@0 {
-   allwinner,pins = "PA15";
-   allwinner,function = "gpio_out";
-   allwinner,drive = ;
-   allwinner,pull = ;
-   };
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_8bit_pins>;
+   vmmc-supply = <_vcc3v3>;
+   bus-width = <8>;
+   non-removable;
+   cap-mmc-hw-reset;
+   status = "okay";
 };
 
-_pio {
-   leds_r_opc: led_pins@0 {
-   allwinner,pins = "PL10";
-   allwinner,function = "gpio_out";
-   allwinner,drive = ;
-   allwinner,pull = ;
-   };
+_8bit_pins {
+   /* Increase drive strength for DDR modes */
+   allwinner,drive = ;
+   /* eMMC is missing pull-ups */
+   allwinner,pull = ;
+};
 
-   sw_r_opc: key_pins@0 {
-   allwinner,pins = "PL03";
-   allwinner,function = "gpio_in";
-   allwinner,drive = ;
-   allwinner,pull = ;
-   };
+ {
+   status = "okay";
 };
 
- {
+ {
status = "okay";
 };
 
- {
+ {
status = "okay";
 };
 
@@ -152,33 +106,6 @@
};
 };
 
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>, <_cd_pin>;
-   vmmc-supply = <_vcc3v3>;
-   bus-width = <4>;
-   cd-gpios = < 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
-   cd-inverted;
-   status = "okay";
-};
-
-_usb1_vbus {
-   gpio = < 6 13 GPIO_ACTIVE_HIGH>;
-   status = "okay";
-};
-
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins_a>;
-   status = "okay";
-};
-
-_vbus_pin_a {
-   allwinner,pins = "PG13";
-};
-
  {
-   usb1_vbus-supply = <_usb1_vbus>;
usb3_vbus-supply = <_usb3_vbus>;
-   status = "okay";
 };
diff --git a/arch/arm/dts/sun8i-h3.dtsi b/arch/arm/dts/sun8i-h3.dtsi
index c2f63c5..4a4926b 100644
--- a/arch/arm/dts/sun8i-h3.dtsi
+++ b/arch/arm/dts/sun8i-h3.dtsi
@@ -530,6 +530,16 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   mmc2_8bit_pins: mmc2_8bit {
+   allwinner,pins = "PC5", "PC6", "PC8",
+"PC9", "PC10", "PC11",
+"PC12", "PC13", "PC14",
+"PC15", "PC16";
+   allwinner,function = "mmc2";
+

[U-Boot] [PATCH 4/4] sunxi: Add defconfig and dts file for the Orange Pi Lite SBC

2016-07-09 Thread Hans de Goede

The Orange Pi Lite SBC is a small H3 based SBC, with 512MB RAM,
micro-sd slot, HDMI out, 2 USB-A connectors, 1 micro-USB connector,
sdio attached rtl8189ftv wifi and an ir receiver.

The dts file is identical to the one submitted to the upstream kernel.

Signed-off-by: Hans de Goede 
---
 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/sun8i-h3-orangepi-lite.dts | 178 
 board/sunxi/MAINTAINERS |   1 +
 configs/orangepi_lite_defconfig |  15 +++
 4 files changed, 195 insertions(+)
 create mode 100644 arch/arm/dts/sun8i-h3-orangepi-lite.dts
 create mode 100644 configs/orangepi_lite_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ef573ec..acecb7c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -242,6 +242,7 @@ dtb-$(CONFIG_MACH_SUN8I_A83T) += \
sun8i-a83t-sinovoip-bpi-m3.dtb
 dtb-$(CONFIG_MACH_SUN8I_H3) += \
sun8i-h3-orangepi-2.dtb \
+   sun8i-h3-orangepi-lite.dtb \
sun8i-h3-orangepi-one.dtb \
sun8i-h3-orangepi-pc.dtb \
sun8i-h3-orangepi-plus.dtb
diff --git a/arch/arm/dts/sun8i-h3-orangepi-lite.dts 
b/arch/arm/dts/sun8i-h3-orangepi-lite.dts
new file mode 100644
index 000..ac71749
--- /dev/null
+++ b/arch/arm/dts/sun8i-h3-orangepi-lite.dts
@@ -0,0 +1,178 @@
+/*
+ * Copyright (C) 2016 Hans de Goede 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "Xunlong Orange Pi Lite";
+   compatible = "xunlong,orangepi-lite", "allwinner,sun8i-h3";
+
+   aliases {
+   /* The H3 emac is not used so the wifi is ethernet0 */
+   ethernet1 = 
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_opc>, <_r_opc>;
+
+   pwr_led {
+   label = "orangepi:green:pwr";
+   gpios = <_pio 0 10 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+
+   status_led {
+   label = "orangepi:red:status";
+   gpios = < 0 15 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   r_gpio_keys {
+   compatible = "gpio-keys";
+   pinctrl-names = "default";
+   pinctrl-0 = <_r_opc>;
+
+   sw4 {
+   label = "sw4";
+   linux,code = ;
+   gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>, <_cd_pin>;
+

[U-Boot] [PATCH 2/4] sunxi: orangepi_pc: Add support for eMMC found on the Orange Pi PC Plus

2016-07-09 Thread Hans de Goede

The Plus variant of the Orange Pi PC has an eMMC, add support for this.

Note we are using the same u-boot defconfig / dts for both the regular
Orange Pi PC as well as the Orange Pi PC Plus.

Signed-off-by: Hans de Goede 
---
 configs/orangepi_pc_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/orangepi_pc_defconfig b/configs/orangepi_pc_defconfig
index 7eaa795..9d5e521 100644
--- a/configs/orangepi_pc_defconfig
+++ b/configs/orangepi_pc_defconfig
@@ -4,6 +4,8 @@ CONFIG_MACH_SUN8I_H3=y
 CONFIG_DRAM_CLK=624
 CONFIG_DRAM_ZQ=3881979
 CONFIG_DRAM_ODT_EN=y
+CONFIG_MMC0_CD_PIN="PF6"
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
 # CONFIG_VIDEO is not set
 CONFIG_DEFAULT_DEVICE_TREE="sun8i-h3-orangepi-pc"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
-- 
2.7.4

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

[U-Boot] [PATCH 1/4] sunxi: Use BROM stored boot_media value to determine our boot-source

2016-07-09 Thread Hans de Goede

Now that we know that the BROM stores a value indicating the boot-source
at the beginning of SRAM, use that instead of trying to recreate the
BROM's boot probing.

Signed-off-by: Hans de Goede 
---
 arch/arm/include/asm/arch-sunxi/mmc.h |  1 -
 arch/arm/mach-sunxi/board.c   | 34 +++---
 board/sunxi/board.c   |  3 +--
 drivers/mmc/sunxi_mmc.c   | 17 -
 4 files changed, 12 insertions(+), 43 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h 
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 3da360b..cb52e64 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -127,5 +127,4 @@ struct sunxi_mmc {
 #define SUNXI_MMC_COMMON_RESET (1 << 18)
 
 struct mmc *sunxi_mmc_init(int sdc_no);
-int sunxi_mmc_has_egon_boot_signature(struct mmc *mmc);
 #endif /* _SUNXI_MMC_H */
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 3f5116b..06a1986 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -203,7 +203,8 @@ DECLARE_GLOBAL_DATA_PTR;
  */
 u32 spl_boot_device(void)
 {
-   __maybe_unused struct mmc *mmc0, *mmc1;
+   int boot_source;
+
/*
 * When booting from the SD card or NAND memory, the "eGON.BT0"
 * signature is expected to be found in memory at the address 0x0004
@@ -223,32 +224,19 @@ u32 spl_boot_device(void)
if (!is_boot0_magic(SPL_ADDR + 4)) /* eGON.BT0 */
return BOOT_DEVICE_BOARD;
 
-#ifdef CONFIG_SPL_SPI_SUNXI
-   if (readb(SPL_ADDR + 0x28) == SUNXI_BOOTED_FROM_SPI)
-   return BOOT_DEVICE_SPI;
-#endif
-
-   /* The BROM will try to boot from mmc0 first, so try that first. */
-#ifdef CONFIG_MMC
-   mmc_initialize(gd->bd);
-   mmc0 = find_mmc_device(0);
-   if (sunxi_mmc_has_egon_boot_signature(mmc0))
+   boot_source = readb(SPL_ADDR + 0x28);
+   switch (boot_source) {
+   case SUNXI_BOOTED_FROM_MMC0:
return BOOT_DEVICE_MMC1;
-#endif
-
-   /* Fallback to booting NAND if enabled. */
-   if (IS_ENABLED(CONFIG_SPL_NAND_SUPPORT))
+   case SUNXI_BOOTED_FROM_NAND:
return BOOT_DEVICE_NAND;
-
-#ifdef CONFIG_MMC
-   if (CONFIG_MMC_SUNXI_SLOT_EXTRA == 2) {
-   mmc1 = find_mmc_device(1);
-   if (sunxi_mmc_has_egon_boot_signature(mmc1))
-   return BOOT_DEVICE_MMC2;
+   case SUNXI_BOOTED_FROM_MMC2:
+   return BOOT_DEVICE_MMC2;
+   case SUNXI_BOOTED_FROM_SPI:
+   return BOOT_DEVICE_SPI;
}
-#endif
 
-   panic("Could not determine boot source\n");
+   panic("Unknown boot source %d\n", boot_source);
return -1;  /* Never reached */
 }
 
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 9767310..840f01d 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -369,8 +369,7 @@ int board_mmc_init(bd_t *bis)
 * are searched there first. Note we only do this for u-boot proper,
 * not for the SPL, see spl_boot_device().
 */
-   if (!sunxi_mmc_has_egon_boot_signature(mmc0) &&
-   sunxi_mmc_has_egon_boot_signature(mmc1)) {
+   if (readb(SPL_ADDR + 0x28) == SUNXI_BOOTED_FROM_MMC2) {
/* Booting from emmc / mmc2, swap */
mmc0->block_dev.devnum = 1;
mmc1->block_dev.devnum = 0;
diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 3be9a90..5d8abdc 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -445,23 +445,6 @@ static int sunxi_mmc_getcd(struct mmc *mmc)
return !gpio_get_value(cd_pin);
 }
 
-int sunxi_mmc_has_egon_boot_signature(struct mmc *mmc)
-{
-   char *buf = malloc(512);
-   int valid_signature = 0;
-
-   if (buf == NULL)
-   panic("Failed to allocate memory\n");
-
-   if (mmc_getcd(mmc) && mmc_init(mmc) == 0 &&
-   mmc->block_dev.block_read(>block_dev, 16, 1, buf) == 1 &&
-   strncmp([4], "eGON.BT0", 8) == 0)
-   valid_signature = 1;
-
-   free(buf);
-   return valid_signature;
-}
-
 static const struct mmc_ops sunxi_mmc_ops = {
.send_cmd   = sunxi_mmc_send_cmd,
.set_ios= sunxi_mmc_set_ios,
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2] SPL: tiny-printf: avoid any BSS usage

2016-07-09 Thread André Przywara

On 09/07/16 15:38, Simon Glass wrote:
> On 8 July 2016 at 08:18, Andre Przywara  wrote:
>> As printf calls may be executed quite early, we should avoid using any
>> BSS stored variables, since some boards put BSS in DRAM, which may not
>> have been initialised yet.
>> Explicitly mark those "static global" variables as belonging to the
>> .data section, to keep tiny-printf clear of any BSS usage.
>>
>> Signed-off-by: Andre Przywara 
> 
> Reviewed-by: Simon Glass 
> 
> Another approach would be to put these vars in a struct, declare it as
> a local variable and pass it around. But this works OK too.

Yeah, I was thinking about this too. Actually fixing the issue that we
need global variables in the first place.
But a quick look revealed that this is not trivial, so I reverted to
this simpler approach for the quick fix. Also I am not sure this will
eventually work against this "tiny" idea, we will see.

To be honest I think the real proper fix(TM) would be to provide a
separate BSS section for any code that runs _before_ DRAM init. This
should be a few bytes only and could easily live in SRAM.
If the loading part of the SPL requires a bigger BSS, that's fine as it
could still live in DRAM.
I might bake a patch when I get bored ...

Cheers,
Andre.


> 
>> ---
>> Changes v1 .. v2:
>> - remove NO_BSS macro, use __attribute__ ... directly instead
>>
>>  lib/tiny-printf.c | 11 ---
>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
>> index 451f4f7..b334f05 100644
>> --- a/lib/tiny-printf.c
>> +++ b/lib/tiny-printf.c
>> @@ -13,11 +13,16 @@
>>  #include 
>>  #include 
>>
>> -static char *bf;
>> -static char zs;
>> +/*
>> + * This code in here may execute before the DRAM is initialised, so
>> + * we should make sure that it doesn't touch BSS, which some boards
>> + * put in DRAM.
>> + */
>> +static char *bf __attribute__ ((section(".data")));
>> +static char zs __attribute__ ((section(".data")));
>>
>>  /* Current position in sprintf() output string */
>> -static char *outstr;
>> +static char *outstr __attribute__ ((section(".data")));
>>
>>  static void out(char c)
>>  {
>> --
>> 2.8.2
>>
> 

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

[U-Boot] [PATCH] git-mailrc: add rockchip alias

2016-07-09 Thread jk

It's easier to Cc rockchip maintainers on rockchip-releated patches.

Signed-off-by: jk 
---
 doc/git-mailrc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/git-mailrc b/doc/git-mailrc
index 1d6f4fc..8f0724f 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -76,7 +76,7 @@ alias tegra2 tegra
 alias ti uboot, trini
 alias uniphier   uboot, masahiro
 alias zynq   uboot, monstr
-
+alias rockchip   uboot, sjg, Lin huang 
 alias avr32  uboot, abiessmann
 
 alias bfin   uboot, vapier, sonic
-- 
1.9.1

___
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

2016-07-09 Thread Tom Rini

On Sat, Jul 09, 2016 at 09:00:16PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please take this series.

We are about 2 days from release.  None of these changes are clearly 
critical for release bug fixes.  I will pick this up after the release,
thanks.

> 
> thanks!
> Jagan.
> 
> The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0:
> 
>   Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-spi.git master
> 
> for you to fetch changes up to 96907c0fe50a856f66f60ade68864a2d7949bf15:
> 
>   dm: spi: Read default speed and mode values from DT (2016-07-09 20:16:34 
> +0530)
> 
> 
> Anatolij Gustschin (1):
>   spi: spi-uclass: fix typo in debug output
> 
> Vignesh R (18):
>   dm: core: implement dev_map_physmem()
>   spi: davinci_spi: Convert to driver to adapt to DM
>   keystone2: spi: do not define DM_SPI and DM_SPI_FLASH for SPL build
>   ARM: dts: keystone2: add SPI aliases for davinci SPI nodes
>   ARM: dts: k2hk: Enable Davinci SPI controller
>   defconfig: k2hk_evm_defconfig: enable SPI driver model
>   ARM: dts: k2e: Enable Davinci SPI controller
>   defconfig: k2e_evm_defconfig: enable SPI driver model
>   ARM: dts: k2l: Enable Davinci SPI controller
>   defconfig: k2l_evm_defconfig: enable SPI driver model
>   ARM: dts: k2g: add support for Davinci SPI controller
>   defconfig: k2g_evm_defconfig: enable SPI driver model
>   spi: cadence_qspi_apb: Support 32 bit AHB address
>   spi: cadence_quadspi: Enable QUAD mode based on DT data
>   ARM: dts: K2G: Add support for QSPI controller
>   defconfig: k2g_evm_defconfig: Enable Cadence QSPI controller
>   ARM: dts: dra7x: Support QSPI MODE-0 operation at 64MHz
>   dm: spi: Read default speed and mode values from DT
> 
>  arch/arm/dts/dra7-evm.dts|   6 +-
>  arch/arm/dts/dra72-evm.dts   |   6 +-
>  arch/arm/dts/k2e-evm.dts |   3 +-
>  arch/arm/dts/k2g-evm.dts |  69 
>  arch/arm/dts/k2g.dtsi|  61 +++
>  arch/arm/dts/k2hk-evm.dts|   3 +-
>  arch/arm/dts/k2l-evm.dts |   3 +-
>  arch/arm/dts/keystone.dtsi   |   3 +
>  cmd/sf.c |   2 +
>  common/env_sf.c  |   8 +-
>  configs/k2e_evm_defconfig|   2 +
>  configs/k2g_evm_defconfig|   4 +
>  configs/k2hk_evm_defconfig   |   2 +
>  configs/k2l_evm_defconfig|   2 +
>  drivers/core/device.c|  11 ++
>  drivers/spi/cadence_qspi.c   |   3 +-
>  drivers/spi/cadence_qspi.h   |   2 +-
>  drivers/spi/cadence_qspi_apb.c   |  15 +-
>  drivers/spi/davinci_spi.c| 329 
> +--
>  drivers/spi/spi-uclass.c |  10 +-
>  include/configs/k2g_evm.h|   6 +
>  include/configs/ti_armv7_keystone2.h |   4 +
>  include/dm/device.h  |  13 ++
>  23 files changed, 450 insertions(+), 117 deletions(-)

-- 
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] mmc: sdhci: clean up timeout detection

2016-07-09 Thread Masahiro Yamada

The current timeout detection logic is not very nice; it calls
get_timer(start) in the while() loop, and then calls it again after
the loop to check if a timeout error happened.

Because of the time difference between the two calls of get_timer(),
the timeout detected after the loop may not be true.

Signed-off-by: Masahiro Yamada 
Acked-by: Jaehoon Chung 
---

Changes in v2:
  - Fix a typo :  get_time() -> get_timer() in git-log

 drivers/mmc/sdhci.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 604f18d..0a1882d 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -243,17 +243,17 @@ static int sdhci_send_command(struct mmc *mmc, struct 
mmc_cmd *cmd,
stat = sdhci_readl(host, SDHCI_INT_STATUS);
if (stat & SDHCI_INT_ERROR)
break;
-   } while (((stat & mask) != mask) &&
-(get_timer(start) < SDHCI_READ_STATUS_TIMEOUT));
 
-   if (get_timer(start) >= SDHCI_READ_STATUS_TIMEOUT) {
-   if (host->quirks & SDHCI_QUIRK_BROKEN_R1B)
-   return 0;
-   else {
-   printf("%s: Timeout for status update!\n", __func__);
-   return TIMEOUT;
+   if (get_timer(start) >= SDHCI_READ_STATUS_TIMEOUT) {
+   if (host->quirks & SDHCI_QUIRK_BROKEN_R1B) {
+   return 0;
+   } else {
+   printf("%s: Timeout for status update!\n",
+  __func__);
+   return TIMEOUT;
+   }
}
-   }
+   } while ((stat & mask) != mask);
 
if ((stat & (SDHCI_INT_ERROR | mask)) == mask) {
sdhci_cmd_done(host, cmd);
-- 
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] include: usb: Rename USB controller base address mapping

2016-07-09 Thread Rajesh Bhagat



> -Original Message-
> From: york sun
> Sent: Monday, June 27, 2016 8:58 PM
> To: Rajesh Bhagat ; u-boot@lists.denx.de
> Cc: qianyu.g...@freescale.com; mingkai...@freescale.com;
> prabha...@freescale.com
> Subject: Re: [PATCH v2] include: usb: Rename USB controller base address 
> mapping
> 
> On 06/16/2016 08:58 PM, Rajesh Bhagat wrote:
> >
> >
> >> -Original Message-
> >> From: york sun
> >> Sent: Friday, June 17, 2016 9:07 AM
> >> To: Rajesh Bhagat ; u-boot@lists.denx.de
> >> Cc: qianyu.g...@freescale.com; mingkai...@freescale.com;
> >> prabha...@freescale.com
> >> Subject: Re: [PATCH v2] include: usb: Rename USB controller base
> >> address mapping
> >>
> >> On 06/16/2016 08:28 PM, Rajesh Bhagat wrote:
> >>>
> >>>
>  -Original Message-
>  From: york sun
>  Sent: Thursday, June 16, 2016 9:13 PM
>  To: Rajesh Bhagat ; u-boot@lists.denx.de
>  Cc: qianyu.g...@freescale.com; mingkai...@freescale.com;
>  prabha...@freescale.com
>  Subject: Re: [PATCH v2] include: usb: Rename USB controller base
>  address mapping
> 
>  On 06/07/2016 06:29 AM, Rajesh Bhagat wrote:
> > Remove Soc specific defines and use generic chasis specific
> > defines for USB controller base address mapping.
> >
> > Signed-off-by: Rajesh Bhagat 
> > ---
> > Changes in v2:
> > - Rebased patch for latest u-boot
> 
> 
>  
> 
> > diff --git a/include/linux/usb/xhci-fsl.h
> > b/include/linux/usb/xhci-fsl.h index 253eddf..199f366 100644
> > --- a/include/linux/usb/xhci-fsl.h
> > +++ b/include/linux/usb/xhci-fsl.h
> > @@ -51,22 +51,18 @@ struct fsl_xhci {
> > struct dwc3 *dwc3_reg;
> > };
> >
> > -#if defined(CONFIG_LS102XA)
> > -#define CONFIG_SYS_FSL_XHCI_USB1_ADDR
> > CONFIG_SYS_LS102XA_XHCI_USB1_ADDR
> > +#if defined(CONFIG_LS102XA) || defined(CONFIG_LS1012A) #define
> > +CONFIG_SYS_FSL_XHCI_USB1_ADDR CONFIG_SYS_XHCI_USB1_ADDR
> > #define CONFIG_SYS_FSL_XHCI_USB2_ADDR 0
> > #define CONFIG_SYS_FSL_XHCI_USB3_ADDR 0
> > #elif defined(CONFIG_LS2080A)
> > -#define CONFIG_SYS_FSL_XHCI_USB1_ADDR
> > CONFIG_SYS_LS2080A_XHCI_USB1_ADDR -#define
> > CONFIG_SYS_FSL_XHCI_USB2_ADDR
> >> CONFIG_SYS_LS2080A_XHCI_USB2_ADDR
> > -#define CONFIG_SYS_FSL_XHCI_USB3_ADDR 0 -#elif
> > defined(CONFIG_LS1043A) || defined(CONFIG_LS1012A) -#define
> > CONFIG_SYS_FSL_XHCI_USB1_ADDR
> >> CONFIG_SYS_LS1043A_XHCI_USB1_ADDR
> > -#define CONFIG_SYS_FSL_XHCI_USB2_ADDR
> > CONFIG_SYS_LS1043A_XHCI_USB2_ADDR -#define
> > CONFIG_SYS_FSL_XHCI_USB3_ADDR
> >> CONFIG_SYS_LS1043A_XHCI_USB3_ADDR -
>  #elif
> > defined(CONFIG_LS1012A) -#define CONFIG_SYS_FSL_XHCI_USB1_ADDR
> > CONFIG_SYS_LS1043A_XHCI_USB1_ADDR -#define
> > CONFIG_SYS_FSL_XHCI_USB2_ADDR 0
> > +#define CONFIG_SYS_FSL_XHCI_USB1_ADDR
> >> CONFIG_SYS_XHCI_USB1_ADDR
> > +#define CONFIG_SYS_FSL_XHCI_USB2_ADDR
> >> CONFIG_SYS_XHCI_USB2_ADDR
> > #define CONFIG_SYS_FSL_XHCI_USB3_ADDR 0
> > +#elif defined(CONFIG_LS1043A)
> > +#define CONFIG_SYS_FSL_XHCI_USB1_ADDR
> >> CONFIG_SYS_XHCI_USB1_ADDR
> > +#define CONFIG_SYS_FSL_XHCI_USB2_ADDR
> >> CONFIG_SYS_XHCI_USB2_ADDR
> > +#define CONFIG_SYS_FSL_XHCI_USB3_ADDR
> >> CONFIG_SYS_XHCI_USB3_ADDR
> > #endif
> >>>
> >>> Hello York,
> >>>
> 
>  Do you plan to consolidate the above section?
> 
> >>>
> >>> Do you mean making the macro defines common as below?
> >>>
> >>> #define CONFIG_SYS_FSL_XHCI_USB1_ADDR 0 #define
> >>> CONFIG_SYS_FSL_XHCI_USB2_ADDR 0 #define
> >> CONFIG_SYS_FSL_XHCI_USB3_ADDR
> >>> 0
> >>>
> >>> #if defined(CONFIG_LS102XA) || defined(CONFIG_LS1012A) ||
> >> defined(CONFIG_LS2080A)
> >>>   || defined(CONFIG_LS2085A) || defined(CONFIG_LS1043A) #undef
> >>> CONFIG_SYS_FSL_XHCI_USB1_ADDR #define
> >> CONFIG_SYS_FSL_XHCI_USB1_ADDR
> >>> CONFIG_SYS_XHCI_USB1_ADDR #endif
> >>>
> >>> #if defined(CONFIG_LS2080A) || defined(CONFIG_LS2085A) ||
> >>> defined(CONFIG_LS1043A) #undef CONFIG_SYS_FSL_XHCI_USB2_ADDR
> #define
> >>> CONFIG_SYS_FSL_XHCI_USB2_ADDR CONFIG_SYS_XHCI_USB2_ADDR #endif
> >>>
> >>> #if defined(CONFIG_LS1043A)
> >>> #undef CONFIG_SYS_FSL_XHCI_USB3_ADDR #define
> >>> CONFIG_SYS_FSL_XHCI_USB3_ADDR CONFIG_SYS_XHCI_USB3_ADDR
> >> #endif
> >>>
> >
> > Hello York,
> >
> >>
> >> No. I mean to replace this section as
> >>
> >> #ifndef CONFIG_SYS_FSL_XHCI_USB1_ADDR #define
> >> CONFIG_SYS_FSL_XHCI_USB1_ADDR 0 #endif #ifndef
> >> CONFIG_SYS_FSL_XHCI_USB2_ADD #define CONFIG_SYS_FSL_XHCI_USB2_ADD
> 0
> >> #endif #ifndef CONFIG_SYS_FSL_XHCI_USB3_ADD #define
> >> CONFIG_SYS_FSL_XHCI_USB3_ADD 0 #endif
> >>
> >> Then you don't need to check SoC macros at all.
> >>
> >
> > Actually, we are trying to re-use macros defined in chasis specific
> > files for other platform of same chasis i.e.

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

2016-07-09 Thread Jagan Teki

Hi Tom,

Please take this series.

thanks!
Jagan.

The following changes since commit e8009beff6d5c55c1bf1ae8184791f167e6378b0:

  Merge git://git.denx.de/u-boot-arc (2016-07-04 11:46:21 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-spi.git master

for you to fetch changes up to 96907c0fe50a856f66f60ade68864a2d7949bf15:

  dm: spi: Read default speed and mode values from DT (2016-07-09 20:16:34 
+0530)


Anatolij Gustschin (1):
  spi: spi-uclass: fix typo in debug output

Vignesh R (18):
  dm: core: implement dev_map_physmem()
  spi: davinci_spi: Convert to driver to adapt to DM
  keystone2: spi: do not define DM_SPI and DM_SPI_FLASH for SPL build
  ARM: dts: keystone2: add SPI aliases for davinci SPI nodes
  ARM: dts: k2hk: Enable Davinci SPI controller
  defconfig: k2hk_evm_defconfig: enable SPI driver model
  ARM: dts: k2e: Enable Davinci SPI controller
  defconfig: k2e_evm_defconfig: enable SPI driver model
  ARM: dts: k2l: Enable Davinci SPI controller
  defconfig: k2l_evm_defconfig: enable SPI driver model
  ARM: dts: k2g: add support for Davinci SPI controller
  defconfig: k2g_evm_defconfig: enable SPI driver model
  spi: cadence_qspi_apb: Support 32 bit AHB address
  spi: cadence_quadspi: Enable QUAD mode based on DT data
  ARM: dts: K2G: Add support for QSPI controller
  defconfig: k2g_evm_defconfig: Enable Cadence QSPI controller
  ARM: dts: dra7x: Support QSPI MODE-0 operation at 64MHz
  dm: spi: Read default speed and mode values from DT

 arch/arm/dts/dra7-evm.dts|   6 +-
 arch/arm/dts/dra72-evm.dts   |   6 +-
 arch/arm/dts/k2e-evm.dts |   3 +-
 arch/arm/dts/k2g-evm.dts |  69 
 arch/arm/dts/k2g.dtsi|  61 +++
 arch/arm/dts/k2hk-evm.dts|   3 +-
 arch/arm/dts/k2l-evm.dts |   3 +-
 arch/arm/dts/keystone.dtsi   |   3 +
 cmd/sf.c |   2 +
 common/env_sf.c  |   8 +-
 configs/k2e_evm_defconfig|   2 +
 configs/k2g_evm_defconfig|   4 +
 configs/k2hk_evm_defconfig   |   2 +
 configs/k2l_evm_defconfig|   2 +
 drivers/core/device.c|  11 ++
 drivers/spi/cadence_qspi.c   |   3 +-
 drivers/spi/cadence_qspi.h   |   2 +-
 drivers/spi/cadence_qspi_apb.c   |  15 +-
 drivers/spi/davinci_spi.c| 329 +--
 drivers/spi/spi-uclass.c |  10 +-
 include/configs/k2g_evm.h|   6 +
 include/configs/ti_armv7_keystone2.h |   4 +
 include/dm/device.h  |  13 ++
 23 files changed, 450 insertions(+), 117 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] SPL: tiny-printf: avoid any BSS usage

2016-07-09 Thread Marek Vasut


On 07/09/2016 04:38 PM, Simon Glass wrote:

On 8 July 2016 at 08:18, Andre Przywara  wrote:

As printf calls may be executed quite early, we should avoid using any
BSS stored variables, since some boards put BSS in DRAM, which may not
have been initialised yet.
Explicitly mark those "static global" variables as belonging to the
.data section, to keep tiny-printf clear of any BSS usage.

Signed-off-by: Andre Przywara 


Reviewed-by: Simon Glass 

Another approach would be to put these vars in a struct, declare it as
a local variable and pass it around. But this works OK too.


This might in fact be even better.


---
Changes v1 .. v2:
- remove NO_BSS macro, use __attribute__ ... directly instead

 lib/tiny-printf.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
index 451f4f7..b334f05 100644
--- a/lib/tiny-printf.c
+++ b/lib/tiny-printf.c
@@ -13,11 +13,16 @@
 #include 
 #include 

-static char *bf;
-static char zs;
+/*
+ * This code in here may execute before the DRAM is initialised, so
+ * we should make sure that it doesn't touch BSS, which some boards
+ * put in DRAM.
+ */
+static char *bf __attribute__ ((section(".data")));
+static char zs __attribute__ ((section(".data")));

 /* Current position in sprintf() output string */
-static char *outstr;
+static char *outstr __attribute__ ((section(".data")));

 static void out(char c)
 {
--
2.8.2




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

Re: [U-Boot] [RESEND PATCH v5 01/12] dm: core: implement dev_map_phsymem()

2016-07-09 Thread Jagan Teki

On 7 July 2016 at 04:49, Simon Glass  wrote:
> Hi,
>
> On 5 July 2016 at 22:28, Vignesh R  wrote:
>> This API helps to map physical register addresss pace of device to
>> virtual address space easily. Its just a wrapper around map_physmem()
>> with MAP_NOCACHE flag.
>>
>
> nit: dev_map_physmem() in the subject

Thanks for the nit Simon, updated the same!

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

Re: [U-Boot] [U-Boot,v2] SPL: tiny-printf: avoid any BSS usage

2016-07-09 Thread Tom Rini

On Sat, Jul 09, 2016 at 10:22:37AM +0200, Marek Vasut wrote:
> On 07/09/2016 02:28 AM, Tom Rini wrote:
> >On Fri, Jul 08, 2016 at 11:48:12PM +0200, Marek Vasut wrote:
> >>On 07/08/2016 06:50 PM, Tom Rini wrote:
> >>>On Fri, Jul 08, 2016 at 03:18:35PM +0100, Andre Przywara wrote:
> >>>
> As printf calls may be executed quite early, we should avoid using any
> BSS stored variables, since some boards put BSS in DRAM, which may not
> have been initialised yet.
> Explicitly mark those "static global" variables as belonging to the
> .data section, to keep tiny-printf clear of any BSS usage.
> 
> Signed-off-by: Andre Przywara 
> >>>
> >>>Applied to u-boot/master, thanks!
> >>>
> >>Mind you, __section(".data") would be enough, no need to spell the
> >>whole attribute.
> >
> >True, but that's a helper that's not really utilized today.
> >
> That's something that should likely be changed, as it allows to
> seamlessly deal with compiler quirks (if some were to ever pop up in
> this area).

Patches welcome for the next release ;)

-- 
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: move all the rockchip board in one folder

2016-07-09 Thread Simon Glass

On 7 July 2016 at 21:53, Ziyuan Xu  wrote:
>
>
> On 2016年07月08日 11:30, Kever Yang wrote:
>>
>> The 'evb_rk3036' and 'kylin' is not a vendor name, let's replace them
>> to 'rockchip' which is a real _vendor_ name, and meet the architecure
>> 'board///'.
>>
>> More boards from rockchip like evb_rk3288, evb_rk3399 will comes later.
>>
>> Signed-off-by: Kever Yang 
>> ---
>>   arch/arm/mach-rockchip/rk3036/Kconfig  |  4 +-
>>   board/evb_rk3036/evb_rk3036/Kconfig| 15 --
>>   board/evb_rk3036/evb_rk3036/MAINTAINERS|  0
>>   board/evb_rk3036/evb_rk3036/Makefile   |  7 ---
>>   board/evb_rk3036/evb_rk3036/evb_rk3036.c   | 49 --
>>   board/kylin/kylin_rk3036/Kconfig   | 15 --
>>   board/kylin/kylin_rk3036/MAINTAINERS   |  0
>>   board/kylin/kylin_rk3036/Makefile  |  7 ---
>>   board/kylin/kylin_rk3036/kylin_rk3036.c| 81
>> --
>>   board/rockchip/evb_rk3036/Kconfig  | 15 ++
>>   board/rockchip/evb_rk3036/MAINTAINERS  |  0
>>   board/rockchip/evb_rk3036/Makefile |  7 +++
>>   board/rockchip/evb_rk3036/evb_rk3036.c | 49 ++
>>   board/rockchip/kylin_rk3036/Kconfig| 15 ++
>>   board/rockchip/kylin_rk3036/MAINTAINERS|  0
>>   board/rockchip/kylin_rk3036/Makefile   |  7 +++
>>   board/rockchip/kylin_rk3036/kylin_rk3036.c | 81
>> ++
>>   17 files changed, 176 insertions(+), 176 deletions(-)
>>   delete mode 100644 board/evb_rk3036/evb_rk3036/Kconfig
>>   delete mode 100644 board/evb_rk3036/evb_rk3036/MAINTAINERS
>>   delete mode 100644 board/evb_rk3036/evb_rk3036/Makefile
>>   delete mode 100644 board/evb_rk3036/evb_rk3036/evb_rk3036.c
>>   delete mode 100644 board/kylin/kylin_rk3036/Kconfig
>>   delete mode 100644 board/kylin/kylin_rk3036/MAINTAINERS
>>   delete mode 100644 board/kylin/kylin_rk3036/Makefile
>>   delete mode 100644 board/kylin/kylin_rk3036/kylin_rk3036.c
>>   create mode 100644 board/rockchip/evb_rk3036/Kconfig
>>   create mode 100644 board/rockchip/evb_rk3036/MAINTAINERS
>>   create mode 100644 board/rockchip/evb_rk3036/Makefile
>>   create mode 100644 board/rockchip/evb_rk3036/evb_rk3036.c
>>   create mode 100644 board/rockchip/kylin_rk3036/Kconfig
>>   create mode 100644 board/rockchip/kylin_rk3036/MAINTAINERS
>>   create mode 100644 board/rockchip/kylin_rk3036/Makefile
>>   create mode 100644 board/rockchip/kylin_rk3036/kylin_rk3036.c
>>
[snip]
>> diff --git a/board/rockchip/evb_rk3036/MAINTAINERS
>> b/board/rockchip/evb_rk3036/MAINTAINERS
>> new file mode 100644
>
> Also merge Simon's commit https://patchwork.ozlabs.org/patch/634321/  ?
>

Better as a separate patch I think. I can apply them in the right
order / fix things up.

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

Re: [U-Boot] [PATCH 2/4] tools/env: javadoc for fw_printenv, fw_getenv and fw_parse_script

2016-07-09 Thread Simon Glass

On 27 June 2016 at 16:06, Andreas Fenkart
 wrote:
> there are two groups of functions:
> - application ready tools: fw_setenv/fw_getenv/fw_parse_script
> these are used, when creating a single binary containing multiple
> tools (busybox like)
> - file access like: open/read/write/close
> above functions are implemented on top of these. applications
> can use those to modify several variables without creating a
> temporary batch script file
>
> Signed-off-by: Andreas Fenkart 
> ---
>  tools/env/fw_env.h | 75 
> +-
>  1 file changed, 74 insertions(+), 1 deletion(-)

Great to see this, thank you.

Reviewed-by: Simon Glass 

Nit below

>
> diff --git a/tools/env/fw_env.h b/tools/env/fw_env.h
> index dac964d..8bf74f3 100644
> --- a/tools/env/fw_env.h
> +++ b/tools/env/fw_env.h
> @@ -67,12 +67,85 @@ struct env_opts {
>
>  int parse_aes_key(char *key, uint8_t *bin_key);
>
> +/**
> + * fw_printenv - print one or several environment variables

We normally add function brackets:

   fw_printenv() - print ...

> + *
> + * @argc  number of variables names to be printed, print all if 0
> + * @argv  array of variable names to be printed
> + * @value_only  do not repeat the variable name, only print the value,
> + *  only one variable allowed with this option, argc must be 1
> + * @opts  encryption key, configuration file, defaults are used if NULL

@returns

> + */
>  int fw_printenv(int argc, char *argv[], int value_only, struct env_opts 
> *opts);
> -char *fw_getenv(char *name);
> +
> +/**
> + * fw_setenv - adds or removes one variable from the environment
> + *
> + * @argc  number of strings in argv, argv[0] is variable name,
> + *  argc==1 means erase variable, argc > 1 means add a variable
> + * @argv  argv[0] is variable name, argv[1..argc-1] are concatenated 
> separated
> + *   by single blank and set as the new value of the variable
> + * @opts  how to retrieve environment from flash, defaults are used if NULL
> + * @ret   EROFS if variable must not be changed (ethaddr, serial#)

@returns

> + */
>  int fw_setenv(int argc, char *argv[], struct env_opts *opts);
> +
> +/**
> + * fw_parse_script - add/remove multiple variables with a batch script
> + *
> + * @fname  batch script file name
> + * @opts  encryption key, configuration file, defaults are used if NULL

@returns

(please do for all)

> + *
> + * Script Syntax:
> + *   key [[space]+ value]
> + *   lines starting with '#' treated as comment
> + *
> + *   A variable without value will be deleted. Any number of spaces are 
> allowed
> + *   between key and value. The value starts with the first non-space 
> character
> + *   and ends with newline. No comments allowed on these lines.  Spaces 
> inside
> + *   the value are preserved verbatim.
> + *
> + * Script Example:"
> + *   netdev eth0
> + *   kernel_addr40
> + *   foospaces   are copied verbatim
> + *   # delete variable bar
> + *   bar\n"
> + */
>  int fw_parse_script(char *fname, struct env_opts *opts);
> +
> +
> +/**
> + * fw_env_open - read enviroment from flash and cache it in RAM
> + *
> + * @opts  encryption key, configuration file, defaults are used if NULL
> + */
>  int fw_env_open(struct env_opts *opts);
> +
> +/**
> + * fw_getenv - lookup variable in RAM cache
> + *
> + * @name  variable to be searched
> + * @ret   NULL if not found
> + */
> +char *fw_getenv(char *name);
> +
> +/**
> + * fw_env_write - set/clear a single variable in the RAM cache
> + *
> + * This is called in sequence to update the environment in RAM without 
> updating
> + * the copy in flash after each set
> + *
> + * @name  variable
> + * @value delete variable if NULL, otherwise create or overwrite the variable
> + */
>  int fw_env_write(char *name, char *value);
> +
> +/**
> + * fw_env_close - writes environment from RAM back to flash
> + *
> + * @opts  encryption key, configuration file, defaults are used if NULL
> + */
>  int fw_env_close(struct env_opts *opts);
>
>  unsigned long crc32(unsigned long, const unsigned char *, unsigned);
> --
> 2.8.1
>
> ___
> 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 3/4] tools/env: move envmatch further up in file to avoid forward declarations

2016-07-09 Thread Simon Glass

On 27 June 2016 at 16:06, Andreas Fenkart
 wrote:
> From: Andreas Fenkart 
>
> forward declaration not needed when re-ordered
>
> Signed-off-by: Andreas Fenkart 
> ---
>  tools/env/fw_env.c | 38 ++
>  1 file changed, 18 insertions(+), 20 deletions(-)

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

Re: [U-Boot] [PATCH] pwm: add MACRO to limit some code which only for rk3288

2016-07-09 Thread Simon Glass

Hi Kever,

On 7 July 2016 at 20:45, Kever Yang  wrote:
> The grf setting for rkpwm is only need in rk3288, other SoCs like
> RK3399 which also use rkpwm do not need set the grf, let's add a
> MACRO to make the code only for RK3288.
>
> Change-Id: I167a4e8cf925e840d4bbbcfb1437aaed52b81477

patman will automatically remove these for you.

> Signed-off-by: Kever Yang 
> ---
>  drivers/pwm/rk_pwm.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/pwm/rk_pwm.c b/drivers/pwm/rk_pwm.c
> index 2d289a4..e34adf0 100644
> --- a/drivers/pwm/rk_pwm.c
> +++ b/drivers/pwm/rk_pwm.c
> @@ -13,8 +13,10 @@
>  #include 
>  #include 
>  #include 
> +#ifdef CONFIG_ROCKCHIP_RK3288
>  #include 
>  #include 
> +#endif
>  #include 
>  #include 
>
> @@ -22,7 +24,9 @@ DECLARE_GLOBAL_DATA_PTR;
>
>  struct rk_pwm_priv {
> struct rk3288_pwm *regs;
> +#ifdef CONFIG_ROCKCHIP_RK3288
> struct rk3288_grf *grf;
> +#endif
>  };
>
>  static int rk_pwm_set_config(struct udevice *dev, uint channel, uint 
> period_ns,
> @@ -65,19 +69,23 @@ static int rk_pwm_ofdata_to_platdata(struct udevice *dev)
> struct regmap *map;
>
> priv->regs = (struct rk3288_pwm *)dev_get_addr(dev);
> +#ifdef CONFIG_ROCKCHIP_RK3288
> map = syscon_get_regmap_by_driver_data(ROCKCHIP_SYSCON_GRF);
> if (IS_ERR(map))
> return PTR_ERR(map);
> priv->grf = regmap_get_range(map, 0);
> +#endif

I'd like to find a better way. Do all chips have a grf? If so then
perhaps we can have a function like grf_enable_pwm() in the core SoC
code and call it here. The #ifdef can be there.

Or perhaps we should have a general soc.c, with its own struct
containing pointers to grf, sgrf, etc. It can be set up at the start,
and then provide a soc_enable_pwm() function to enable the pwm.

What do you think?

>
> return 0;
>  }
>
>  static int rk_pwm_probe(struct udevice *dev)
>  {
> +#ifdef CONFIG_ROCKCHIP_RK3288
> struct rk_pwm_priv *priv = dev_get_priv(dev);
>
> rk_setreg(>grf->soc_con2, 1 << 0);
> +#endif
>
> return 0;
>  }
> --
> 1.9.1
>
>

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

Re: [U-Boot] [PATCH 1/4] tools/env: return with error if redundant environments have unequal size

2016-07-09 Thread Simon Glass

On 27 June 2016 at 16:06, Andreas Fenkart
 wrote:
>
> From: Andreas Fenkart 
>
> For double buffering to work, the target buffer must always be big
> enough to hold all data. This can only be ensured if buffers are of
> equal size, otherwise one must be smaller and we risk data loss
> when copying from the bigger to the smaller buffer.
>
> Signed-off-by: Andreas Fenkart 
> ---
>  tools/env/fw_env.c | 23 ---
>  1 file changed, 12 insertions(+), 11 deletions(-)

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

Re: [U-Boot] [RESEND PATCH] rockchip: add basic support for evb-rk3288 board

2016-07-09 Thread Simon Glass

On 5 July 2016 at 04:06, Ziyuan Xu  wrote:
> evb-3288 board RK3288-based development board with 2 USB ports, HDMI,
> VGA, micro-SD card, audio, WiFi and Gigabit Ethernet. It also includes
> on-board 8G eMMC and 2GB of SDRAM. Expansion connector provide access to
> display pins, I2C, SPI, UART and GPIOs. This add some basic files
> required to allow the board to output serial messaged and can run
> command(mmc info etc).
>
> evb-rk3288 also supports booting from eMMC or SD card, the default is eMMC.
>
> Signed-off-by: Ziyuan Xu 
>
> ---
>
>  arch/arm/dts/Makefile |   1 +
>  arch/arm/dts/rk3288-evb.dts   |  59 +
>  arch/arm/dts/rk3288-evb.dtsi  | 379 
> ++
>  arch/arm/mach-rockchip/rk3288-board-spl.c |   4 +-
>  arch/arm/mach-rockchip/rk3288/Kconfig |  10 +
>  board/evb-rk3288/evb-rk3288/Kconfig   |  15 ++
>  board/evb-rk3288/evb-rk3288/MAINTAINERS   |   6 +
>  board/evb-rk3288/evb-rk3288/Makefile  |   7 +
>  board/evb-rk3288/evb-rk3288/evb-rk3288.c  |  15 ++
>  configs/evb-rk3288_defconfig  |  67 ++
>  doc/README.rockchip   |   3 +-
>  include/configs/evb-rk3288.h  |  26 ++
>  12 files changed, 590 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/dts/rk3288-evb.dts
>  create mode 100644 arch/arm/dts/rk3288-evb.dtsi
>  create mode 100644 board/evb-rk3288/evb-rk3288/Kconfig
>  create mode 100644 board/evb-rk3288/evb-rk3288/MAINTAINERS
>  create mode 100644 board/evb-rk3288/evb-rk3288/Makefile
>  create mode 100644 board/evb-rk3288/evb-rk3288/evb-rk3288.c
>  create mode 100644 configs/evb-rk3288_defconfig
>  create mode 100644 include/configs/evb-rk3288.h
>

Reviewed-by: Simon Glass 

small nit below.

[snip]

> diff --git a/board/evb-rk3288/evb-rk3288/evb-rk3288.c 
> b/board/evb-rk3288/evb-rk3288/evb-rk3288.c
> new file mode 100644
> index 000..a82f0ae
> --- /dev/null
> +++ b/board/evb-rk3288/evb-rk3288/evb-rk3288.c
> @@ -0,0 +1,15 @@
> +/*
> + * (C) Copyright 2016 Rockchip Electronics Co., Ltd
> + *
> + * SPDX-License-Identifier: GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +
> +void board_boot_order(u32 *spl_boot_list)
> +{
> +   /* eMMC prior to sdcard. */

nit: Can you drop the .?

> +   spl_boot_list[0] = BOOT_DEVICE_MMC2;
> +   spl_boot_list[1] = BOOT_DEVICE_MMC1;
> +}

snip]

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

Re: [U-Boot] [PATCH v2] SPL: tiny-printf: avoid any BSS usage

2016-07-09 Thread Simon Glass

On 8 July 2016 at 08:18, Andre Przywara  wrote:
> As printf calls may be executed quite early, we should avoid using any
> BSS stored variables, since some boards put BSS in DRAM, which may not
> have been initialised yet.
> Explicitly mark those "static global" variables as belonging to the
> .data section, to keep tiny-printf clear of any BSS usage.
>
> Signed-off-by: Andre Przywara 

Reviewed-by: Simon Glass 

Another approach would be to put these vars in a struct, declare it as
a local variable and pass it around. But this works OK too.

> ---
> Changes v1 .. v2:
> - remove NO_BSS macro, use __attribute__ ... directly instead
>
>  lib/tiny-printf.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
> index 451f4f7..b334f05 100644
> --- a/lib/tiny-printf.c
> +++ b/lib/tiny-printf.c
> @@ -13,11 +13,16 @@
>  #include 
>  #include 
>
> -static char *bf;
> -static char zs;
> +/*
> + * This code in here may execute before the DRAM is initialised, so
> + * we should make sure that it doesn't touch BSS, which some boards
> + * put in DRAM.
> + */
> +static char *bf __attribute__ ((section(".data")));
> +static char zs __attribute__ ((section(".data")));
>
>  /* Current position in sprintf() output string */
> -static char *outstr;
> +static char *outstr __attribute__ ((section(".data")));
>
>  static void out(char c)
>  {
> --
> 2.8.2
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] board: move all the rockchip board in one folder

2016-07-09 Thread Simon Glass

Hi Kevin,

On 7 July 2016 at 21:49, Eddie Cai  wrote:
> 2016-07-08 11:30 GMT+08:00 Kever Yang :
>> The 'evb_rk3036' and 'kylin' is not a vendor name, let's replace them
>> to 'rockchip' which is a real _vendor_ name, and meet the architecure
>> 'board///'.
>>
>> More boards from rockchip like evb_rk3288, evb_rk3399 will comes later.
>>
>> Signed-off-by: Kever Yang 
> Reviewed-by: Eddie Cai 
>> ---
>>  arch/arm/mach-rockchip/rk3036/Kconfig  |  4 +-
>>  board/evb_rk3036/evb_rk3036/Kconfig| 15 --
>>  board/evb_rk3036/evb_rk3036/MAINTAINERS|  0
>>  board/evb_rk3036/evb_rk3036/Makefile   |  7 ---
>>  board/evb_rk3036/evb_rk3036/evb_rk3036.c   | 49 --
>>  board/kylin/kylin_rk3036/Kconfig   | 15 --
>>  board/kylin/kylin_rk3036/MAINTAINERS   |  0
>>  board/kylin/kylin_rk3036/Makefile  |  7 ---
>>  board/kylin/kylin_rk3036/kylin_rk3036.c| 81 
>> --
>>  board/rockchip/evb_rk3036/Kconfig  | 15 ++
>>  board/rockchip/evb_rk3036/MAINTAINERS  |  0
>>  board/rockchip/evb_rk3036/Makefile |  7 +++
>>  board/rockchip/evb_rk3036/evb_rk3036.c | 49 ++
>>  board/rockchip/kylin_rk3036/Kconfig| 15 ++
>>  board/rockchip/kylin_rk3036/MAINTAINERS|  0
>>  board/rockchip/kylin_rk3036/Makefile   |  7 +++
>>  board/rockchip/kylin_rk3036/kylin_rk3036.c | 81 
>> ++
>>  17 files changed, 176 insertions(+), 176 deletions(-)
>>  delete mode 100644 board/evb_rk3036/evb_rk3036/Kconfig
>>  delete mode 100644 board/evb_rk3036/evb_rk3036/MAINTAINERS
>>  delete mode 100644 board/evb_rk3036/evb_rk3036/Makefile
>>  delete mode 100644 board/evb_rk3036/evb_rk3036/evb_rk3036.c
>>  delete mode 100644 board/kylin/kylin_rk3036/Kconfig
>>  delete mode 100644 board/kylin/kylin_rk3036/MAINTAINERS
>>  delete mode 100644 board/kylin/kylin_rk3036/Makefile
>>  delete mode 100644 board/kylin/kylin_rk3036/kylin_rk3036.c
>>  create mode 100644 board/rockchip/evb_rk3036/Kconfig
>>  create mode 100644 board/rockchip/evb_rk3036/MAINTAINERS
>>  create mode 100644 board/rockchip/evb_rk3036/Makefile
>>  create mode 100644 board/rockchip/evb_rk3036/evb_rk3036.c
>>  create mode 100644 board/rockchip/kylin_rk3036/Kconfig
>>  create mode 100644 board/rockchip/kylin_rk3036/MAINTAINERS
>>  create mode 100644 board/rockchip/kylin_rk3036/Makefile
>>  create mode 100644 board/rockchip/kylin_rk3036/kylin_rk3036.c

Did you use patman for these? I think it should show these as renames
rather than delete/add deltas.

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

Re: [U-Boot] arm: Fix setjmp (again)

2016-07-09 Thread Tom Rini

On Tue, Jul 05, 2016 at 08:37:17PM +0200, Alexander Graf wrote:

> Commit e677724 (arm: Fix setjmp) added code to fix compilation of the setjmp
> code path with thumv1. Unfortunately it missed a constraint that the adr
> instruction can only refer to 4 byte aligned offsets.
> 
> So this patch adds the required alignment hooks to make compilation
> work again even when setjmp doesn't happen to be 4 byte aligned.
> 
> Signed-off-by: Alexander Graf 
> Tested-by: Tom Rini 

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

Re: [U-Boot] [U-Boot, v2] armv8: Enable CPUECTLR.SMPEN for coherency

2016-07-09 Thread Tom Rini

On Thu, Jul 07, 2016 at 12:22:12PM +0800, Qianyu Gong wrote:

> From: Mingkai Hu 
> 
> For A53, data coherency is enabled only when the CPUECTLR.SMPEN bit is
> set. The SMPEN bit should be set before enabling the data cache.
> If not enabled, the cache is not coherent with other cores and
> data corruption could occur.
> 
> For A57/A72, SMPEN bit enables the processor to receive instruction
> cache and TLB maintenance operations broadcast from other processors
> in the cluster. This bit should be set before enabling the caches and
> MMU, or performing any cache and TLB maintenance operations.
> 
> Signed-off-by: Mingkai Hu 
> Signed-off-by: Gong Qianyu 
> Reviewed-by: Masahiro Yamada 

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

Re: [U-Boot] test/py: support 'memstart =' in u_boot_utils.find_ram_base()

2016-07-09 Thread Tom Rini

On Wed, Jul 06, 2016 at 12:44:22PM +0200, Daniel Schwierzeck wrote:

> Some archs like MIPS or PPC have a different 'bdinfo' output
> than ARM regarding the memory configuration. Also support
> 'memstart = 0x*' in u_boot_utils.find_ram_base() to make
> all tests requiring the RAM base working on those archs.
> 
> Signed-off-by: Daniel Schwierzeck 
> Acked-by: Stephen Warren 

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

Re: [U-Boot] test/py: strip VT100 codes from match buffer

2016-07-09 Thread Tom Rini

On Wed, Jul 06, 2016 at 10:34:30AM -0600, Stephen Warren wrote:

> From: Stephen Warren 
> 
> Prior to this patch, any VT100 codes emitted by U-Boot are considered part
> of a command's output, which often causes tests to fail. For example,
> test_env_echo_exists executes printenv, and then considers any text on a
> line before an = sign as a valid U-Boot environment variable name. This
> includes any VT100 codes emitted. When the test later attempts to use that
> variable, the name would be invalid since it includes the VT100 codes.
> Solve this by stripping VT100 codes from the match buffer, so they are
> never seen by higher level test code.
> 
> The codes are still logged unmodified, so that users can expect U-Boot's
> exact output without interference. This does clutter the log file a bit.
> However, it allows users to see exactly what U-Boot emitted rather than a
> modified version, which hopefully is better for debugging. It's also much
> simpler to implement, since logging happens as soon as text is received,
> and so stripping the VT100 codes from the log would require handling
> reception and stripping of partial VT100 codes.
> 
> Signed-off-by: Stephen Warren 

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

Re: [U-Boot] Important patch missing in u-boot master (was: [PATCH] arm: Fix setjmp (again))

2016-07-09 Thread Tom Rini

On Sat, Jul 09, 2016 at 01:09:29PM +0200, Karsten Merker wrote:
> On Tue, Jul 05, 2016 at 08:37:17PM +0200, Alexander Graf wrote:
> 
> > Commit e677724 (arm: Fix setjmp) added code to fix compilation of the setjmp
> > code path with thumv1. Unfortunately it missed a constraint that the adr
> > instruction can only refer to 4 byte aligned offsets.
> > 
> > So this patch adds the required alignment hooks to make compilation
> > work again even when setjmp doesn't happen to be 4 byte aligned.
> > 
> > Signed-off-by: Alexander Graf 
> > Tested-by: Tom Rini 
> > ---
> >  arch/arm/include/asm/setjmp.h | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/include/asm/setjmp.h b/arch/arm/include/asm/setjmp.h
> > index ae738b2..f7b97ef 100644
> > --- a/arch/arm/include/asm/setjmp.h
> > +++ b/arch/arm/include/asm/setjmp.h
> > @@ -43,6 +43,7 @@ static inline int setjmp(jmp_buf jmp)
> >  #else
> > asm volatile(
> >  #ifdef CONFIG_SYS_THUMB_BUILD
> > +   ".align 2\n"
> > "adr r0, jmp_target\n"
> > "add r0, r0, $1\n"
> >  #else
> > @@ -52,7 +53,8 @@ static inline int setjmp(jmp_buf jmp)
> > "mov r2, sp\n"
> > "stm r1!, {r0, r2, r4, r5, r6, r7}\n"
> > "b 2f\n"
> > -   "jmp_target: "
> > +   ".align 2\n"
> > +   "jmp_target: \n"
> > "mov %0, #1\n"
> > "2:\n"
> > : "+l" (r)
> 
> Hello,
> 
> this patch (https://patchwork.ozlabs.org/patch/644968/) hasn't
> yet found its way into u-boot master, but it should go in before
> the v2016.07 release which is due in two days, as without the
> patch u-boot fails to build on a number of platforms (cf.
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/266777).

Yes.  This is part of a small number that I was testing yesterday.

-- 
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] sunxi: Add support for multiple ethadrr-esses

2016-07-09 Thread Hans de Goede

Currently we fill ethaddr with a fixed unique address based on the SoCs
serial (from the sid) to make sure that boards which use the integrated
emac / gmac get a fixed mac rather then a random one.

On some boards the wifi does not come with a fixed mac either, so we need
to also set eth1addr.

This commit changes the ethaddr setting code to check for ethernet%d
aliases (as fdt_fixup_ethernet does) and set an ethaddr variable for
all present aliases.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Only set ethaddr env variable for ethernet interfaces which have
 an ethernet%d alias in the dt aliases node
---
 board/sunxi/board.c | 59 ++---
 1 file changed, 43 insertions(+), 16 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 78dfda5..955a44f 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -26,6 +26,7 @@
 #endif
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -609,36 +610,38 @@ static void parse_spl_header(const uint32_t spl_addr)
 }
 #endif
 
-#ifdef CONFIG_MISC_INIT_R
-int misc_init_r(void)
+static void setup_environment(const void *fdt)
 {
char serial_string[17] = { 0 };
unsigned int sid[4];
uint8_t mac_addr[6];
-   int ret;
-
-#if !defined(CONFIG_SPL_BUILD)
-   setenv("fel_booted", NULL);
-   setenv("fel_scriptaddr", NULL);
-   /* determine if we are running in FEL mode */
-   if (!is_boot0_magic(SPL_ADDR + 4)) { /* eGON.BT0 */
-   setenv("fel_booted", "1");
-   parse_spl_header(SPL_ADDR);
-   }
-#endif
+   char ethaddr[16];
+   int i, ret;
 
ret = sunxi_get_sid(sid);
if (ret == 0 && sid[0] != 0 && sid[3] != 0) {
-   if (!getenv("ethaddr")) {
+   for (i = 0; i < 4; i++) {
+   sprintf(ethaddr, "ethernet%d", i);
+   if (!fdt_get_alias(fdt, ethaddr))
+   continue;
+
+   if (i == 0)
+   strcpy(ethaddr, "ethaddr");
+   else
+   sprintf(ethaddr, "eth%daddr", i);
+
+   if (getenv(ethaddr))
+   continue;
+
/* Non OUI / registered MAC address */
-   mac_addr[0] = 0x02;
+   mac_addr[0] = (i << 4) | 0x02;
mac_addr[1] = (sid[0] >>  0) & 0xff;
mac_addr[2] = (sid[3] >> 24) & 0xff;
mac_addr[3] = (sid[3] >> 16) & 0xff;
mac_addr[4] = (sid[3] >>  8) & 0xff;
mac_addr[5] = (sid[3] >>  0) & 0xff;
 
-   eth_setenv_enetaddr("ethaddr", mac_addr);
+   eth_setenv_enetaddr(ethaddr, mac_addr);
}
 
if (!getenv("serial#")) {
@@ -648,6 +651,24 @@ int misc_init_r(void)
setenv("serial#", serial_string);
}
}
+}
+
+#ifdef CONFIG_MISC_INIT_R
+int misc_init_r(void)
+{
+   int ret;
+
+#if !defined(CONFIG_SPL_BUILD)
+   setenv("fel_booted", NULL);
+   setenv("fel_scriptaddr", NULL);
+   /* determine if we are running in FEL mode */
+   if (!is_boot0_magic(SPL_ADDR + 4)) { /* eGON.BT0 */
+   setenv("fel_booted", "1");
+   parse_spl_header(SPL_ADDR);
+   }
+#endif
+
+   setup_environment(gd->fdt_blob);
 
 #ifndef CONFIG_MACH_SUN9I
ret = sunxi_usb_phy_probe();
@@ -664,6 +685,12 @@ int ft_board_setup(void *blob, bd_t *bd)
 {
int __maybe_unused r;
 
+   /*
+* Call setup_environment again in case the boot fdt has
+* ethernet aliases the u-boot copy does not have.
+*/
+   setup_environment(blob);
+
 #ifdef CONFIG_VIDEO_DT_SIMPLEFB
r = sunxi_simplefb_setup(blob);
if (r)
-- 
2.7.4

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

Re: [U-Boot] [PATCH] sunxi: Add support for eth1addr

2016-07-09 Thread Hans de Goede


Hi,

On 09-07-16 15:05, Hans de Goede wrote:

Currently we will already fill ethaddr with a fixed unique address
based on the SoCs serial (from the sid) to make sure that boards which
use the integrated emac / gmac get a fixed mac rather then a random one.

On some boards (observed on 2 tablets using sdio rtl8703as wifi chips)
the wifi does not come with a fixed mac either, so also set eth1addr,
so that dts files can set an ethernet1 alias to get mac-address and
local-mac-address filled for dt nodes describing the wifi controller.

Signed-off-by: Hans de Goede 


Oops, I forgot to update the commit msg and mark this as v2, I will
send a new version instead.

Regards,

Hans



---
 board/sunxi/board.c | 59 ++---
 1 file changed, 43 insertions(+), 16 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 78dfda5..955a44f 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -26,6 +26,7 @@
 #endif
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -609,36 +610,38 @@ static void parse_spl_header(const uint32_t spl_addr)
 }
 #endif

-#ifdef CONFIG_MISC_INIT_R
-int misc_init_r(void)
+static void setup_environment(const void *fdt)
 {
char serial_string[17] = { 0 };
unsigned int sid[4];
uint8_t mac_addr[6];
-   int ret;
-
-#if !defined(CONFIG_SPL_BUILD)
-   setenv("fel_booted", NULL);
-   setenv("fel_scriptaddr", NULL);
-   /* determine if we are running in FEL mode */
-   if (!is_boot0_magic(SPL_ADDR + 4)) { /* eGON.BT0 */
-   setenv("fel_booted", "1");
-   parse_spl_header(SPL_ADDR);
-   }
-#endif
+   char ethaddr[16];
+   int i, ret;

ret = sunxi_get_sid(sid);
if (ret == 0 && sid[0] != 0 && sid[3] != 0) {
-   if (!getenv("ethaddr")) {
+   for (i = 0; i < 4; i++) {
+   sprintf(ethaddr, "ethernet%d", i);
+   if (!fdt_get_alias(fdt, ethaddr))
+   continue;
+
+   if (i == 0)
+   strcpy(ethaddr, "ethaddr");
+   else
+   sprintf(ethaddr, "eth%daddr", i);
+
+   if (getenv(ethaddr))
+   continue;
+
/* Non OUI / registered MAC address */
-   mac_addr[0] = 0x02;
+   mac_addr[0] = (i << 4) | 0x02;
mac_addr[1] = (sid[0] >>  0) & 0xff;
mac_addr[2] = (sid[3] >> 24) & 0xff;
mac_addr[3] = (sid[3] >> 16) & 0xff;
mac_addr[4] = (sid[3] >>  8) & 0xff;
mac_addr[5] = (sid[3] >>  0) & 0xff;

-   eth_setenv_enetaddr("ethaddr", mac_addr);
+   eth_setenv_enetaddr(ethaddr, mac_addr);
}

if (!getenv("serial#")) {
@@ -648,6 +651,24 @@ int misc_init_r(void)
setenv("serial#", serial_string);
}
}
+}
+
+#ifdef CONFIG_MISC_INIT_R
+int misc_init_r(void)
+{
+   int ret;
+
+#if !defined(CONFIG_SPL_BUILD)
+   setenv("fel_booted", NULL);
+   setenv("fel_scriptaddr", NULL);
+   /* determine if we are running in FEL mode */
+   if (!is_boot0_magic(SPL_ADDR + 4)) { /* eGON.BT0 */
+   setenv("fel_booted", "1");
+   parse_spl_header(SPL_ADDR);
+   }
+#endif
+
+   setup_environment(gd->fdt_blob);

 #ifndef CONFIG_MACH_SUN9I
ret = sunxi_usb_phy_probe();
@@ -664,6 +685,12 @@ int ft_board_setup(void *blob, bd_t *bd)
 {
int __maybe_unused r;

+   /*
+* Call setup_environment again in case the boot fdt has
+* ethernet aliases the u-boot copy does not have.
+*/
+   setup_environment(blob);
+
 #ifdef CONFIG_VIDEO_DT_SIMPLEFB
r = sunxi_simplefb_setup(blob);
if (r)


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

[U-Boot] [PATCH] sunxi: Add support for eth1addr

2016-07-09 Thread Hans de Goede

Currently we will already fill ethaddr with a fixed unique address
based on the SoCs serial (from the sid) to make sure that boards which
use the integrated emac / gmac get a fixed mac rather then a random one.

On some boards (observed on 2 tablets using sdio rtl8703as wifi chips)
the wifi does not come with a fixed mac either, so also set eth1addr,
so that dts files can set an ethernet1 alias to get mac-address and
local-mac-address filled for dt nodes describing the wifi controller.

Signed-off-by: Hans de Goede 
---
 board/sunxi/board.c | 59 ++---
 1 file changed, 43 insertions(+), 16 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 78dfda5..955a44f 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -26,6 +26,7 @@
 #endif
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -609,36 +610,38 @@ static void parse_spl_header(const uint32_t spl_addr)
 }
 #endif
 
-#ifdef CONFIG_MISC_INIT_R
-int misc_init_r(void)
+static void setup_environment(const void *fdt)
 {
char serial_string[17] = { 0 };
unsigned int sid[4];
uint8_t mac_addr[6];
-   int ret;
-
-#if !defined(CONFIG_SPL_BUILD)
-   setenv("fel_booted", NULL);
-   setenv("fel_scriptaddr", NULL);
-   /* determine if we are running in FEL mode */
-   if (!is_boot0_magic(SPL_ADDR + 4)) { /* eGON.BT0 */
-   setenv("fel_booted", "1");
-   parse_spl_header(SPL_ADDR);
-   }
-#endif
+   char ethaddr[16];
+   int i, ret;
 
ret = sunxi_get_sid(sid);
if (ret == 0 && sid[0] != 0 && sid[3] != 0) {
-   if (!getenv("ethaddr")) {
+   for (i = 0; i < 4; i++) {
+   sprintf(ethaddr, "ethernet%d", i);
+   if (!fdt_get_alias(fdt, ethaddr))
+   continue;
+
+   if (i == 0)
+   strcpy(ethaddr, "ethaddr");
+   else
+   sprintf(ethaddr, "eth%daddr", i);
+
+   if (getenv(ethaddr))
+   continue;
+
/* Non OUI / registered MAC address */
-   mac_addr[0] = 0x02;
+   mac_addr[0] = (i << 4) | 0x02;
mac_addr[1] = (sid[0] >>  0) & 0xff;
mac_addr[2] = (sid[3] >> 24) & 0xff;
mac_addr[3] = (sid[3] >> 16) & 0xff;
mac_addr[4] = (sid[3] >>  8) & 0xff;
mac_addr[5] = (sid[3] >>  0) & 0xff;
 
-   eth_setenv_enetaddr("ethaddr", mac_addr);
+   eth_setenv_enetaddr(ethaddr, mac_addr);
}
 
if (!getenv("serial#")) {
@@ -648,6 +651,24 @@ int misc_init_r(void)
setenv("serial#", serial_string);
}
}
+}
+
+#ifdef CONFIG_MISC_INIT_R
+int misc_init_r(void)
+{
+   int ret;
+
+#if !defined(CONFIG_SPL_BUILD)
+   setenv("fel_booted", NULL);
+   setenv("fel_scriptaddr", NULL);
+   /* determine if we are running in FEL mode */
+   if (!is_boot0_magic(SPL_ADDR + 4)) { /* eGON.BT0 */
+   setenv("fel_booted", "1");
+   parse_spl_header(SPL_ADDR);
+   }
+#endif
+
+   setup_environment(gd->fdt_blob);
 
 #ifndef CONFIG_MACH_SUN9I
ret = sunxi_usb_phy_probe();
@@ -664,6 +685,12 @@ int ft_board_setup(void *blob, bd_t *bd)
 {
int __maybe_unused r;
 
+   /*
+* Call setup_environment again in case the boot fdt has
+* ethernet aliases the u-boot copy does not have.
+*/
+   setup_environment(blob);
+
 #ifdef CONFIG_VIDEO_DT_SIMPLEFB
r = sunxi_simplefb_setup(blob);
if (r)
-- 
2.7.4

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

[U-Boot] [PATCH] sunxi: Remove some unnecessary #ifdefs

2016-07-09 Thread Hans de Goede

We always define CONFIG_MISC_INIT_R on sunxi and misc_init_r is never
called in the spl, so the linker will optimize it and parse_spl_header(),
of which it is the only caller, away.

On the tests I've done (Orange Pi PC build) the SPL actually becomes
8 bytes smaller with this patch.

Signed-off-by: Hans de Goede 
---
 board/sunxi/board.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 955a44f..9767310 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -20,12 +20,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #ifndef CONFIG_ARM64
 #include 
 #endif
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -572,10 +574,6 @@ void get_board_serial(struct tag_serialnr *serialnr)
 }
 #endif
 
-#if !defined(CONFIG_SPL_BUILD)
-#include 
-#include 
-
 /*
  * Check the SPL header for the "sunxi" variant. If found: parse values
  * that might have been passed by the loader ("fel" utility), and update
@@ -608,7 +606,6 @@ static void parse_spl_header(const uint32_t spl_addr)
/* otherwise assume .scr format (mkimage-type script) */
setenv_hex("fel_scriptaddr", spl->fel_script_address);
 }
-#endif
 
 static void setup_environment(const void *fdt)
 {
@@ -653,12 +650,10 @@ static void setup_environment(const void *fdt)
}
 }
 
-#ifdef CONFIG_MISC_INIT_R
 int misc_init_r(void)
 {
int ret;
 
-#if !defined(CONFIG_SPL_BUILD)
setenv("fel_booted", NULL);
setenv("fel_scriptaddr", NULL);
/* determine if we are running in FEL mode */
@@ -666,7 +661,6 @@ int misc_init_r(void)
setenv("fel_booted", "1");
parse_spl_header(SPL_ADDR);
}
-#endif
 
setup_environment(gd->fdt_blob);
 
@@ -679,7 +673,6 @@ int misc_init_r(void)
 
return 0;
 }
-#endif
 
 int ft_board_setup(void *blob, bd_t *bd)
 {
-- 
2.7.4

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

Re: [U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img

2016-07-09 Thread Otavio Salvador

On Sat, Jul 9, 2016 at 9:42 AM, Alexey Brodkin
 wrote:
> Recently I started to notice that u-boot.img built for Wandboard
> by some toolchains becomes so large that it basically overlaps with
> U-Boot environment area on SD-card.
>
> According to
> http://wiki.wandboard.org/index.php/Boot-process#sdcard_boot_data_layout
> Wandboard's SD-card layout is as follows:
> -->8---
> ==
> 1. 0x   Reserved For MBR
> 2. 0x0200   512 Secondary Image Table (optional)
> 3. 0x0400   1024uBoot Image (Starting From IVT)
> 4. 0x0006   393216  start of uboot env (size:8k)
> 5. 0x00062000   end of uboot env
> 6. 0x0010   1048576 Linux kernel start
> 7. 0x0076AC00   280 start of partition 1
> -->8---
>
> So for U-Boot we have 383kB (392192 bytes).
>
> But in up to date U-Boot for Wandboard we build separately
>  a) SPL
>  b) u-boot.img
>
> which gives us a bit more detailed SD-card layout:
> -->8---
> ==
> 1. 0x   Reserved For MBR
> 2. 0x0200   512 Secondary Image Table (optional)
> 3. 0x0400   1024SPL
> 4. 0x00011400   70656   u-boot.img
> 5. 0x0006   393216  start of uboot env (size:8k)
> 6. 0x00062000   end of uboot env
> ...
> -->8---
>
> From that layout we may calculate amount of space reserved for
> u-boot.img. It's just 315kb (322560 bytes).
>
> Now if I build U-Boot with Sourcery CodeBench ARM 2014.05 produced
> u-boot.img is already more than we expected
> (323840 bytes instead of "< 322560"):
> -->8---
> ls -la u-boot.img
> -rw-rw-r-- 1 user user 323840 Jul  5 07:38 u-boot.img
> -->8---
>
> Funny enough if I rebuild U-Boot with ARM toolchain available in
> my Fedora 23 distro u-boot.img becomes a little bit smaller:
> -->8---
> ls -la u-boot.img
> -rw-rw-r-- 1 user user 322216 Jul  5 07:39 u-boot.img
> -->8---
>
> What's worse this problem might not affect people most of the time
> because what happens people would just copy u-boot.img on SD-card and
> live in happiness with it... well until somebody attempts to save
> environment in U-Boot with "saveenv" command which will simply
> overwrite the very end of u-boot.img.
> That will lead to unusable SD-card until user dd u-boot.img on
> SD-card again.
>
> I may foresee this issue in the future to become more visible once we
> add more features in U-Boot for Wandboard or just existing code base
> becomes bulkier and people will consistently get larger u-boot.img
> files produced.
>
> IMHO there's an obvious solution for all that - just move U-Boot's env
> to the very end of the gap between U-Boot and the first real partition
> on the SD-card. This patch will follow
> 8fb9eea5653796 ("mx6sabre_common: Fix U-Boot corruption after 'saveenv'").
> So env is still not in the very end of the gap (obviously 256kb is way
> too much for U-Boot's env) but at least we have now the same
> partitioning for i.MX6 boards.
>
> Signed-off-by: Alexey Brodkin 
> Cc: Fabio Estevam 
> Cc: Otavio Salvador 
> Cc: Peter Robinson 
> Cc: Tom Rini 
> Cc: Peter Korsgaard 
> Cc: Wolfgang Denk 

Couldn't this be done on the common header?

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

[U-Boot] [PATCH] wandboard: move environment partition farther from u-boot.img

2016-07-09 Thread Alexey Brodkin

Recently I started to notice that u-boot.img built for Wandboard
by some toolchains becomes so large that it basically overlaps with
U-Boot environment area on SD-card.

According to
http://wiki.wandboard.org/index.php/Boot-process#sdcard_boot_data_layout
Wandboard's SD-card layout is as follows:
-->8---
==
1. 0x   Reserved For MBR
2. 0x0200   512 Secondary Image Table (optional)
3. 0x0400   1024uBoot Image (Starting From IVT)
4. 0x0006   393216  start of uboot env (size:8k)
5. 0x00062000   end of uboot env
6. 0x0010   1048576 Linux kernel start
7. 0x0076AC00   280 start of partition 1
-->8---

So for U-Boot we have 383kB (392192 bytes).

But in up to date U-Boot for Wandboard we build separately
 a) SPL
 b) u-boot.img

which gives us a bit more detailed SD-card layout:
-->8---
==
1. 0x   Reserved For MBR
2. 0x0200   512 Secondary Image Table (optional)
3. 0x0400   1024SPL
4. 0x00011400   70656   u-boot.img
5. 0x0006   393216  start of uboot env (size:8k)
6. 0x00062000   end of uboot env
...
-->8---

>From that layout we may calculate amount of space reserved for
u-boot.img. It's just 315kb (322560 bytes).

Now if I build U-Boot with Sourcery CodeBench ARM 2014.05 produced
u-boot.img is already more than we expected
(323840 bytes instead of "< 322560"):
-->8---
ls -la u-boot.img
-rw-rw-r-- 1 user user 323840 Jul  5 07:38 u-boot.img
-->8---

Funny enough if I rebuild U-Boot with ARM toolchain available in
my Fedora 23 distro u-boot.img becomes a little bit smaller:
-->8---
ls -la u-boot.img
-rw-rw-r-- 1 user user 322216 Jul  5 07:39 u-boot.img
-->8---

What's worse this problem might not affect people most of the time
because what happens people would just copy u-boot.img on SD-card and
live in happiness with it... well until somebody attempts to save
environment in U-Boot with "saveenv" command which will simply
overwrite the very end of u-boot.img.
That will lead to unusable SD-card until user dd u-boot.img on
SD-card again.

I may foresee this issue in the future to become more visible once we
add more features in U-Boot for Wandboard or just existing code base
becomes bulkier and people will consistently get larger u-boot.img
files produced.

IMHO there's an obvious solution for all that - just move U-Boot's env
to the very end of the gap between U-Boot and the first real partition
on the SD-card. This patch will follow
8fb9eea5653796 ("mx6sabre_common: Fix U-Boot corruption after 'saveenv'").
So env is still not in the very end of the gap (obviously 256kb is way
too much for U-Boot's env) but at least we have now the same
partitioning for i.MX6 boards.

Signed-off-by: Alexey Brodkin 
Cc: Fabio Estevam 
Cc: Otavio Salvador 
Cc: Peter Robinson 
Cc: Tom Rini 
Cc: Peter Korsgaard 
Cc: Wolfgang Denk 
---
 include/configs/wandboard.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/wandboard.h b/include/configs/wandboard.h
index 99f5c0c..928d3d5 100644
--- a/include/configs/wandboard.h
+++ b/include/configs/wandboard.h
@@ -181,7 +181,7 @@
 #define CONFIG_ENV_SIZE(8 * 1024)
 
 #define CONFIG_ENV_IS_IN_MMC
-#define CONFIG_ENV_OFFSET  (6 * 64 * 1024)
+#define CONFIG_ENV_OFFSET  (768 * 1024)
 #define CONFIG_SYS_MMC_ENV_DEV 0
 
 #endif/* __CONFIG_H * */
-- 
2.5.5

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

Re: [U-Boot] 2016.07 regression on Orange Pi PC

2016-07-09 Thread Peter Robinson

>> It seems we've regressed with the Orange Pi PC for 2016.07 but I'm
>> wondering with the PCSI bits whether the process has changed and I've
>> missed the details of what's needed to flash u-boot.
>
>
> I just tried on my own Orange Pi PC with current master (which will
> become the final 2016.07 real soon now) and everything works fine.
>
> wrt the flash process, nothing has changed simply dd
> u-boot-sunxi-with-spl.bin to an offset of 8192 bytes on the sdcard.
>
>> With rc3 I see the follwing:
>>
>> U-Boot SPL 2016.07-rc3 (Jul 07 2016 - 10:36:40)
>> DRAM: u MiB
>> Could not determine boot source
>
>
> Sometimes this happens if writing to the sdcard went wrong somehow,
> sometimes the data can be unreadable or worse not readable reliably
> for the board even though the PC reports everything as ok
> (often when this happens the write takes longer then usual, indicating
>  the PC has to retry it under the hood).
>
> Often just repeating the dd fixes this (sad but true), I'm not aware
> of any bug in rc3 wich would trigger this, and looking at the
> commits in master since rc3 nothing stands out.
>
> To double check I've just taken u-boot-sunxi-with-spl.bin for the
> opi pc from:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=778437
>
> And then did:
>
> sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8
>
> And after that tested it, and it works fine for me, so it seems
> that you indeed got unlucky by hitting a bad / weak flash sector
> on the sdcard.

That's what I used and I used the same card for both 2016.07rc3 and
2016.05 with the later working, I tried the 07.rc3 a couple of times
with the same errors, I'll dig out another card and give it a go.

Peter


>> resetting ...
>>
>> But with 2016.05 GA I get:
>>
>> U-Boot SPL 2016.05 (May 30 2016 - 20:15:17)
>> DRAM: 1024 MiB
>> Trying to boot from MMC1
>>
>>
>> U-Boot 2016.05 (May 30 2016 - 20:15:17 +) Allwinner Technology
>>
>> CPU:   Allwinner H3 (SUN8I 1680)
>> Model: Xunlong Orange Pi PC
>> I2C:   ready
>> DRAM:  1 GiB
>> MMC:   SUNXI SD/MMC: 0
>> *** Warning - bad CRC, using default environment
>>
>> In:serial
>> Out:   serial
>> Err:   serial
>> Net:   No ethernet found.
>> starting USB...
>> USB0:   USB EHCI 1.00
>> USB1:   USB OHCI 1.0
>> USB2:   USB EHCI 1.00
>> USB3:   USB OHCI 1.0
>> USB4:   USB EHCI 1.00
>> USB5:   USB OHCI 1.0
>> scanning bus 0 for devices... 1 USB Device(s) found
>> scanning bus 2 for devices... 1 USB Device(s) found
>> scanning bus 4 for devices... 1 USB Device(s) found
>> Hit any key to stop autoboot:  0
>> =>
>> ___
>> 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] 2016.07 regression on Orange Pi PC

2016-07-09 Thread Hans de Goede


Hi,

On 09-07-16 07:52, Peter Robinson wrote:

It seems we've regressed with the Orange Pi PC for 2016.07 but I'm
wondering with the PCSI bits whether the process has changed and I've
missed the details of what's needed to flash u-boot.


I just tried on my own Orange Pi PC with current master (which will
become the final 2016.07 real soon now) and everything works fine.

wrt the flash process, nothing has changed simply dd
u-boot-sunxi-with-spl.bin to an offset of 8192 bytes on the sdcard.


With rc3 I see the follwing:

U-Boot SPL 2016.07-rc3 (Jul 07 2016 - 10:36:40)
DRAM: u MiB
Could not determine boot source


Sometimes this happens if writing to the sdcard went wrong somehow,
sometimes the data can be unreadable or worse not readable reliably
for the board even though the PC reports everything as ok
(often when this happens the write takes longer then usual, indicating
 the PC has to retry it under the hood).

Often just repeating the dd fixes this (sad but true), I'm not aware
of any bug in rc3 wich would trigger this, and looking at the
commits in master since rc3 nothing stands out.

To double check I've just taken u-boot-sunxi-with-spl.bin for the
opi pc from:
http://koji.fedoraproject.org/koji/buildinfo?buildID=778437

And then did:

sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8

And after that tested it, and it works fine for me, so it seems
that you indeed got unlucky by hitting a bad / weak flash sector
on the sdcard.

Regards,

Hans






resetting ...

But with 2016.05 GA I get:

U-Boot SPL 2016.05 (May 30 2016 - 20:15:17)
DRAM: 1024 MiB
Trying to boot from MMC1


U-Boot 2016.05 (May 30 2016 - 20:15:17 +) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi PC
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default environment

In:serial
Out:   serial
Err:   serial
Net:   No ethernet found.
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
USB4:   USB EHCI 1.00
USB5:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 4 for devices... 1 USB Device(s) found
Hit any key to stop autoboot:  0
=>
___
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] [RESEND PATCH] sunxi: mmc: increase status register polling rate for data transfers

2016-07-09 Thread Hans de Goede


Hi,

On 08-07-16 12:40, Tobias Doerffel wrote:

With a recent bunch of SD3.0 cards in our A20-based board we
experienced data transfer rates of about 250 KiB/s instead of 10 MiB/s
with previous cards from the same vendor (both 4 GB/class 10). By
increasing status register polling rate from 1 kHz to 1 MHz we were
able to reach the original transfer rates again. With the old cards
we now even reach about 16 MiB/s.

Signed-off-by: Tobias Doerffel 


Thanks, this tremendously speeds up boot on some of my boards, good stuff!

I've merge this locally and it should show up in u-boot-sunxi/next later
today.

Regards,

Hans




---
 drivers/mmc/sunxi_mmc.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index ce2dc4a..36da3b3 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -269,18 +269,18 @@ static int mmc_trans_data_by_cpu(struct mmc *mmc, struct 
mmc_data *data)
unsigned i;
unsigned *buff = (unsigned int *)(reading ? data->dest : data->src);
unsigned byte_cnt = data->blocksize * data->blocks;
-   unsigned timeout_msecs = byte_cnt >> 8;
-   if (timeout_msecs < 2000)
-   timeout_msecs = 2000;
+   unsigned timeout_usecs = (byte_cnt >> 8) * 1000;
+   if (timeout_usecs < 200)
+   timeout_usecs = 200;

/* Always read / write data through the CPU */
setbits_le32(>reg->gctrl, SUNXI_MMC_GCTRL_ACCESS_BY_AHB);

for (i = 0; i < (byte_cnt >> 2); i++) {
while (readl(>reg->status) & status_bit) {
-   if (!timeout_msecs--)
+   if (!timeout_usecs--)
return -1;
-   udelay(1000);
+   udelay(1);
}

if (reading)


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

Re: [U-Boot] [U-Boot,v2] SPL: tiny-printf: avoid any BSS usage

2016-07-09 Thread Marek Vasut


On 07/09/2016 02:28 AM, Tom Rini wrote:

On Fri, Jul 08, 2016 at 11:48:12PM +0200, Marek Vasut wrote:

On 07/08/2016 06:50 PM, Tom Rini wrote:

On Fri, Jul 08, 2016 at 03:18:35PM +0100, Andre Przywara wrote:


As printf calls may be executed quite early, we should avoid using any
BSS stored variables, since some boards put BSS in DRAM, which may not
have been initialised yet.
Explicitly mark those "static global" variables as belonging to the
.data section, to keep tiny-printf clear of any BSS usage.

Signed-off-by: Andre Przywara 


Applied to u-boot/master, thanks!


Mind you, __section(".data") would be enough, no need to spell the
whole attribute.


True, but that's a helper that's not really utilized today.

That's something that should likely be changed, as it allows to 
seamlessly deal with compiler quirks (if some were to ever pop up in 
this area).


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

37 matches

Mail list logo