[U-Boot] [PATCH v2 3/3] rockchip: rk3399: Add more instructions to the README

[Ezequiel Garcia]

This commit adds a content section and also instructions
on how to create a bootable SD/MMC device for RK3399 boards.

Acked-by: Philipp Tomsich 
Reviewed-by: Simon Glass 
Signed-off-by: Ezequiel Garcia 
---
 board/rockchip/evb_rk3399/README | 55 ++--
 1 file changed, 53 insertions(+), 2 deletions(-)

diff --git a/board/rockchip/evb_rk3399/README b/board/rockchip/evb_rk3399/README
index d08e2ea13147..4d283dc31d48 100644
--- a/board/rockchip/evb_rk3399/README
+++ b/board/rockchip/evb_rk3399/README
@@ -1,3 +1,21 @@
+Contents
+
+
+1. Introduction
+2. Get the Source and prebuild binary
+3. Compile the ATF
+4. Compile the U-Boot
+5. Compile the rkdeveloptool
+6. Package the image
+   6.1. Package the image for U-Boot SPL(option 1)
+   6.2. Package the image for Rockchip miniloader(option 2)
+7. Bootloader storage options
+8. Flash the image to eMMC
+   8.1. Flash the image with U-Boot SPL(option 1)
+   8.2. Flash the image with Rockchip miniloader(option 2)
+9. Create a bootable SD/MMC
+10. And that is it
+
 Introduction
 
 
@@ -97,6 +115,12 @@ Package the image for Rockchip miniloader(option 2)
 
   Get trust.img and uboot.img in this step.
 
+Bootloader storage options
+==
+
+There are a few different storage options for the bootloader.
+This document explores two of these: eMMC and removable SD/MMC.
+
 Flash the image to eMMC
 ===
 
@@ -117,6 +141,33 @@ Power on(or reset with RESET KEY) with MASKROM KEY 
preesed, and then:
   > rkdeveloptool wl 0x6000 u-boot/trust.img
   > rkdeveloptool rd
 
+Create a bootable SD/MMC
+
+
+The idbspl.img contains the first stage, and the u-boot.img the second stage.
+As explained in the Rockchip partition table reference [2], the first stage
+(aka loader1) start sector is 64, and the second stage start sector is 16384.
+
+Each sector is 512 bytes, which means the first stage offset is 32 KiB,
+and the second stage offset is 8 MiB.
+
+Note: the second stage location is actually not as per the spec,
+but defined by the SPL. Mainline SPL defines an 8 MiB offset for the second
+stage.
+
+Assuming the SD card is exposed by device /dev/mmcblk0, the commands
+to write the two stages are:
+
+  > dd if=idbspl.img of=/dev/mmcblk0 bs=1k seek=32
+  > dd if=u-boot.itb of=/dev/mmcblk0 bs=1k seek=8192
+
+Setting up the kernel and rootfs is beyond the scope of this document.
+
+And that is it
+==
+
 You should be able to get U-Boot log in console/UART2(baurdrate 150)
-For more detail, please reference to:
-http://opensource.rock-chips.com/wiki_Boot_option
+For more detail, please reference [2].
+
+[1] http://opensource.rock-chips.com/wiki_Partitions
+[2] http://opensource.rock-chips.com/wiki_Boot_option
-- 
2.18.0

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

[U-Boot] [PATCH v2 2/3] rockchip: rk3399: add Ficus board

[Ezequiel Garcia]

This commit adds support for RK3399 Ficus board,
aka ROCK960 Enterprise Edition.

Following peripherals are tested and known to work:
* Gigabit Ethernet
* USB 2.0
* MMC

Acked-by: Philipp Tomsich 
Signed-off-by: Ezequiel Garcia 
---
 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/rk3399-ficus.dts| 564 +++
 board/rockchip/evb_rk3399/README |   2 +
 configs/ficus-rk3399_defconfig   |  70 
 4 files changed, 637 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-ficus.dts
 create mode 100644 configs/ficus-rk3399_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index ebfa2272627b..9aaee42c1521 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -47,6 +47,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3368-geekbox.dtb \
rk3368-px5-evb.dtb \
rk3399-evb.dtb \
+   rk3399-ficus.dtb \
rk3399-firefly.dtb \
rk3399-puma-ddr1333.dtb \
rk3399-puma-ddr1600.dtb \
diff --git a/arch/arm/dts/rk3399-ficus.dts b/arch/arm/dts/rk3399-ficus.dts
new file mode 100644
index ..db015a26
--- /dev/null
+++ b/arch/arm/dts/rk3399-ficus.dts
@@ -0,0 +1,564 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * Schematics available at https://dl.vamrs.com/products/ficus/docs/hw
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+#include "rk3399-sdram-ddr3-1600.dtsi"
+
+/ {
+   model = "96boards RK3399 Ficus";
+   compatible = "vamrs,ficus", "rockchip,rk3399";
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   clkin_gmac: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "clkin_gmac";
+   #clock-cells = <0>;
+   };
+
+   vcc1v8_s0: vcc1v8-s0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc1v8_s0";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   vcc_sys: vcc-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_sys";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+
+   vcc3v3_sys: vcc3v3-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   vin-supply = <_sys>;
+   };
+
+   vcc3v3_pcie: vcc3v3-pcie-regulator {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = < 24 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_drv>;
+   regulator-boot-on;
+   regulator-name = "vcc3v3_pcie";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_sys>;
+   };
+
+   vcc5v0_host: vcc5v0-host-regulator {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = < 27 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_vbus_drv>;
+   regulator-name = "vcc5v0_host";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   vin-supply = <_sys>;
+   };
+
+   vdd_log: vdd-log {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 0>;
+   regulator-name = "vdd_log";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+   vin-supply = <_sys>;
+   };
+};
+
+_l0 {
+   cpu-supply = <_cpu_l>;
+};
+
+_l1 {
+   cpu-supply = <_cpu_l>;
+};
+
+_l2 {
+   cpu-supply = <_cpu_l>;
+};
+
+_l3 {
+   cpu-supply = <_cpu_l>;
+};
+
+_b0 {
+   cpu-supply = <_cpu_b>;
+};
+
+_b1 {
+   cpu-supply = <_cpu_b>;
+};
+
+_phy {
+   status = "okay";
+};
+
+ {
+   assigned-clocks = < SCLK_RMII_SRC>;
+   assigned-clock-parents = <_gmac>;
+   clock_in_out = "input";
+   phy-supply = <_sys>;
+   phy-mode = "rgmii";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   snps,reset-gpio = < RK_PB7 GPIO_ACTIVE_LOW>;
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 5>;
+   tx_delay = <0x28>;
+   rx_delay = <0x11>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   

[U-Boot] [PATCH v2 0/3] RK3399: Add support for Ficus board

[Ezequiel Garcia]

Add support for a new RK3399-based board. The RK3399 Ficus
board is an Enterprise Edition board manufactured by Vamrs Ltd.,
based on the Rockchip RK3399 SoC.

While here, we extend the evb_rk3399/README document
with instructions for SD/MMC boot.

The devicetree file for this board has been already merged
in Linux maintainer's tree:

https://kernel.googlesource.com/pub/scm/linux/kernel/git/mmind/linux-rockchip/+/v4.19-armsoc/dts64/arch/arm64/boot/dts/rockchip/rk3399-ficus.dts

Changes from v1:
  * Drop CONFIG_ROCKCHIP_USB2_PHY which wasn't
appropriate for this board, and also it was breaking
the build.
  * Tested on travis-ci.org.

Ezequiel Garcia (2):
  rockchip: rk3399: add Ficus board
  rockchip: rk3399: Add more instructions to the README

Randy Li (1):
  arm: dts: rockchip: add some common pin-settings to rk3399

 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/rk3399-ficus.dts| 564 +++
 arch/arm/dts/rk3399.dtsi |  55 ++-
 board/rockchip/evb_rk3399/README |  57 +++-
 configs/ficus-rk3399_defconfig   |  70 
 5 files changed, 739 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm/dts/rk3399-ficus.dts
 create mode 100644 configs/ficus-rk3399_defconfig

-- 
2.18.0

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

[U-Boot] [PATCH v2 1/3] arm: dts: rockchip: add some common pin-settings to rk3399

[Ezequiel Garcia]

From: Randy Li 

Those pins would be used by many boards.

Commit grabbed from Linux:

commit b41023282d07b61a53e2c9b9508912b1e7ce7b4f
Author: Randy Li 
Date:   Thu Jun 21 21:32:10 2018 +0800

arm64: dts: rockchip: add some common pin-settings to rk3399

Those pins would be used by many boards.

Signed-off-by: Randy Li 
Signed-off-by: Heiko Stuebner 

Acked-by: Philipp Tomsich 
Signed-off-by: Randy Li 
Signed-off-by: Heiko Stuebner 
Signed-off-by: Ezequiel Garcia 
---
 arch/arm/dts/rk3399.dtsi | 55 +++-
 1 file changed, 49 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index 83c257b1228b..8349451b03dc 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -1602,19 +1602,49 @@
drive-strength = <12>;
};
 
+   pcfg_pull_none_13ma: pcfg-pull-none-13ma {
+   bias-disable;
+   drive-strength = <13>;
+   };
+
+   pcfg_pull_none_18ma: pcfg-pull-none-18ma {
+   bias-disable;
+   drive-strength = <18>;
+   };
+
+   pcfg_pull_none_20ma: pcfg-pull-none-20ma {
+   bias-disable;
+   drive-strength = <20>;
+   };
+
+   pcfg_pull_up_2ma: pcfg-pull-up-2ma {
+   bias-pull-up;
+   drive-strength = <2>;
+   };
+
pcfg_pull_up_8ma: pcfg-pull-up-8ma {
bias-pull-up;
drive-strength = <8>;
};
 
+   pcfg_pull_up_18ma: pcfg-pull-up-18ma {
+   bias-pull-up;
+   drive-strength = <18>;
+   };
+
+   pcfg_pull_up_20ma: pcfg-pull-up-20ma {
+   bias-pull-up;
+   drive-strength = <20>;
+   };
+
pcfg_pull_down_4ma: pcfg-pull-down-4ma {
bias-pull-down;
drive-strength = <4>;
};
 
-   pcfg_pull_up_2ma: pcfg-pull-up-2ma {
-   bias-pull-up;
-   drive-strength = <2>;
+   pcfg_pull_down_8ma: pcfg-pull-down-8ma {
+   bias-pull-down;
+   drive-strength = <8>;
};
 
pcfg_pull_down_12ma: pcfg-pull-down-12ma {
@@ -1622,9 +1652,22 @@
drive-strength = <12>;
};
 
-   pcfg_pull_none_13ma: pcfg-pull-none-13ma {
-   bias-disable;
-   drive-strength = <13>;
+   pcfg_pull_down_18ma: pcfg-pull-down-18ma {
+   bias-pull-down;
+   drive-strength = <18>;
+   };
+
+   pcfg_pull_down_20ma: pcfg-pull-down-20ma {
+   bias-pull-down;
+   drive-strength = <20>;
+   };
+
+   pcfg_output_high: pcfg-output-high {
+   output-high;
+   };
+
+   pcfg_output_low: pcfg-output-low {
+   output-low;
};
 
clock {
-- 
2.18.0

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

Re: [U-Boot] [PATCH V4 1/2] mmc: add HS400 support

[Peng Fan]

Hi,

Would anyone pick up this patchset? Tom, I delegated the patchset to you, would 
you mind pick it up? 

Thanks,
Peng.

-Original Message-
From: Peng Fan 
Sent: 2018年8月10日 14:08
To: jh80.ch...@samsung.com; sba...@denx.de
Cc: u-boot@lists.denx.de; dl-linux-imx ; Peng Fan 
; Jean-Jacques Hiblot ; Kishon Vijay Abraham 
I ; Faiz Abbas ; Marek Vasut 
Subject: [PATCH V4 1/2] mmc: add HS400 support

Add HS400 support.
Selecting HS400 needs first select HS200 according to spec, so use a dedicated 
function for HS400.
Add HS400 related macros.
Remove the restriction of only using the low 6 bits of EXT_CSD_CARD_TYPE, using 
all the 8 bits.

Signed-off-by: Peng Fan 
Cc: Jaehoon Chung 
Cc: Jean-Jacques Hiblot 
Cc: Stefano Babic 
Cc: Kishon Vijay Abraham I 
Cc: Faiz Abbas 
Cc: Marek Vasut 
---

V4:
 Add SPL_MMC_HS400_SUPPORT Kconfig entry  typo fix, HS199->HS200 in commit log.

V3:
 Simplify code
 add error msg

V2:
 remove 4bits support from HS400, as HS400 does not support 4bits per spec.

 drivers/mmc/Kconfig |  13 +
 drivers/mmc/mmc.c   | 137 +---
 include/mmc.h   |  11 +
 3 files changed, 134 insertions(+), 27 deletions(-)

diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index 
377b1c4b3b..1616022b91 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -111,6 +111,19 @@ config SPL_MMC_UHS_SUPPORT
  cards. The IO voltage must be switchable from 3.3v to 1.8v. The bus
  frequency can go up to 208MHz (SDR104)
 
+config MMC_HS400_SUPPORT
+   bool "enable HS400 support"
+   select MMC_HS200_SUPPORT
+   help
+ The HS400 mode is support by some eMMC. The bus frequency is up to
+ 200MHz. This mode requires tuning the IO.
+
+config SPL_MMC_HS400_SUPPORT
+   bool "enable HS400 support in SPL"
+   help
+ The HS400 mode is support by some eMMC. The bus frequency is up to
+ 200MHz. This mode requires tuning the IO.
+
 config MMC_HS200_SUPPORT
bool "enable HS200 support"
help
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index ad429f49c9..585951cd78 
100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -147,6 +147,7 @@ const char *mmc_mode_name(enum bus_mode mode)
  [MMC_HS_52]   = "MMC High Speed (52MHz)",
  [MMC_DDR_52]  = "MMC DDR52 (52MHz)",
  [MMC_HS_200]  = "HS200 (200MHz)",
+ [MMC_HS_400]  = "HS400 (200MHz)",
};
 
if (mode >= MMC_MODES_END)
@@ -171,6 +172,7 @@ static uint mmc_mode2freq(struct mmc *mmc, enum bus_mode 
mode)
  [UHS_DDR50]   = 5000,
  [UHS_SDR104]  = 20800,
  [MMC_HS_200]  = 2,
+ [MMC_HS_400]  = 2,
};
 
if (mode == MMC_LEGACY)
@@ -769,6 +771,11 @@ static int mmc_set_card_speed(struct mmc *mmc, enum 
bus_mode mode)
case MMC_HS_200:
speed_bits = EXT_CSD_TIMING_HS200;
break;
+#endif
+#if CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+   case MMC_HS_400:
+   speed_bits = EXT_CSD_TIMING_HS400;
+   break;
 #endif
case MMC_LEGACY:
speed_bits = EXT_CSD_TIMING_LEGACY;
@@ -816,7 +823,7 @@ static int mmc_get_capabilities(struct mmc *mmc)
 
mmc->card_caps |= MMC_MODE_4BIT | MMC_MODE_8BIT;
 
-   cardtype = ext_csd[EXT_CSD_CARD_TYPE] & 0x3f;
+   cardtype = ext_csd[EXT_CSD_CARD_TYPE];
mmc->cardtype = cardtype;
 
 #if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
@@ -824,6 +831,12 @@ static int mmc_get_capabilities(struct mmc *mmc)
EXT_CSD_CARD_TYPE_HS200_1_8V)) {
mmc->card_caps |= MMC_MODE_HS200;
}
+#endif
+#if CONFIG_IS_ENABLED(MMC_HS400_SUPPORT)
+   if (cardtype & (EXT_CSD_CARD_TYPE_HS400_1_2V |
+   EXT_CSD_CARD_TYPE_HS400_1_8V)) {
+   mmc->card_caps |= MMC_MODE_HS400;
+   }
 #endif
if (cardtype & EXT_CSD_CARD_TYPE_52) {
if (cardtype & EXT_CSD_CARD_TYPE_DDR_52) @@ -1734,10 +1747,13 
@@ static int mmc_set_lowest_voltage(struct mmc *mmc, enum bus_mode mode,
u32 card_mask = 0;
 
switch (mode) {
+   case MMC_HS_400:
case MMC_HS_200:
-   if (mmc->cardtype & EXT_CSD_CARD_TYPE_HS200_1_8V)
+   if (mmc->cardtype & (EXT_CSD_CARD_TYPE_HS200_1_8V |
+   EXT_CSD_CARD_TYPE_HS400_1_8V))
card_mask |= MMC_SIGNAL_VOLTAGE_180;
-   if (mmc->cardtype & EXT_CSD_CARD_TYPE_HS200_1_2V)
+   if (mmc->cardtype & (EXT_CSD_CARD_TYPE_HS200_1_2V |
+   EXT_CSD_CARD_TYPE_HS400_1_2V))
card_mask |= MMC_SIGNAL_VOLTAGE_120;
break;
case MMC_DDR_52:
@@ -1773,6 +1789,13 @@ static inline int mmc_set_lowest_voltage(struct mmc 
*mmc, enum bus_mode mode,  #endif
 
 static const struct mode_width_tuning mmc_modes_by_pref[] = 

[U-Boot] [PATCH 0/1] Update instructions for HiSilicon HiKey board

[Manivannan Sadhasivam]

Update the board instructions for the HiSilicon HiKey development
board based on the latest source available at 96Boards repositories.
These instructions are tested on the Lemaker HiKey board.

Thanks,
Mani

Manivannan Sadhasivam (1):
  hisilicon: hikey: Update instructions based on latest source

 board/hisilicon/hikey/README | 259 +++
 1 file changed, 113 insertions(+), 146 deletions(-)

-- 
2.17.1

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

[U-Boot] [PATCH 1/1] hisilicon: hikey: Update instructions based on latest source

[Manivannan Sadhasivam]

Update the HiKey board instructions based on the latest source
available. These instructions are derived from the ATF platform doc.
While updating the instructions, some comments on ATF issue has been
removed since it is fixed in latest ATF source.

Signed-off-by: Manivannan Sadhasivam 
---
 board/hisilicon/hikey/README | 259 +++
 1 file changed, 113 insertions(+), 146 deletions(-)

diff --git a/board/hisilicon/hikey/README b/board/hisilicon/hikey/README
index 4c2021f5097..94e8397e9b2 100644
--- a/board/hisilicon/hikey/README
+++ b/board/hisilicon/hikey/README
@@ -10,11 +10,10 @@ HiKey is the first certified 96Boards Consumer Edition 
board. The board/SoC has:
 * 802.11a/b/g/n WiFi, Bluetooth
 
 The HiKey schematic can be found here: -
-https://github.com/96boards/documentation/blob/master/hikey/96Boards-Hikey-Rev-A1.pdf
+https://github.com/96boards/documentation/blob/master/consumer/hikey/hikey620/hardware-docs/HiKey_schematics_LeMaker_version_Rev_A1.pdf
 
-A SoC datasheet can be found here: -
-https://github.com/96boards/documentation/blob/master/hikey/
-Hi6220V100_Multi-Mode_Application_Processor_Function_Description.pdf
+The SoC datasheet can be found here: -
+https://github.com/96boards/documentation/blob/master/consumer/hikey/hikey620/hardware-docs/Hi6220V100_Multi-Mode_Application_Processor_Function_Description.pdf
 
 Currently the u-boot port supports: -
 * USB
@@ -32,18 +31,20 @@ First get all the sources
 
   > mkdir -p ~/hikey/src ~/hikey/bin
   > cd ~/hikey/src
-  > git clone https://github.com/96boards/edk2.git
-  > git clone https://github.com/96boards/arm-trusted-firmware.git
-  > git clone https://github.com/96boards/l-loader.git
-  > git clone https://github.com/96boards/burn-boot.git
+  > git clone https://github.com/96boards-hikey/edk2 -b testing/hikey960_v2.5
+  > git clone https://github.com/ARM-software/arm-trusted-firmware
+  > git clone https://github.com/96boards-hikey/l-loader -b 
testing/hikey960_v1.2
+  > git clone https://github.com/96boards-hikey/OpenPlatformPkg -b 
testing/hikey960_v1.3.4
+  > git clone https://github.com/96boards-hikey/atf-fastboot
+  > wget 
https://snapshots.linaro.org/96boards/reference-platform/components/uefi-staging/latest/hikey/release/hisi-idt.py
 
 Get the BL30 mcuimage.bin binary. It is shipped as part of the UEFI source.
-The latest version can be obtained from the edk2 repo.
+The latest version can be obtained from the OpenPlatformPkg repo.
 
-  > cp edk2/HisiPkg/HiKeyPkg/NonFree/mcuimage.bin ~/hikey/bin/
+  > cp OpenPlatformPkg/Platforms/Hisilicon/HiKey/Binary/mcuimage.bin 
~/hikey/bin/
 
-Get nvme.img binary (check this link is still the latest)
-  > wget -P ~/hikey/bin 
https://builds.96boards.org/releases/reference-platform/debian/hikey/16.03/bootloader/nvme.img
+Get nvme.img binary
+  > wget -P ~/hikey/bin 
https://snapshots.linaro.org/96boards/reference-platform/components/uefi-staging/latest/hikey/release/nvme.img
 
 Compile U-Boot
 ==
@@ -58,34 +59,45 @@ Compile ARM Trusted Firmware (ATF)
 
   > cd ~/hikey/src/arm-trusted-firmware
   > make CROSS_COMPILE=aarch64-linux-gnu- all fip \
-BL30=~/hikey/bin/mcuimage.bin \
+SCP_BL2=~/hikey/bin/mcuimage.bin \
 BL33=~/hikey/bin/u-boot.bin DEBUG=1 PLAT=hikey
 
-Copy resulting binaries
-  > cp build/hikey/debug/bl1.bin ~/hikey/bin
+Copy the resulting FIP binary
   > cp build/hikey/debug/fip.bin ~/hikey/bin
 
+Compile ATF Fastboot
+
+
+  > cd ~/hikey/src/atf-fastboot
+  > make CROSS_COMPILE=aarch64-linux-gnu- PLAT=hikey DEBUG=1
+
 Compile l-loader
-===
+
   > cd ~/hikey/src/l-loader
-  > make BL1=~/hikey/bin/bl1.bin all
+  > ln -sf ~/hikey/src/arm-trusted-firmware/build/hikey/debug/bl1.bin
+  > ln -sf ~/hikey/src/arm-trusted-firmware/build/hikey/debug/bl2.bin
+  > ln -sf ~/hikey/src/atf-fastboot/build/hikey/debug/bl1.bin fastboot.bin
+  > make hikey PTABLE_LST=aosp-8g
+
+Copy the resulting binaries
   > cp *.img ~/hikey/bin
   > cp l-loader.bin ~/hikey/bin
+  > cp recovery.bin ~/hikey/bin
 
 These instructions are adapted from
-https://github.com/96boards/documentation/wiki/HiKeyUEFI
+https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/hikey.rst
 
 FLASHING
 
 
 1. Connect the second jumper on J15 BOOT SEL, to go into recovery mode and 
flash l-loader.bin with
-the hisi-idt.py utility.
+the hisi-idt.py utility. Then connect a USB A to B mini cable from your PC to 
the USB OTG port of HiKey and execute the below command.
 
 The command below assumes HiKey enumerated as the first USB serial port
-  > sudo ~/hikey/src/burn-boot/hisi-idt.py -d /dev/ttyUSB0 
--img1=~/hikey/bin/l-loader.bin
 
-2. Once LED 0 comes on solid, HiKey board should be detected as a fastboot 
device by plugging a USB A to mini B
-   cable from your PC to the USB OTG port of HiKey (on some boards I've found 
this to be unreliable).
+  > sudo python ~/hikey/src/hisi-idt.py -d /dev/ttyUSB0 --img1 

[U-Boot] [v3 patch] net: fman: Support both new and legacy FMan Compatibles

[Zhao Qiang]

Recently  the FMan Port and MAC compatibles were changed.
This patch aligns the FMan Port and MAC compatibles
to the new FMan device tree binding document.
The FMan device tree binding document can be found in the Linux
kernel:
version 3.18.0
commit 297d35fd2a7d3fbd4e5c0f0c1c18213117ba11ba
./Documentation/devicetree/bindings/powerpc/fsl/fman.txt

This patch doesn't affect legacy compatibles support.

Signed-off-by: Zhao Qiang 
---
Changes for v2
- add kernel version and commit id modifing the binding
Changes for v3
- put "fsl,fman-xgec" before "fsl,fman-tgec"
- because it use the former in latest kernel version

 drivers/net/fm/init.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/net/fm/init.c b/drivers/net/fm/init.c
index 147d043..f896e80 100644
--- a/drivers/net/fm/init.c
+++ b/drivers/net/fm/init.c
@@ -328,7 +328,8 @@ void fdt_fixup_fman_ethernet(void *blob)
ft_fixup_port(blob, _info[i],
  "fsl,fman-1g-mac");
} else {
-   if (ft_fixup_port(blob, _info[i], "fsl,fman-tgec"))
+   if (ft_fixup_port(blob, _info[i], "fsl,fman-xgec") &&
+   ft_fixup_port(blob, _info[i], "fsl,fman-tgec"))
ft_fixup_port(blob, _info[i],
  "fsl,fman-10g-mac");
}
-- 
1.7.1

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

Re: [U-Boot] u-boot release and feature set

[Prabhakar Kushwaha]

Thanks Tom for responding,

> -Original Message-
> From: Tom Rini 
> Sent: Wednesday, August 29, 2018 7:28 AM
> To: Prabhakar Kushwaha 
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] u-boot release and feature set
> 
> On Tue, Aug 28, 2018 at 06:48:13AM +, Prabhakar Kushwaha wrote:
> 
> > Hi Tom,
> >
> > Every u-boot release announcement has a very high level feature set.
> > I am wondering, if you also maintain detailed feature list  per u-boot
> release?
> >
> > I can see "Statistics" details per release from https://www.denx.de/wiki/U-
> Boot/ReleaseCycle but not the feature set.
> > May be I am looking at wrong place ☹
> 
> It's been asked from time to time but I am simply bad about it.  I had tried
> parsing the git logs every -rc to come up with something more detailed, but
> that didn't last.  If more people did signed tags that would provide some
> useful information for a detailed changelog.
> 
Feature set is good thing to have per release. It help us in taking decision of 
upreving u-boot (now or later). 

A suggestion, can we ask feature set details in every pull request from 
sub-maintainers. 
Or
A blog can also be maintained, where sub-maintainer can write feature set per 
pull request. 

Sub-maintainers have better idea what feature they are providing.  
Feature set can also be published per sub-system (instead of pick and choose).  

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

Re: [U-Boot] u-boot release and feature set

[Tom Rini]

On Tue, Aug 28, 2018 at 06:48:13AM +, Prabhakar Kushwaha wrote:

> Hi Tom,
> 
> Every u-boot release announcement has a very high level feature set.
> I am wondering, if you also maintain detailed feature list  per u-boot 
> release? 
> 
> I can see "Statistics" details per release from 
> https://www.denx.de/wiki/U-Boot/ReleaseCycle but not the feature set.
> May be I am looking at wrong place ☹

It's been asked from time to time but I am simply bad about it.  I had
tried parsing the git logs every -rc to come up with something more
detailed, but that didn't last.  If more people did signed tags that
would provide some useful information for a detailed changelog.

-- 
Tom


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

Re: [U-Boot] [PATCH] TPL/SPL: add separate CONFIG_TPL_FRAMEWORK for TPL

[Tom Rini]

On Tue, Aug 28, 2018 at 09:11:35PM +0800, Kever Yang wrote:

> Hi Tom,
> 
> 
> On 08/28/2018 08:49 PM, Tom Rini wrote:
> > On Tue, Aug 28, 2018 at 04:51:26PM +0800, Kever Yang wrote:
> >
> >> SPL_FRAMEWORK is a set of framework feature, we may not need the
> >> fromework for both TPL and SPL at the same time, so add a separate
> >> one for TPL.
> >>
> >> Signed-off-by: Kever Yang 
> >> ---
> >>
> >>  Makefile  | 2 +-
> >>  arch/arm/lib/Makefile | 4 ++--
> >>  arch/arm/lib/crt0.S   | 6 +-
> >>  common/spl/Kconfig| 9 +
> >>  common/spl/Makefile   | 2 +-
> >>  scripts/Makefile.spl  | 4 
> >>  6 files changed, 22 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/Makefile b/Makefile
> >> index 4b3023b259..68b77d1e43 100644
> >> --- a/Makefile
> >> +++ b/Makefile
> >> @@ -822,7 +822,7 @@ endif
> >>  endif
> >>  ALL-$(CONFIG_TPL) += tpl/u-boot-tpl.bin
> >>  ALL-$(CONFIG_OF_SEPARATE) += u-boot.dtb
> >> -ifeq ($(CONFIG_SPL_FRAMEWORK),y)
> >> +ifeq ($(CONFIG_TPL_FRAMEWORK),y)
> >>  ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img
> >>  endif
> >>  ALL-$(CONFIG_OF_HOSTFILE) += u-boot.dtb
> > We should be adding a new stanza here and not replacing the SPL one I
> > would think.
> This may not need,  I though this is for TPL because it's just after
> target for CONFIG_TPL.
> Will drop this part next version.
> >
> > [snip]
> >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> >> index db1915fe5c..1a2e10b892 100644
> >> --- a/common/spl/Kconfig
> >> +++ b/common/spl/Kconfig
> >> @@ -813,6 +813,15 @@ config TPL
> >>help
> >>  If you want to build TPL as well as the normal image and SPL, say Y.
> >>  
> >> +config TPL_FRAMEWORK
> >> +  bool "Support TPL based upon the common TPL framework"
> >> +  depends on TPL
> >> +  default y
> >> +  help
> >> +Enable the TPL framework under common/spl/.  This framework
> >> +re-use the all the framework feature from SPL but enable separetely.
> >> +If unsure, say Y.
> > This shouldn't be default y, and the help shouldn't suggest that either
> > I think.  My concern with this series is TPL wasn't intended to get too
> > featureful.  Our initial constraints are enough that we need something
> > to init DDR and load SPL into that as we can't do enough with our
> > limited resources to load full U-Boot.  In fact, looking at the follow
> > up rockchip specific patch that's more in line what my expectations.  So
> > I think you should be able to get TPL to do what you want without
> > introducing TPL_FRAMEWORK.  Thanks!
> I have to introducing  TPL_FRAMEWORK because the SPL_FRAMEWORK
> is shared by TPL and SPL, if I have enable TPL and SPL, then:
> - I would like to use TPL without framework(which refers to DM, common
> lib and FDT);
> - I would like to use SPL with SPL_FRAMEWORK
> If there is no TPL_FRAMEWORK, then I'm not sure if I can use the
> TINY_FRAMEWORK
> to overwrite everything.
> 
> 
> I introduce TINY_FRAMEWORK is to remove other program like vector table,
> runtime C init, which is not include in SPL_FRAMEWORK now.

First, please make sure that your next series here has been through
travis-ci or you've built some of the PowerPC targets (say
./tools/buildman/buildman.py p1_p2) as I'm pretty sure TPL_FRAMEWORK
being on by default breaks them.

Next, I'm still not quite following, sorry.  The way TPL is used
normally today (again, see PowerPC for the non-rockchip examples) does
not rely on the spl framework, and that's intentional as they have
extremely limited resources.  I still think you should be able to rework
things such that you don't need TPL_FRAMEWORK being set to them
overwrite most of it.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH v3 1/2] gpio: Add struct reset_ctl_bulk

[Marek Vasut]

On 08/29/2018 03:28 AM, Ley Foon Tan wrote:
> On Tue, Aug 28, 2018 at 5:53 PM Marek Vasut  wrote:
>>
>> On 08/28/2018 06:07 PM, Ley Foon Tan wrote:
>>> Add struct reset_ctl_bulk to struct gpio_dev_priv to support reset control
>>> in GPIO driver.
>>>
>>> Signed-off-by: Ley Foon Tan 
>>
>> Isn't this reset support supposed to be driver specific, and thus part
>> of driver private data ?
> 
> Just notice not all gpio node have sub gpio port node. platdata in
> dwgpio drivers is per gpio port.
> Will abandon this patch and add a platdata struct for dwgpio parent device.

That's probably a good idea.

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

Re: [U-Boot] [PATCH v3 1/2] gpio: Add struct reset_ctl_bulk

[Ley Foon Tan]

On Tue, Aug 28, 2018 at 5:53 PM Marek Vasut  wrote:
>
> On 08/28/2018 06:07 PM, Ley Foon Tan wrote:
> > Add struct reset_ctl_bulk to struct gpio_dev_priv to support reset control
> > in GPIO driver.
> >
> > Signed-off-by: Ley Foon Tan 
>
> Isn't this reset support supposed to be driver specific, and thus part
> of driver private data ?

Just notice not all gpio node have sub gpio port node. platdata in
dwgpio drivers is per gpio port.
Will abandon this patch and add a platdata struct for dwgpio parent device.

>
> > ---
> >  include/asm-generic/gpio.h |2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
> > index d036026..9fd5808 100644
> > --- a/include/asm-generic/gpio.h
> > +++ b/include/asm-generic/gpio.h
> > @@ -8,6 +8,7 @@
> >  #define _ASM_GENERIC_GPIO_H_
> >
> >  #include 
> > +#include 
> >
> >  struct ofnode_phandle_args;
> >
> > @@ -318,6 +319,7 @@ struct gpio_dev_priv {
> >   unsigned gpio_count;
> >   unsigned gpio_base;
> >   char **name;
> > + struct reset_ctl_bulk resets;
> >  };
> >
> >  /* Access the GPIO operations for a device */
> >
>
>
Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3] usb: dwc2: Add reset ctrl to driver

[Marek Vasut]

On 08/29/2018 02:52 AM, Ley Foon Tan wrote:
> On Tue, Aug 28, 2018 at 5:53 PM Marek Vasut  wrote:
>>
>> On 08/28/2018 06:08 PM, Ley Foon Tan wrote:
>>> Add code to reset all reset signals as in usb DT node. A reset property
>>> is an optional feature, so only print out a warning and do not fail if a
>>> reset property is not present.
>>>
>>> If a reset property is discovered, then use it to deassert, thus
>>> bringing the IP out of reset.
>>>
>>> Signed-off-by: Ley Foon Tan 
>>>
>>> ---
>>> v3:
>>> - Add error handling when return non-zero from reset_get_bulk().
>>>
>>> v2:
>>> - Add reset_release_bulk() in _remove function.
>>> ---
>>>  drivers/usb/host/dwc2.c |   37 +
>>>  1 files changed, 37 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
>>> index cbe065b..b6f008a 100644
>>> --- a/drivers/usb/host/dwc2.c
>>> +++ b/drivers/usb/host/dwc2.c
>>> @@ -15,6 +15,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>>  #include "dwc2.h"
>>>
>>> @@ -49,6 +50,8 @@ struct dwc2_priv {
>>>*/
>>>   bool hnp_srp_disable;
>>>   bool oc_disable;
>>> +
>>> + struct reset_ctl_bulk   resets;
>>>  };
>>>
>>>  #ifndef CONFIG_DM_USB
>>> @@ -1124,11 +1127,43 @@ int _submit_int_msg(struct dwc2_priv *priv, struct 
>>> usb_device *dev,
>>>   }
>>>  }
>>>
>>> +static int dwc2_reset(struct udevice *dev)
>>> +{
>>> + int ret;
>>> + struct dwc2_priv *priv = dev_get_priv(dev);
>>> +
>>> + ret = reset_get_bulk(dev, >resets);
>>> + if (ret) {
>>> + dev_warn(dev, "Can't get reset: %d\n", ret);
>>> + /* Return 0 if error due to !CONFIG_DM_RESET and reset
>>> +  * DT property is not present.
>>> +  */
>>> + if (ret == -ENOENT || ret == -ENOTSUPP)
>>> + return 0;
>>> + else
>>> + return ret;
>>> + }
>>> +
>>> + ret = reset_deassert_bulk(>resets);
>>> + if (ret) {
>>> + reset_release_bulk(>resets);
>>> + dev_err(dev, "Failed to reset: %d\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>>  static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
>>>  {
>>>   struct dwc2_core_regs *regs = priv->regs;
>>>   uint32_t snpsid;
>>>   int i, j;
>>> + int ret;
>>> +
>>> + ret = dwc2_reset(dev);
>>> + if (ret)
>>> + return ret;
>>>
>>>   snpsid = readl(>gsnpsid);
>>>   dev_info(dev, "Core Release: %x.%03x\n",
>>> @@ -1303,6 +1338,8 @@ static int dwc2_usb_remove(struct udevice *dev)
>>>
>>>   dwc2_uninit_common(priv->regs);
>>>
>>
>> Don't you need to assert the reset here ?
> reset_release_bulk() function will assert the reset and free reset struct.

Ah, OK, applied, thanks.

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

Re: [U-Boot] [PATCH v3 2/2] gpio: dwapb_gpio: Add reset ctrl to driver

[Ley Foon Tan]

On Tue, Aug 28, 2018 at 5:53 PM Marek Vasut  wrote:
>
> On 08/28/2018 06:07 PM, Ley Foon Tan wrote:
> > Add code to reset all reset signals as in gpio DT node. A reset property
> > is an optional feature, so only print out a warning and do not fail if a
> > reset property is not present.
> >
> > If a reset property is discovered, then use it to deassert, thus
> > bringing the IP out of reset.
> >
> > Signed-off-by: Ley Foon Tan 
> >
> > ---
> > v3:
> > - Add .remove function.
> > - Add error handling when return non-zero from reset_get_bulk().
> >
> > v2:
> > - Move reset to probe() function.
> > ---
> >  drivers/gpio/dwapb_gpio.c |   42 --
> >  1 files changed, 40 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
> > index 7cf2d47..6394fa9 100644
> > --- a/drivers/gpio/dwapb_gpio.c
> > +++ b/drivers/gpio/dwapb_gpio.c
> > @@ -15,6 +15,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -99,13 +100,42 @@ static const struct dm_gpio_ops gpio_dwapb_ops = {
> >   .get_function   = dwapb_gpio_get_function,
> >  };
> >
> > +static int gpio_dwapb_reset(struct udevice *dev)
> > +{
> > + int ret;
> > + struct gpio_dev_priv *priv = dev_get_uclass_priv(dev);
> > +
> > + ret = reset_get_bulk(dev, >resets);
> > + if (ret) {
> > + dev_warn(dev, "Can't get reset: %d\n", ret);
> > + /* Return 0 if error due to !CONFIG_DM_RESET and reset
> > +  * DT property is not present.
> > +  */
> > + if (ret == -ENOENT || ret == -ENOTSUPP)
> > + return 0;
> > + else
> > + return ret;
> > + }
> > +
> > + ret = reset_deassert_bulk(>resets);
> > + if (ret) {
> > + reset_release_bulk(>resets);
> > + dev_err(dev, "Failed to reset: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> >  static int gpio_dwapb_probe(struct udevice *dev)
> >  {
> >   struct gpio_dev_priv *priv = dev_get_uclass_priv(dev);
> >   struct gpio_dwapb_platdata *plat = dev->platdata;
> >
> > - if (!plat)
> > - return 0;
> > + if (!plat) {
> > + /* Reset on parent device only */
> > + return gpio_dwapb_reset(dev);
> > + }
> >
> >   priv->gpio_count = plat->pins;
> >   priv->bank_name = plat->name;
> > @@ -166,6 +196,13 @@ err:
> >   return ret;
> >  }
> >
> > +static int gpio_dwapb_remove(struct udevice *dev)
> > +{
> > + struct gpio_dev_priv *priv = dev_get_uclass_priv(dev);
>
> You might want to assert the reset too.

reset_release_bulk() function will assert the reset and free reset struct.

>
> > + return reset_release_bulk(>resets);
> > +}
> > +
> >  static const struct udevice_id gpio_dwapb_ids[] = {
> >   { .compatible = "snps,dw-apb-gpio" },
> >   { }
> > @@ -178,4 +215,5 @@ U_BOOT_DRIVER(gpio_dwapb) = {
> >   .ops= _dwapb_ops,
> >   .bind   = gpio_dwapb_bind,
> >   .probe  = gpio_dwapb_probe,
> > + .remove = gpio_dwapb_remove,
> >  };
> >
>
>
Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3] usb: dwc2: Add reset ctrl to driver

[Ley Foon Tan]

On Tue, Aug 28, 2018 at 5:53 PM Marek Vasut  wrote:
>
> On 08/28/2018 06:08 PM, Ley Foon Tan wrote:
> > Add code to reset all reset signals as in usb DT node. A reset property
> > is an optional feature, so only print out a warning and do not fail if a
> > reset property is not present.
> >
> > If a reset property is discovered, then use it to deassert, thus
> > bringing the IP out of reset.
> >
> > Signed-off-by: Ley Foon Tan 
> >
> > ---
> > v3:
> > - Add error handling when return non-zero from reset_get_bulk().
> >
> > v2:
> > - Add reset_release_bulk() in _remove function.
> > ---
> >  drivers/usb/host/dwc2.c |   37 +
> >  1 files changed, 37 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> > index cbe065b..b6f008a 100644
> > --- a/drivers/usb/host/dwc2.c
> > +++ b/drivers/usb/host/dwc2.c
> > @@ -15,6 +15,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "dwc2.h"
> >
> > @@ -49,6 +50,8 @@ struct dwc2_priv {
> >*/
> >   bool hnp_srp_disable;
> >   bool oc_disable;
> > +
> > + struct reset_ctl_bulk   resets;
> >  };
> >
> >  #ifndef CONFIG_DM_USB
> > @@ -1124,11 +1127,43 @@ int _submit_int_msg(struct dwc2_priv *priv, struct 
> > usb_device *dev,
> >   }
> >  }
> >
> > +static int dwc2_reset(struct udevice *dev)
> > +{
> > + int ret;
> > + struct dwc2_priv *priv = dev_get_priv(dev);
> > +
> > + ret = reset_get_bulk(dev, >resets);
> > + if (ret) {
> > + dev_warn(dev, "Can't get reset: %d\n", ret);
> > + /* Return 0 if error due to !CONFIG_DM_RESET and reset
> > +  * DT property is not present.
> > +  */
> > + if (ret == -ENOENT || ret == -ENOTSUPP)
> > + return 0;
> > + else
> > + return ret;
> > + }
> > +
> > + ret = reset_deassert_bulk(>resets);
> > + if (ret) {
> > + reset_release_bulk(>resets);
> > + dev_err(dev, "Failed to reset: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> >  static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
> >  {
> >   struct dwc2_core_regs *regs = priv->regs;
> >   uint32_t snpsid;
> >   int i, j;
> > + int ret;
> > +
> > + ret = dwc2_reset(dev);
> > + if (ret)
> > + return ret;
> >
> >   snpsid = readl(>gsnpsid);
> >   dev_info(dev, "Core Release: %x.%03x\n",
> > @@ -1303,6 +1338,8 @@ static int dwc2_usb_remove(struct udevice *dev)
> >
> >   dwc2_uninit_common(priv->regs);
> >
>
> Don't you need to assert the reset here ?
reset_release_bulk() function will assert the reset and free reset struct.
>
> > + reset_release_bulk(>resets);
> > +
> >   return 0;
> >  }
> >
> >
>
Regards
Ley Foon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 3/7] drivers: net: designware: Add reading of DT phy-handle node

[Grygorii Strashko]

On 08/28/2018 01:25 AM, Janine Hagemann wrote:

Add the ability to read the phy-handle node of the
gmac.  Upon reading this handle the phy-id
can be stored based on the reg node in the DT.

The phy-handle also needs to be stored and passed
to the phy to access any phy data that is available.

Signed-off-by: Janine Hagemann 
Acked-by: Joe Hershberger 
---
v4: Change used function from dev_set_of_offset( ) to
 offset_to_ofnode( )
---
  drivers/net/designware.c | 11 ++-
  drivers/net/designware.h |  1 +
  2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 19db0a8..bba12f2 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -477,7 +477,7 @@ static int dw_phy_init(struct dw_eth_dev *priv, void *dev)
  {
struct phy_device *phydev;
int mask = 0x, ret;
-
+   struct dw_eth_pdata *dw_pdata = dev_get_platdata(dev);
  #ifdef CONFIG_PHY_ADDR
mask = 1 << CONFIG_PHY_ADDR;
  #endif
@@ -496,6 +496,11 @@ static int dw_phy_init(struct dw_eth_dev *priv, void *dev)
}
phydev->advertising = phydev->supported;
  
+#ifdef CONFIG_DM_ETH

+   if (dw_pdata->phy_of_handle)
+   phydev->node  = offset_to_ofnode(dw_pdata->phy_of_handle);
+#endif
+


Above part looks good now. thank you.

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

[U-Boot] [PATCH] tools: mkimage: Ensure munmap unmaps the same length that was mapped

[Chris Packham]

From: Mark Tomlinson 

The set_header call in kwbimage.c adds a checksum to the end of the
image in addition to setting up the header. It 'helpfully' updates the
st_size to match the fact that the file is now longer. However, mkimage
uses this length in the munmap call. This can lead to unmapping an extra
page, of perhaps required data. When this happens, a SEGV can occur.

To prevent this from happening, the munmap call now uses the same length
that was passed to mmap. This could also have been fixed by not changing
the length in kwbimage.c, however changing it in the main file means
that other plugins will also not fall for the same trap.

Signed-off-by: Mark Tomlinson 
Signed-off-by: Chris Packham 
[cp: resolve checkpatch complaints]
Tested-by: Chris Packham 
---

 tools/mkimage.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index e0d4d20be499..6abd4d6a8b22 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -318,6 +318,7 @@ int main(int argc, char **argv)
struct image_type_params *tparams = NULL;
int pad_len = 0;
int dfd;
+   size_t map_len;
 
params.cmdname = *argv;
params.addr = 0;
@@ -576,7 +577,8 @@ int main(int argc, char **argv)
}
params.file_size = sbuf.st_size;
 
-   ptr = mmap(0, sbuf.st_size, PROT_READ|PROT_WRITE, MAP_SHARED, ifd, 0);
+   map_len = sbuf.st_size;
+   ptr = mmap(0, map_len, PROT_READ | PROT_WRITE, MAP_SHARED, ifd, 0);
if (ptr == MAP_FAILED) {
fprintf (stderr, "%s: Can't map %s: %s\n",
params.cmdname, params.imagefile, strerror(errno));
@@ -600,7 +602,7 @@ int main(int argc, char **argv)
params.cmdname, tparams->name);
}
 
-   (void) munmap((void *)ptr, sbuf.st_size);
+   (void)munmap((void *)ptr, map_len);
 
/* We're a bit of paranoid */
 #if defined(_POSIX_SYNCHRONIZED_IO) && \
-- 
2.18.0

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

[U-Boot] mkimage (kwbimage) unmapping more bytes than it maps

[Chris Packham]

Hi,

Mark and I have been looking at a problem we've been experiencing on
our build system.

We're running a number of similarly configured makers and seemingly
randomly one will fail to build one of our kirkwood based targets
(specifically the SBx81LIFXCAT that was recently added) with a
segfault in mkimage. When I tried to run the same build it would work
fine on my PC (in theory the same base install as the makers).

I'd been blaming specific makers as having bad RAM (these things get
hammered so we've had them die before) but Mark managed to track it
down to mmap and munmap disagreeing on the size of the area mapped.
You can see this by running strace on mkimage

strace -y ./tools/mkimage -n ./arch/arm/mach-mvebu/kwbimage.cfg -T
kwbimage -a 0x0080 -e 0x0080 -d u-boot.img u-boot-spl.kwb
...
mmap(NULL, 641024, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7f1b5ce3e000
...
munmap(0x7f1b5ce3e000, 641028) = 0

Note that the size has been incremented by 4. Most of the time this is
harmless but on our build system the size of the image worked out to
an exact multiple of the page size so the munmap ended up spilling
over and unmapping another page which depending on the in-memory
layout of the process could result in a segfault.

This extra 4 bytes comes from kwbimage.c. Towards the end of
kwbimage_set_header() we have

checksum = cpu_to_le32(image_checksum32((uint32_t *)ptr, sbuf->st_size));
size = write(ifd, , sizeof(uint32_t));
...
sbuf->st_size += sizeof(uint32_t);

The st_size increment seems like a leftover from commit 4acd2d24b651
("tools: kwbimage: Add image version 1 support for Armada XP / 370")
as aside from the munmap in mkimage nothing else uses it.

This is where Mark and I disagree. A minimal change would simply to
remove the increment of st_size from kwbimage.c. But a more robust fix
would be to have mkimage not trust sbuf after it's been passed to
tparams->set_header.

Is there are preference for how to handle this? I'll follow up this
mail with Marks proposed fix.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] amlogic: board p212: Fix Ethernet PHY init

[Jasper Kcoding]

Without this patch the Ethernet PHY on the p212 board does not get fully 
configured.
When this happens Ethernet does not function.

The similar libretech-cc and khadas-vim boards have this code already.
That's why the Ethernet on these boards do work.
---
 board/amlogic/p212/p212.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/amlogic/p212/p212.c b/board/amlogic/p212/p212.c
index 06c2eaee47..d5ce5397f3 100644
--- a/board/amlogic/p212/p212.c
+++ b/board/amlogic/p212/p212.c
@@ -29,7 +29,7 @@ int misc_init_r(void)
char serial[EFUSE_SN_SIZE];
ssize_t len;
 
-   meson_gx_eth_init(PHY_INTERFACE_MODE_RMII, 0);
+   meson_gx_eth_init(PHY_INTERFACE_MODE_RMII, 
MESON_GXL_USE_INTERNAL_RMII_PHY);
 
if (!eth_env_get_enetaddr("ethaddr", mac_addr)) {
len = meson_sm_read_efuse(EFUSE_MAC_OFFSET,
-- 
2.11.0

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

Re: [U-Boot] [PATCH v3 19/58] clk: sunxi: Implement direct MMC clocks

[Jagan Teki]

On Tue, Aug 28, 2018 at 3:21 PM, Maxime Ripard
 wrote:
> On Mon, Aug 27, 2018 at 03:34:20PM +0530, Jagan Teki wrote:
>> >> diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
>> >> index fb11231dd1..55176bc174 100644
>> >> --- a/drivers/clk/sunxi/clk_a10.c
>> >> +++ b/drivers/clk/sunxi/clk_a10.c
>> >> @@ -23,6 +23,11 @@ static struct ccu_clk_map a10_clks[] = {
>> >>   [CLK_AHB_MMC2]  = { 0x060, BIT(10), NULL },
>> >>   [CLK_AHB_MMC3]  = { 0x060, BIT(11), NULL },
>> >>
>> >> + [CLK_MMC0]  = { 0x088, BIT(31), _clk_set_rate },
>> >> + [CLK_MMC1]  = { 0x08c, BIT(31), _clk_set_rate },
>> >> + [CLK_MMC2]  = { 0x090, BIT(31), _clk_set_rate },
>> >> + [CLK_MMC3]  = { 0x094, BIT(31), _clk_set_rate },
>> >> +
>> >>   [CLK_USB_OHCI0] = { 0x0cc, BIT(6), NULL },
>> >>   [CLK_USB_OHCI1] = { 0x0cc, BIT(7), NULL },
>> >>   [CLK_USB_PHY]   = { 0x0cc, BIT(8), NULL },
>> >> diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
>> >> index bc4ae7352b..fbac0ad751 100644
>> >> --- a/drivers/clk/sunxi/clk_a10s.c
>> >> +++ b/drivers/clk/sunxi/clk_a10s.c
>> >> @@ -20,6 +20,12 @@ static struct ccu_clk_map a10s_clks[] = {
>> >>   [CLK_AHB_MMC1]  = { 0x060, BIT(9), NULL },
>> >>   [CLK_AHB_MMC2]  = { 0x060, BIT(10), NULL },
>> >>
>> >> +#ifdef CONFIG_MMC
>> >> + [CLK_MMC0]  = { 0x088, BIT(31), _clk_set_rate },
>> >> + [CLK_MMC1]  = { 0x08c, BIT(31), _clk_set_rate },
>> >> + [CLK_MMC2]  = { 0x090, BIT(31), _clk_set_rate },
>> >> +#endif
>> >> +
>> >
>> > I'm not too sure about the ifdef here. Or at least, we should be
>> > consistent, and if we do it for the MMC, we should do it for all the
>> > SoCs (including the A10), and for all the controllers (including USB,
>> > for example).
>>
>> because few of sun5i boards not using MMC, example CHIP and CHIP_pro
>> otherwise we need to use intermediate wrapper to call
>> mmc_clk_set_rate.
>
> Well, yes, but you can make the same argument for other SoCs, and
> other features. So really, I think this is a good idea, but if we
> remain consistent between SoCs and features.

True, I see adding wrapper make consistent on these descriptor table,
so the wrapper will call the actual set_rate, of course we need to add
ifdef in wrapper for non-MMC targets or __weak function.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image

[Dalon L Westergreen]

On Tue, 2018-08-28 at 17:51 +0200, Marek Vasut wrote:
> On 08/28/2018 05:43 PM, Dalon L Westergreen wrote:
> 
> On Tue, 2018-08-28 at 01:54 +0200, Marek Vasut wrote:
> 
> On 08/28/2018 12:03 AM, Dalon L Westergreen wrote:
> On Mon, 2018-08-27 at 21:03 +0200, Marek Vasut wrote:
> On 08/27/2018 05:30 PM, Dalon L Westergreen wrote:
> On Tue, 2018-08-21 at 05:52 +0200, Marek Vasut wrote:
> On 08/20/2018 11:04 PM, Dalon L Westergreen wrote:
> On Mon, 2018-08-20 at 20:33 +0200, Marek Vasut wrote:
> On 08/20/2018 03:54 PM, Dalon Westergreen wrote:
> Stratix10 requires a hex image of the spl for boot.  The hex
> image is added to the FPGA configuration image and loaded to
> the processor memory by the configuration engine.
> 
> Signed-off-by: Dalon Westergreen    >    >>    >    
> ---
>  scripts/Makefile.spl | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index 76d08fd92b..c424f87e6e 100644
> --- a/scripts/Makefile.spl
> +++ b/scripts/Makefile.spl
> @@ -190,6 +190,7 @@ endif
>  ifdef CONFIG_ARCH_SOCFPGA
>  ALL-$(CONFIG_TARGET_SOCFPGA_GEN5)+= $(obj)/$(SPL_BIN).sfp
>  ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp
> +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10)   += $(obj)/$(SPL_BIN).hex
>  endif
>  
>  ifdef CONFIG_ARCH_SUNXI
> @@ -299,6 +300,15 @@ OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j 
> .start16 -j .resetvec
>  $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE
>   $(call if_changed,objcopy)
>  
> +ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
> +OBJCOPYFLAGS_$(SPL_BIN).hex = -I binary -O ihex --change-addresses 0xffe0
> 
> Why is this --change-address needed ? This smells like a hack of some
> sort ...
> 
> I believe the tool that uses this file expects this offset, that said i have 
> not
> 
> tried using a hex file without this change address applied.  I will try 
> without 
> 
> this, and see what happens.
> 
> You probably need to adjust the link address of the SPL or U-Boot too.
> 
> The link address appears to be correctly set to 0xffe0 which is the 
> location of the onchip ram.  
> 
> The quartus_cpf tool itself errors out when the --change-address option is 
> not used.  The quartus_cpf 
> 
> checks that the address range of the hex is entirely within the onchip ram.  
> My suggestion would
> 
> be to leave the --change-address option as is.  
> 
> So what is _not_ in the onchip RAM then ? Is something sticking out of
> the OCRAM , that's why the quartus_cpf fails ? Maybe that's something
> you should fix.
> 
> Thanks Marek, I'm m not very familiar with the hex format
> 
> The intel ihex is terrible (sorry), it's really hard to decode. But
> here's some example:
> https://en.wikipedia.org/wiki/Intel_HEX
> 
> but there only 2 lines that differ when
> 
> using the change address option, the first and last, of the hex. 
> 
> 
> in the file with the change-address option :0204FFE01B is prepended to 
> the file, and 
> 
> :0405FFE018 is added to the second to last line.  It is followed by 
> :0001FF (end of file).
> 
> 
> My belief is the change-address is simply specifying the start address of the 
> hex data converted from
> 
> the binary.  This offset is required by the quartus_cpf tool as a form of 
> validation.
> 
> This is what objcopy(1) says:
> 
>--change-addresses incr
>--adjust-vma incr
>Change the VMA and LMA addresses of all sections, as well as
> the start address, by adding incr.  Some object file formats do not
> permit section addresses to be changed
>arbitrarily.  Note that this does not relocate the sections;
> if the program expects sections to be loaded at a certain address, and
> this option is used to change the sections such
>that they are loaded at a different address, the program may
> fail.
> 
> So I ran make V=1 , to see how the hex file is generated, and this is how:
>   aarch64-linux-gnu-objcopy  -j .text -j .secure_text -j .secure_data -j
> .rodata -j .data -j .u_boot_list -j .rela.dyn -j .got -j .got.plt -j
> .binman_sym_table -j .text_rest -j .dtb.init.rodata -j .efi_runtime -j
> .efi_runtime_rel -I binary -O ihex --change-addresses 0xffe0
> spl/u-boot-spl.bin spl/u-boot-spl.hex
> 
> It's generated from u-boot-spl.bin , which is weird. The u-boot.hex is
> generated from u-boot (ELF binary). I think that's what the SPL hex
> should be generated from too, since the ELF binary contains all the
> relocation info.
> 
> So a target similar to u-boot.hex should do:
> 

Re: [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image

[Marek Vasut]

On 08/28/2018 05:43 PM, Dalon L Westergreen wrote:
> On Tue, 2018-08-28 at 01:54 +0200, Marek Vasut wrote:
>> On 08/28/2018 12:03 AM, Dalon L Westergreen wrote:
>> On Mon, 2018-08-27 at 21:03 +0200, Marek Vasut wrote:
>> On 08/27/2018 05:30 PM, Dalon L Westergreen wrote:
>> On Tue, 2018-08-21 at 05:52 +0200, Marek Vasut wrote:
>> On 08/20/2018 11:04 PM, Dalon L Westergreen wrote:
>> On Mon, 2018-08-20 at 20:33 +0200, Marek Vasut wrote:
>> On 08/20/2018 03:54 PM, Dalon Westergreen wrote:
>> Stratix10 requires a hex image of the spl for boot.  The hex
>> image is added to the FPGA configuration image and loaded to
>> the processor memory by the configuration engine.
>>
>> Signed-off-by: Dalon Westergreen >  > > >  > >> >  > > >  > 
>> ---
>>  scripts/Makefile.spl | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
>> index 76d08fd92b..c424f87e6e 100644
>> --- a/scripts/Makefile.spl
>> +++ b/scripts/Makefile.spl
>> @@ -190,6 +190,7 @@ endif
>>  ifdef CONFIG_ARCH_SOCFPGA
>>  ALL-$(CONFIG_TARGET_SOCFPGA_GEN5)   += $(obj)/$(SPL_BIN).sfp
>>  ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10)+= $(obj)/$(SPL_BIN).sfp
>> +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10)  += $(obj)/$(SPL_BIN).hex
>>  endif
>>  
>>  ifdef CONFIG_ARCH_SUNXI
>> @@ -299,6 +300,15 @@ OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j 
>> .start16 -j .resetvec
>>  $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE
>>  $(call if_changed,objcopy)
>>  
>> +ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
>> +OBJCOPYFLAGS_$(SPL_BIN).hex = -I binary -O ihex --change-addresses 
>> 0xffe0
>>
>> Why is this --change-address needed ? This smells like a hack of some
>> sort ...
>>
>> I believe the tool that uses this file expects this offset, that said i have 
>> not
>>
>> tried using a hex file without this change address applied.  I will try 
>> without 
>>
>> this, and see what happens.
>>
>> You probably need to adjust the link address of the SPL or U-Boot too.
>>
>> The link address appears to be correctly set to 0xffe0 which is the 
>> location of the onchip ram.  
>>
>> The quartus_cpf tool itself errors out when the --change-address option is 
>> not used.  The quartus_cpf 
>>
>> checks that the address range of the hex is entirely within the onchip ram.  
>> My suggestion would
>>
>> be to leave the --change-address option as is.  
>>
>> So what is _not_ in the onchip RAM then ? Is something sticking out of
>> the OCRAM , that's why the quartus_cpf fails ? Maybe that's something
>> you should fix.
>>
>> Thanks Marek, I'm m not very familiar with the hex format
>>
>> The intel ihex is terrible (sorry), it's really hard to decode. But
>> here's some example:
>> https://en.wikipedia.org/wiki/Intel_HEX
>>
>> but there only 2 lines that differ when
>>
>> using the change address option, the first and last, of the hex. 
>>
>>
>> in the file with the change-address option :0204FFE01B is prepended to 
>> the file, and 
>>
>> :0405FFE018 is added to the second to last line.  It is followed by 
>> :0001FF (end of file).
>>
>>
>> My belief is the change-address is simply specifying the start address of 
>> the hex data converted from
>>
>> the binary.  This offset is required by the quartus_cpf tool as a form of 
>> validation.
>>
>> This is what objcopy(1) says:
>>
>>--change-addresses incr
>>--adjust-vma incr
>>Change the VMA and LMA addresses of all sections, as well as
>> the start address, by adding incr.  Some object file formats do not
>> permit section addresses to be changed
>>arbitrarily.  Note that this does not relocate the sections;
>> if the program expects sections to be loaded at a certain address, and
>> this option is used to change the sections such
>>that they are loaded at a different address, the program may
>> fail.
>>
>> So I ran make V=1 , to see how the hex file is generated, and this is how:
>>   aarch64-linux-gnu-objcopy  -j .text -j .secure_text -j .secure_data -j
>> .rodata -j .data -j .u_boot_list -j .rela.dyn -j .got -j .got.plt -j
>> .binman_sym_table -j .text_rest -j .dtb.init.rodata -j .efi_runtime -j
>> .efi_runtime_rel -I binary -O ihex --change-addresses 0xffe0
>> spl/u-boot-spl.bin spl/u-boot-spl.hex
>>
>> It's generated from u-boot-spl.bin , which is weird. The u-boot.hex is
>> generated from u-boot (ELF binary). I think that's what the SPL hex
>> should be generated from too, since the ELF binary contains all the
>> relocation info.
>>
>> So a target similar to 

Re: [U-Boot] [PATCH 2/2] spl: socfpga: stratix10: add hex file output for spl image

[Dalon L Westergreen]

On Tue, 2018-08-28 at 01:54 +0200, Marek Vasut wrote:
> On 08/28/2018 12:03 AM, Dalon L Westergreen wrote:
> On Mon, 2018-08-27 at 21:03 +0200, Marek Vasut wrote:
> On 08/27/2018 05:30 PM, Dalon L Westergreen wrote:
> On Tue, 2018-08-21 at 05:52 +0200, Marek Vasut wrote:
> On 08/20/2018 11:04 PM, Dalon L Westergreen wrote:
> On Mon, 2018-08-20 at 20:33 +0200, Marek Vasut wrote:
> On 08/20/2018 03:54 PM, Dalon Westergreen wrote:
> Stratix10 requires a hex image of the spl for boot.  The hex
> image is added to the FPGA configuration image and loaded to
> the processor memory by the configuration engine.
> 
> Signed-off-by: Dalon Westergreen    >     ---
>  scripts/Makefile.spl | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index 76d08fd92b..c424f87e6e 100644
> --- a/scripts/Makefile.spl
> +++ b/scripts/Makefile.spl
> @@ -190,6 +190,7 @@ endif
>  ifdef CONFIG_ARCH_SOCFPGA
>  ALL-$(CONFIG_TARGET_SOCFPGA_GEN5)+= $(obj)/$(SPL_BIN).sfp
>  ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp
> +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10)   += $(obj)/$(SPL_BIN).hex
>  endif
>  
>  ifdef CONFIG_ARCH_SUNXI
> @@ -299,6 +300,15 @@ OBJCOPYFLAGS_u-boot-x86-16bit-spl.bin := -O binary -j 
> .start16 -j .resetvec
>  $(obj)/u-boot-x86-16bit-spl.bin: $(obj)/u-boot-spl FORCE
>   $(call if_changed,objcopy)
>  
> +ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
> +OBJCOPYFLAGS_$(SPL_BIN).hex = -I binary -O ihex --change-addresses 0xffe0
> 
> Why is this --change-address needed ? This smells like a hack of some
> sort ...
> 
> I believe the tool that uses this file expects this offset, that said i have 
> not
> 
> tried using a hex file without this change address applied.  I will try 
> without 
> 
> this, and see what happens.
> 
> You probably need to adjust the link address of the SPL or U-Boot too.
> 
> The link address appears to be correctly set to 0xffe0 which is the 
> location of the onchip ram.  
> 
> The quartus_cpf tool itself errors out when the --change-address option is 
> not used.  The quartus_cpf 
> 
> checks that the address range of the hex is entirely within the onchip ram.  
> My suggestion would
> 
> be to leave the --change-address option as is.  
> 
> So what is _not_ in the onchip RAM then ? Is something sticking out of
> the OCRAM , that's why the quartus_cpf fails ? Maybe that's something
> you should fix.
> 
> Thanks Marek, I'm m not very familiar with the hex format
> 
> The intel ihex is terrible (sorry), it's really hard to decode. But
> here's some example:
> https://en.wikipedia.org/wiki/Intel_HEX
> 
> but there only 2 lines that differ when
> 
> using the change address option, the first and last, of the hex. 
> 
> 
> in the file with the change-address option :0204FFE01B is prepended to 
> the file, and 
> 
> :0405FFE018 is added to the second to last line.  It is followed by 
> :0001FF (end of file).
> 
> 
> My belief is the change-address is simply specifying the start address of the 
> hex data converted from
> 
> the binary.  This offset is required by the quartus_cpf tool as a form of 
> validation.
> 
> This is what objcopy(1) says:
> 
>--change-addresses incr
>--adjust-vma incr
>Change the VMA and LMA addresses of all sections, as well as
> the start address, by adding incr.  Some object file formats do not
> permit section addresses to be changed
>arbitrarily.  Note that this does not relocate the sections;
> if the program expects sections to be loaded at a certain address, and
> this option is used to change the sections such
>that they are loaded at a different address, the program may
> fail.
> 
> So I ran make V=1 , to see how the hex file is generated, and this is how:
>   aarch64-linux-gnu-objcopy  -j .text -j .secure_text -j .secure_data -j
> .rodata -j .data -j .u_boot_list -j .rela.dyn -j .got -j .got.plt -j
> .binman_sym_table -j .text_rest -j .dtb.init.rodata -j .efi_runtime -j
> .efi_runtime_rel -I binary -O ihex --change-addresses 0xffe0
> spl/u-boot-spl.bin spl/u-boot-spl.hex
> 
> It's generated from u-boot-spl.bin , which is weird. The u-boot.hex is
> generated from u-boot (ELF binary). I think that's what the SPL hex
> should be generated from too, since the ELF binary contains all the
> relocation info.
> 
> So a target similar to u-boot.hex should do:
> OBJCOPYFLAGS_$(SPL_BIN).hex = -O ihex
> 
> $(obj)/$(SPL_BIN).hex: $(obj)/$(SPL_BIN) FORCE
>$(call if_changed,objcopy)
> 
> Does that work for you ?
> 

Actually no, it is weird that it is using SPL_BIN, the intent was to use the 
binary with
the devicetree included.  That is the reason for generating from the binary.  I 
will update
the patch i sent to use 

Re: [U-Boot] [PATCH v2 1/8] powerpc/dts: Define '_end' symbol in mpc85xx u-boot lds files

[Bin Meng]

On Tue, Aug 28, 2018 at 6:50 PM Jagdish Gediya  wrote:
>
> Hi Bin,
>
> > -Original Message-
> > From: Bin Meng 
> > Sent: Tuesday, August 28, 2018 2:46 PM
> > To: Jagdish Gediya 
> > Cc: U-Boot Mailing List ; Prabhakar Kushwaha
> > ; York Sun ; Poonam
> > Aggrwal ; Simon Glass ;
> > Tom Rini 
> > Subject: Re: [PATCH v2 1/8] powerpc/dts: Define '_end' symbol in mpc85xx u-
> > boot lds files
> >
> > On Tue, Aug 28, 2018 at 11:53 AM Jagdish Gediya 
> > wrote:
> > >
> > > 'board_fdt_blob_setup' function sets up fdt blob at '&_end' so define
> > > '_end' symbol in mpc85xx lds files.
> > >
> > > Signed-off-by: Jagdish Gediya 
> > > ---
> > > Changes for v2:
> > > - Defined '_end' symbol in lds file instead of defining new
> > >   'board_fdt_blob_setup' function using existing '_init_end' 
> > > symbol.
> > >
> > >  arch/powerpc/cpu/mpc85xx/u-boot-nand.lds | 1 +
> > >  arch/powerpc/cpu/mpc85xx/u-boot.lds  | 1 +
> > >  2 files changed, 2 insertions(+)
> > >
> >
> > This only updates 2 lds files. Can you update all mpc85xx lds files so that 
> > they
> > are consistent?
>
> Remaining are spl lds files and I think '_end' symbol is not needed there.

But if you look at other targets, the spl version lds has the _end
symbol. Adding _end there does not cause any problem, no?

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

Re: [U-Boot] [PATCH] TPL/SPL: add separate CONFIG_TPL_FRAMEWORK for TPL

[Kever Yang]

Hi Tom,


On 08/28/2018 08:49 PM, Tom Rini wrote:
> On Tue, Aug 28, 2018 at 04:51:26PM +0800, Kever Yang wrote:
>
>> SPL_FRAMEWORK is a set of framework feature, we may not need the
>> fromework for both TPL and SPL at the same time, so add a separate
>> one for TPL.
>>
>> Signed-off-by: Kever Yang 
>> ---
>>
>>  Makefile  | 2 +-
>>  arch/arm/lib/Makefile | 4 ++--
>>  arch/arm/lib/crt0.S   | 6 +-
>>  common/spl/Kconfig| 9 +
>>  common/spl/Makefile   | 2 +-
>>  scripts/Makefile.spl  | 4 
>>  6 files changed, 22 insertions(+), 5 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 4b3023b259..68b77d1e43 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -822,7 +822,7 @@ endif
>>  endif
>>  ALL-$(CONFIG_TPL) += tpl/u-boot-tpl.bin
>>  ALL-$(CONFIG_OF_SEPARATE) += u-boot.dtb
>> -ifeq ($(CONFIG_SPL_FRAMEWORK),y)
>> +ifeq ($(CONFIG_TPL_FRAMEWORK),y)
>>  ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img
>>  endif
>>  ALL-$(CONFIG_OF_HOSTFILE) += u-boot.dtb
> We should be adding a new stanza here and not replacing the SPL one I
> would think.
This may not need,  I though this is for TPL because it's just after
target for CONFIG_TPL.
Will drop this part next version.
>
> [snip]
>> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
>> index db1915fe5c..1a2e10b892 100644
>> --- a/common/spl/Kconfig
>> +++ b/common/spl/Kconfig
>> @@ -813,6 +813,15 @@ config TPL
>>  help
>>If you want to build TPL as well as the normal image and SPL, say Y.
>>  
>> +config TPL_FRAMEWORK
>> +bool "Support TPL based upon the common TPL framework"
>> +depends on TPL
>> +default y
>> +help
>> +  Enable the TPL framework under common/spl/.  This framework
>> +  re-use the all the framework feature from SPL but enable separetely.
>> +  If unsure, say Y.
> This shouldn't be default y, and the help shouldn't suggest that either
> I think.  My concern with this series is TPL wasn't intended to get too
> featureful.  Our initial constraints are enough that we need something
> to init DDR and load SPL into that as we can't do enough with our
> limited resources to load full U-Boot.  In fact, looking at the follow
> up rockchip specific patch that's more in line what my expectations.  So
> I think you should be able to get TPL to do what you want without
> introducing TPL_FRAMEWORK.  Thanks!
I have to introducing  TPL_FRAMEWORK because the SPL_FRAMEWORK
is shared by TPL and SPL, if I have enable TPL and SPL, then:
- I would like to use TPL without framework(which refers to DM, common
lib and FDT);
- I would like to use SPL with SPL_FRAMEWORK
If there is no TPL_FRAMEWORK, then I'm not sure if I can use the
TINY_FRAMEWORK
to overwrite everything.


I introduce TINY_FRAMEWORK is to remove other program like vector table,
runtime C init, which is not include in SPL_FRAMEWORK now.

Thanks,
- Kever


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

Re: [U-Boot] [PATCH] TPL/SPL: add separate CONFIG_TPL_FRAMEWORK for TPL

[Tom Rini]

On Tue, Aug 28, 2018 at 04:51:26PM +0800, Kever Yang wrote:

> SPL_FRAMEWORK is a set of framework feature, we may not need the
> fromework for both TPL and SPL at the same time, so add a separate
> one for TPL.
> 
> Signed-off-by: Kever Yang 
> ---
> 
>  Makefile  | 2 +-
>  arch/arm/lib/Makefile | 4 ++--
>  arch/arm/lib/crt0.S   | 6 +-
>  common/spl/Kconfig| 9 +
>  common/spl/Makefile   | 2 +-
>  scripts/Makefile.spl  | 4 
>  6 files changed, 22 insertions(+), 5 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 4b3023b259..68b77d1e43 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -822,7 +822,7 @@ endif
>  endif
>  ALL-$(CONFIG_TPL) += tpl/u-boot-tpl.bin
>  ALL-$(CONFIG_OF_SEPARATE) += u-boot.dtb
> -ifeq ($(CONFIG_SPL_FRAMEWORK),y)
> +ifeq ($(CONFIG_TPL_FRAMEWORK),y)
>  ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img
>  endif
>  ALL-$(CONFIG_OF_HOSTFILE) += u-boot.dtb

We should be adding a new stanza here and not replacing the SPL one I
would think.

[snip]
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index db1915fe5c..1a2e10b892 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -813,6 +813,15 @@ config TPL
>   help
> If you want to build TPL as well as the normal image and SPL, say Y.
>  
> +config TPL_FRAMEWORK
> + bool "Support TPL based upon the common TPL framework"
> + depends on TPL
> + default y
> + help
> +   Enable the TPL framework under common/spl/.  This framework
> +   re-use the all the framework feature from SPL but enable separetely.
> +   If unsure, say Y.

This shouldn't be default y, and the help shouldn't suggest that either
I think.  My concern with this series is TPL wasn't intended to get too
featureful.  Our initial constraints are enough that we need something
to init DDR and load SPL into that as we can't do enough with our
limited resources to load full U-Boot.  In fact, looking at the follow
up rockchip specific patch that's more in line what my expectations.  So
I think you should be able to get TPL to do what you want without
introducing TPL_FRAMEWORK.  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] rockchip: dts: fix unnecessary '-cells' warning

[Dr. Philipp Tomsich]

> On 28 Aug 2018, at 11:57, Kever Yang  wrote:
> 
> Fix warning below:
> unnecessary #address-cells/#size-cells without "ranges" or child "reg"
> property
> 
> Signed-off-by: Kever Yang 

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

Re: [U-Boot] [PATCH v2 1/8] powerpc/dts: Define '_end' symbol in mpc85xx u-boot lds files

[Jagdish Gediya]

Hi Bin,

> -Original Message-
> From: Bin Meng 
> Sent: Tuesday, August 28, 2018 2:46 PM
> To: Jagdish Gediya 
> Cc: U-Boot Mailing List ; Prabhakar Kushwaha
> ; York Sun ; Poonam
> Aggrwal ; Simon Glass ;
> Tom Rini 
> Subject: Re: [PATCH v2 1/8] powerpc/dts: Define '_end' symbol in mpc85xx u-
> boot lds files
> 
> On Tue, Aug 28, 2018 at 11:53 AM Jagdish Gediya 
> wrote:
> >
> > 'board_fdt_blob_setup' function sets up fdt blob at '&_end' so define
> > '_end' symbol in mpc85xx lds files.
> >
> > Signed-off-by: Jagdish Gediya 
> > ---
> > Changes for v2:
> > - Defined '_end' symbol in lds file instead of defining new
> >   'board_fdt_blob_setup' function using existing '_init_end' symbol.
> >
> >  arch/powerpc/cpu/mpc85xx/u-boot-nand.lds | 1 +
> >  arch/powerpc/cpu/mpc85xx/u-boot.lds  | 1 +
> >  2 files changed, 2 insertions(+)
> >
> 
> This only updates 2 lds files. Can you update all mpc85xx lds files so that 
> they
> are consistent?

Remaining are spl lds files and I think '_end' symbol is not needed there.

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

[U-Boot] [PATCH] TPL/SPL: add separate CONFIG_TPL_FRAMEWORK for TPL

[Kever Yang]

SPL_FRAMEWORK is a set of framework feature, we may not need the
fromework for both TPL and SPL at the same time, so add a separate
one for TPL.

Signed-off-by: Kever Yang 
---

 Makefile  | 2 +-
 arch/arm/lib/Makefile | 4 ++--
 arch/arm/lib/crt0.S   | 6 +-
 common/spl/Kconfig| 9 +
 common/spl/Makefile   | 2 +-
 scripts/Makefile.spl  | 4 
 6 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index 4b3023b259..68b77d1e43 100644
--- a/Makefile
+++ b/Makefile
@@ -822,7 +822,7 @@ endif
 endif
 ALL-$(CONFIG_TPL) += tpl/u-boot-tpl.bin
 ALL-$(CONFIG_OF_SEPARATE) += u-boot.dtb
-ifeq ($(CONFIG_SPL_FRAMEWORK),y)
+ifeq ($(CONFIG_TPL_FRAMEWORK),y)
 ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img
 endif
 ALL-$(CONFIG_OF_HOSTFILE) += u-boot.dtb
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 655727f431..19a6775b0d 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -35,8 +35,8 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
 obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o
 obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
 else
-obj-$(CONFIG_SPL_FRAMEWORK) += spl.o
-obj-$(CONFIG_SPL_FRAMEWORK) += zimage.o
+obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o
+obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += zimage.o
 obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o
 endif
 obj-$(CONFIG_$(SPL_TPL_)USE_ARCH_MEMSET) += memset.o
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 538d78c0b8..f1a8a7e7dc 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -120,7 +120,11 @@ here:
 
bl  c_runtime_cpu_setup /* we still call old routine here */
 #endif
-#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_FRAMEWORK)
+#if !defined(CONFIG_SPL_BUILD) || \
+   (defined(CONFIG_TPL_BUILD) && defined(CONFIG_TPL_FRAMEWORK)) || \
+   (defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD) && \
+   defined(CONFIG_SPL_FRAMEWORK)) \
+
 # ifdef CONFIG_SPL_BUILD
/* Use a DRAM stack for the rest of SPL, if requested */
bl  spl_relocate_stack_gd
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index db1915fe5c..1a2e10b892 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -813,6 +813,15 @@ config TPL
help
  If you want to build TPL as well as the normal image and SPL, say Y.
 
+config TPL_FRAMEWORK
+   bool "Support TPL based upon the common TPL framework"
+   depends on TPL
+   default y
+   help
+ Enable the TPL framework under common/spl/.  This framework
+ re-use the all the framework feature from SPL but enable separetely.
+ If unsure, say Y.
+
 if TPL
 
 config TPL_BOARD_INIT
diff --git a/common/spl/Makefile b/common/spl/Makefile
index a130a5be4b..dd2fc7a5d3 100644
--- a/common/spl/Makefile
+++ b/common/spl/Makefile
@@ -7,7 +7,7 @@
 #
 
 ifdef CONFIG_SPL_BUILD
-obj-$(CONFIG_SPL_FRAMEWORK) += spl.o
+obj-$(CONFIG_$(SPL_TPL_)FRAMEWORK) += spl.o
 obj-$(CONFIG_$(SPL_TPL_)BOOTROM_SUPPORT) += spl_bootrom.o
 obj-$(CONFIG_$(SPL_TPL_)LOAD_FIT) += spl_fit.o
 obj-$(CONFIG_$(SPL_TPL_)NOR_SUPPORT) += spl_nor.o
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 252f13826d..43949cdba1 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -64,7 +64,11 @@ HAVE_VENDOR_COMMON_LIB = $(if $(wildcard 
$(srctree)/board/$(VENDOR)/common/Makef
 libs-y += $(if $(BOARDDIR),board/$(BOARDDIR)/)
 libs-$(HAVE_VENDOR_COMMON_LIB) += board/$(VENDOR)/common/
 
+ifeq ($(CONFIG_TPL_BUILD),y)
+libs-$(CONFIG_TPL_FRAMEWORK) += common/spl/
+else
 libs-$(CONFIG_SPL_FRAMEWORK) += common/spl/
+endif
 libs-y += common/init/
 
 # Special handling for a few options which support SPL/TPL
-- 
2.18.0

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

[U-Boot] [PATCH] rockchip: dts: fix unnecessary '-cells' warning

[Kever Yang]

Fix warning below:
unnecessary #address-cells/#size-cells without "ranges" or child "reg"
property

Signed-off-by: Kever Yang 
---

 arch/arm/dts/rk3288-evb.dtsi | 2 --
 arch/arm/dts/rk3288-firefly.dtsi | 2 --
 arch/arm/dts/rk3288-tinker.dtsi  | 2 --
 arch/arm/dts/rk3288-veyron.dtsi  | 2 --
 arch/arm/dts/rk3288.dtsi | 2 --
 arch/arm/dts/rk3328.dtsi | 2 --
 arch/arm/dts/rk3399-puma.dtsi| 2 --
 arch/arm/dts/rk3399.dtsi | 4 
 8 files changed, 18 deletions(-)

diff --git a/arch/arm/dts/rk3288-evb.dtsi b/arch/arm/dts/rk3288-evb.dtsi
index 17c79d3c27..ce75bd5d28 100644
--- a/arch/arm/dts/rk3288-evb.dtsi
+++ b/arch/arm/dts/rk3288-evb.dtsi
@@ -19,8 +19,6 @@
 
keys: gpio-keys {
compatible = "gpio-keys";
-   #address-cells = <1>;
-   #size-cells = <0>;
 
button@0 {
gpio-key,wakeup = <1>;
diff --git a/arch/arm/dts/rk3288-firefly.dtsi b/arch/arm/dts/rk3288-firefly.dtsi
index de5e8f2e8d..2239ab9f59 100644
--- a/arch/arm/dts/rk3288-firefly.dtsi
+++ b/arch/arm/dts/rk3288-firefly.dtsi
@@ -25,8 +25,6 @@
 
keys: gpio-keys {
compatible = "gpio-keys";
-   #address-cells = <1>;
-   #size-cells = <0>;
 
button@0 {
gpio-key,wakeup = <1>;
diff --git a/arch/arm/dts/rk3288-tinker.dtsi b/arch/arm/dts/rk3288-tinker.dtsi
index a752458663..2f816af47f 100644
--- a/arch/arm/dts/rk3288-tinker.dtsi
+++ b/arch/arm/dts/rk3288-tinker.dtsi
@@ -55,8 +55,6 @@
 
gpio-keys {
compatible = "gpio-keys";
-   #address-cells = <1>;
-   #size-cells = <0>;
autorepeat;
 
pinctrl-names = "default";
diff --git a/arch/arm/dts/rk3288-veyron.dtsi b/arch/arm/dts/rk3288-veyron.dtsi
index 4b66f6be3c..92b68878fd 100644
--- a/arch/arm/dts/rk3288-veyron.dtsi
+++ b/arch/arm/dts/rk3288-veyron.dtsi
@@ -83,8 +83,6 @@
 
gpio_keys: gpio-keys {
compatible = "gpio-keys";
-   #address-cells = <1>;
-   #size-cells = <0>;
 
pinctrl-names = "default";
pinctrl-0 = <_key_h>;
diff --git a/arch/arm/dts/rk3288.dtsi b/arch/arm/dts/rk3288.dtsi
index 9f3f6f5051..273d38c84f 100644
--- a/arch/arm/dts/rk3288.dtsi
+++ b/arch/arm/dts/rk3288.dtsi
@@ -841,8 +841,6 @@
#size-cells = <0>;
status = "disabled";
ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
reg = <1>;
mipi_in: port {
#address-cells = <1>;
diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi
index 82c3717fba..4ec5d3e1f3 100644
--- a/arch/arm/dts/rk3328.dtsi
+++ b/arch/arm/dts/rk3328.dtsi
@@ -189,8 +189,6 @@
u-boot,dm-pre-reloc;
compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
reg = <0x0 0xff10 0x0 0x1000>;
-   #address-cells = <1>;
-   #size-cells = <1>;
 
io_domains: io-domains {
compatible = "rockchip,rk3328-io-voltage-domain";
diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
index 35840319ff..6e7e1e3528 100644
--- a/arch/arm/dts/rk3399-puma.dtsi
+++ b/arch/arm/dts/rk3399-puma.dtsi
@@ -208,8 +208,6 @@
 };
 
  {
-   #address-cells = <1>;
-   #size-cells = <0>;
#sound-dai-cells = <0>;
status = "okay";
 };
diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index 83c257b122..a55a6c6eb9 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -1015,8 +1015,6 @@
u-boot,dm-pre-reloc;
compatible = "rockchip,rk3399-pmugrf", "syscon", "simple-mfd";
reg = <0x0 0xff32 0x0 0x1000>;
-   #address-cells = <1>;
-   #size-cells = <1>;
 
pmu_io_domains: io-domains {
compatible = "rockchip,rk3399-pmu-io-voltage-domain";
@@ -1493,8 +1491,6 @@
#size-cells = <0>;
status = "disabled";
ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
reg = <1>;
mipi_in: port {
#address-cells = <1>;
-- 
2.18.0

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

Re: [U-Boot] [PATCH v3] usb: dwc2: Add reset ctrl to driver

[Marek Vasut]

On 08/28/2018 06:08 PM, Ley Foon Tan wrote:
> Add code to reset all reset signals as in usb DT node. A reset property
> is an optional feature, so only print out a warning and do not fail if a
> reset property is not present.
> 
> If a reset property is discovered, then use it to deassert, thus
> bringing the IP out of reset.
> 
> Signed-off-by: Ley Foon Tan 
> 
> ---
> v3:
> - Add error handling when return non-zero from reset_get_bulk().
> 
> v2:
> - Add reset_release_bulk() in _remove function.
> ---
>  drivers/usb/host/dwc2.c |   37 +
>  1 files changed, 37 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
> index cbe065b..b6f008a 100644
> --- a/drivers/usb/host/dwc2.c
> +++ b/drivers/usb/host/dwc2.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "dwc2.h"
>  
> @@ -49,6 +50,8 @@ struct dwc2_priv {
>*/
>   bool hnp_srp_disable;
>   bool oc_disable;
> +
> + struct reset_ctl_bulk   resets;
>  };
>  
>  #ifndef CONFIG_DM_USB
> @@ -1124,11 +1127,43 @@ int _submit_int_msg(struct dwc2_priv *priv, struct 
> usb_device *dev,
>   }
>  }
>  
> +static int dwc2_reset(struct udevice *dev)
> +{
> + int ret;
> + struct dwc2_priv *priv = dev_get_priv(dev);
> +
> + ret = reset_get_bulk(dev, >resets);
> + if (ret) {
> + dev_warn(dev, "Can't get reset: %d\n", ret);
> + /* Return 0 if error due to !CONFIG_DM_RESET and reset
> +  * DT property is not present.
> +  */
> + if (ret == -ENOENT || ret == -ENOTSUPP)
> + return 0;
> + else
> + return ret;
> + }
> +
> + ret = reset_deassert_bulk(>resets);
> + if (ret) {
> + reset_release_bulk(>resets);
> + dev_err(dev, "Failed to reset: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
>  static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
>  {
>   struct dwc2_core_regs *regs = priv->regs;
>   uint32_t snpsid;
>   int i, j;
> + int ret;
> +
> + ret = dwc2_reset(dev);
> + if (ret)
> + return ret;
>  
>   snpsid = readl(>gsnpsid);
>   dev_info(dev, "Core Release: %x.%03x\n",
> @@ -1303,6 +1338,8 @@ static int dwc2_usb_remove(struct udevice *dev)
>  
>   dwc2_uninit_common(priv->regs);
>  

Don't you need to assert the reset here ?

> + reset_release_bulk(>resets);
> +
>   return 0;
>  }
>  
> 


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

Re: [U-Boot] [PATCH v3 2/2] gpio: dwapb_gpio: Add reset ctrl to driver

[Marek Vasut]

On 08/28/2018 06:07 PM, Ley Foon Tan wrote:
> Add code to reset all reset signals as in gpio DT node. A reset property
> is an optional feature, so only print out a warning and do not fail if a
> reset property is not present.
> 
> If a reset property is discovered, then use it to deassert, thus
> bringing the IP out of reset.
> 
> Signed-off-by: Ley Foon Tan 
> 
> ---
> v3:
> - Add .remove function.
> - Add error handling when return non-zero from reset_get_bulk().
> 
> v2:
> - Move reset to probe() function.
> ---
>  drivers/gpio/dwapb_gpio.c |   42 --
>  1 files changed, 40 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
> index 7cf2d47..6394fa9 100644
> --- a/drivers/gpio/dwapb_gpio.c
> +++ b/drivers/gpio/dwapb_gpio.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
>  
> @@ -99,13 +100,42 @@ static const struct dm_gpio_ops gpio_dwapb_ops = {
>   .get_function   = dwapb_gpio_get_function,
>  };
>  
> +static int gpio_dwapb_reset(struct udevice *dev)
> +{
> + int ret;
> + struct gpio_dev_priv *priv = dev_get_uclass_priv(dev);
> +
> + ret = reset_get_bulk(dev, >resets);
> + if (ret) {
> + dev_warn(dev, "Can't get reset: %d\n", ret);
> + /* Return 0 if error due to !CONFIG_DM_RESET and reset
> +  * DT property is not present.
> +  */
> + if (ret == -ENOENT || ret == -ENOTSUPP)
> + return 0;
> + else
> + return ret;
> + }
> +
> + ret = reset_deassert_bulk(>resets);
> + if (ret) {
> + reset_release_bulk(>resets);
> + dev_err(dev, "Failed to reset: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
>  static int gpio_dwapb_probe(struct udevice *dev)
>  {
>   struct gpio_dev_priv *priv = dev_get_uclass_priv(dev);
>   struct gpio_dwapb_platdata *plat = dev->platdata;
>  
> - if (!plat)
> - return 0;
> + if (!plat) {
> + /* Reset on parent device only */
> + return gpio_dwapb_reset(dev);
> + }
>  
>   priv->gpio_count = plat->pins;
>   priv->bank_name = plat->name;
> @@ -166,6 +196,13 @@ err:
>   return ret;
>  }
>  
> +static int gpio_dwapb_remove(struct udevice *dev)
> +{
> + struct gpio_dev_priv *priv = dev_get_uclass_priv(dev);

You might want to assert the reset too.

> + return reset_release_bulk(>resets);
> +}
> +
>  static const struct udevice_id gpio_dwapb_ids[] = {
>   { .compatible = "snps,dw-apb-gpio" },
>   { }
> @@ -178,4 +215,5 @@ U_BOOT_DRIVER(gpio_dwapb) = {
>   .ops= _dwapb_ops,
>   .bind   = gpio_dwapb_bind,
>   .probe  = gpio_dwapb_probe,
> + .remove = gpio_dwapb_remove,
>  };
> 


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

Re: [U-Boot] [PATCH v3 1/2] gpio: Add struct reset_ctl_bulk

[Marek Vasut]

On 08/28/2018 06:07 PM, Ley Foon Tan wrote:
> Add struct reset_ctl_bulk to struct gpio_dev_priv to support reset control
> in GPIO driver.
> 
> Signed-off-by: Ley Foon Tan 

Isn't this reset support supposed to be driver specific, and thus part
of driver private data ?

> ---
>  include/asm-generic/gpio.h |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
> index d036026..9fd5808 100644
> --- a/include/asm-generic/gpio.h
> +++ b/include/asm-generic/gpio.h
> @@ -8,6 +8,7 @@
>  #define _ASM_GENERIC_GPIO_H_
>  
>  #include 
> +#include 
>  
>  struct ofnode_phandle_args;
>  
> @@ -318,6 +319,7 @@ struct gpio_dev_priv {
>   unsigned gpio_count;
>   unsigned gpio_base;
>   char **name;
> + struct reset_ctl_bulk resets;
>  };
>  
>  /* Access the GPIO operations for a device */
> 


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

Re: [U-Boot] [PATCH v3 19/58] clk: sunxi: Implement direct MMC clocks

[Maxime Ripard]

On Mon, Aug 27, 2018 at 03:34:20PM +0530, Jagan Teki wrote:
> >> diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
> >> index fb11231dd1..55176bc174 100644
> >> --- a/drivers/clk/sunxi/clk_a10.c
> >> +++ b/drivers/clk/sunxi/clk_a10.c
> >> @@ -23,6 +23,11 @@ static struct ccu_clk_map a10_clks[] = {
> >>   [CLK_AHB_MMC2]  = { 0x060, BIT(10), NULL },
> >>   [CLK_AHB_MMC3]  = { 0x060, BIT(11), NULL },
> >>
> >> + [CLK_MMC0]  = { 0x088, BIT(31), _clk_set_rate },
> >> + [CLK_MMC1]  = { 0x08c, BIT(31), _clk_set_rate },
> >> + [CLK_MMC2]  = { 0x090, BIT(31), _clk_set_rate },
> >> + [CLK_MMC3]  = { 0x094, BIT(31), _clk_set_rate },
> >> +
> >>   [CLK_USB_OHCI0] = { 0x0cc, BIT(6), NULL },
> >>   [CLK_USB_OHCI1] = { 0x0cc, BIT(7), NULL },
> >>   [CLK_USB_PHY]   = { 0x0cc, BIT(8), NULL },
> >> diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
> >> index bc4ae7352b..fbac0ad751 100644
> >> --- a/drivers/clk/sunxi/clk_a10s.c
> >> +++ b/drivers/clk/sunxi/clk_a10s.c
> >> @@ -20,6 +20,12 @@ static struct ccu_clk_map a10s_clks[] = {
> >>   [CLK_AHB_MMC1]  = { 0x060, BIT(9), NULL },
> >>   [CLK_AHB_MMC2]  = { 0x060, BIT(10), NULL },
> >>
> >> +#ifdef CONFIG_MMC
> >> + [CLK_MMC0]  = { 0x088, BIT(31), _clk_set_rate },
> >> + [CLK_MMC1]  = { 0x08c, BIT(31), _clk_set_rate },
> >> + [CLK_MMC2]  = { 0x090, BIT(31), _clk_set_rate },
> >> +#endif
> >> +
> >
> > I'm not too sure about the ifdef here. Or at least, we should be
> > consistent, and if we do it for the MMC, we should do it for all the
> > SoCs (including the A10), and for all the controllers (including USB,
> > for example).
> 
> because few of sun5i boards not using MMC, example CHIP and CHIP_pro
> otherwise we need to use intermediate wrapper to call
> mmc_clk_set_rate.

Well, yes, but you can make the same argument for other SoCs, and
other features. So really, I think this is a good idea, but if we
remain consistent between SoCs and features.

> >
> >> diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
> >> index 39f15eb423..bf82014a64 100644
> >> --- a/drivers/mmc/sunxi_mmc.c
> >> +++ b/drivers/mmc/sunxi_mmc.c
> >> @@ -13,6 +13,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -34,6 +35,8 @@ struct sunxi_mmc_priv {
> >>   struct mmc_config cfg;
> >>  };
> >>
> >> +bool new_mode;
> >> +
> >>  #if !CONFIG_IS_ENABLED(DM_MMC)
> >>  /* support 4 mmc hosts */
> >>  struct sunxi_mmc_priv mmc_host[4];
> >> @@ -95,23 +98,19 @@ static int mmc_resource_init(int sdc_no)
> >>  }
> >>  #endif
> >>
> >> -static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, unsigned int hz)
> >> +int mmc_clk_set_rate(void *base, u32 bit, ulong rate)
> >>  {
> >>   unsigned int pll, pll_hz, div, n, oclk_dly, sclk_dly;
> >> - bool new_mode = false;
> >>   u32 val = 0;
> >>
> >> - if (IS_ENABLED(CONFIG_MMC_SUNXI_HAS_NEW_MODE) && (priv->mmc_no == 2))
> >> - new_mode = true;
> >> -
> >
> > [..]
> >
> >> +static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, unsigned int hz)
> >> +{
> >> +#if CONFIG_IS_ENABLED(DM_MMC) && CONFIG_IS_ENABLED(CLK)
> >> +#else
> >> + if (IS_ENABLED(CONFIG_MMC_SUNXI_HAS_NEW_MODE) && (priv->mmc_no == 2))
> >> + new_mode = true;
> >> +
> >
> > I'm not sure why you need the global variable.
> >
> > The A83t emmc case you have below is caught in this condition, and
> > therefore, the scope doesn't need to be global.
> 
> Since mmc_set_rate calling with base and reg bits, which doesn't have
> any possibility know private data of driver we need a global to check
> to update the same in dm and non-dm.

Wouldn't that lead to issues if we have two controllers being active,
one with the new mode enabled, the other without, and you call
mmc_set_rate on the one without?

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

[U-Boot] [PATCH] rockchip: add TPL_TINY_FRAMEWORK support

[Kever Yang]

Rockchip BootRom support load firmware from storage media twice,
one for ddr sdram init code into sram and another time to load
firmware into DDR. For ddr sdram init code(which is TPL in U-Boot
project), it's OK to re-use the stack and vector table. In order
to get more available sram space, we need to skip all the init code
from U-Boot project including start.S, reset.S and framework.

Signed-off-by: Kever Yang 
---

 arch/arm/cpu/armv7/start.S |   2 +
 arch/arm/cpu/armv8/start.S |   2 +
 arch/arm/include/asm/arch-rockchip/boot0.h |  10 ++
 arch/arm/mach-rockchip/Kconfig |  12 +++
 arch/arm/mach-rockchip/Makefile|   2 +
 arch/arm/mach-rockchip/tiny_tpl.c  | 106 +
 6 files changed, 134 insertions(+)
 create mode 100644 arch/arm/mach-rockchip/tiny_tpl.c

diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 81edec01bf..548d9ff23a 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -38,7 +38,9 @@
 reset:
/* Allow the board to save important registers */
b   save_boot_params
+#if !CONFIG_IS_ENABLED(TINY_FRAMEWORK)
 save_boot_params_ret:
+#endif
 #ifdef CONFIG_ARMV7_LPAE
 /*
  * check for Hypervisor support
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index d4db4d044f..e0f8fad10c 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -31,6 +31,7 @@ _start:
b   reset
 #endif
 
+#if !CONFIG_IS_ENABLED(TINY_FRAMEWORK)
.align 3
 
 .globl _TEXT_BASE
@@ -361,3 +362,4 @@ ENDPROC(c_runtime_cpu_setup)
 WEAK(save_boot_params)
b   save_boot_params_ret/* back to my caller */
 ENDPROC(save_boot_params)
+#endif
diff --git a/arch/arm/include/asm/arch-rockchip/boot0.h 
b/arch/arm/include/asm/arch-rockchip/boot0.h
index 9ea4708ada..7f00494513 100644
--- a/arch/arm/include/asm/arch-rockchip/boot0.h
+++ b/arch/arm/include/asm/arch-rockchip/boot0.h
@@ -41,8 +41,18 @@ entry_counter:
 
 #if (defined(CONFIG_SPL_BUILD) || defined(CONFIG_ARM64))
/* U-Boot proper of armv7 do not need this */
+#if CONFIG_IS_ENABLED(TINY_FRAMEWORK)
+   /* Allow the board to save important registers */
+   b save_boot_params
+.globl save_boot_params_ret
+.type   save_boot_params_ret, %function
+
+save_boot_params_ret:
+   b board_init_f
+#else
b reset
 #endif
+#endif
 
 #if !defined(CONFIG_ARM64)
/*
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 187aa14184..be23bcc37e 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -306,6 +306,18 @@ config TPL_ROCKCHIP_EARLYRETURN_TO_BROM
 config SPL_MMC_SUPPORT
default y if !SPL_ROCKCHIP_BACK_TO_BROM
 
+config TPL_TINY_FRAMEWORK
+   bool "Tiny TPL for DDR init"
+   depends on TPL && !TPL_FRAMEWORK
+   default y
+   help
+ Rockchip BootRom support load firmware from storage media twice,
+ one for ddr sdram init code into sram and another time to load
+ firmware into DDR. For ddr sdram init code(which is TPL in U-Boot
+ project), it's OK to re-use the stack and vector table. In order
+ to get more available sram space, we need to skip all the init code
+ from U-Boot project including start.S, reset.S and framework.
+
 source "arch/arm/mach-rockchip/rk3036/Kconfig"
 source "arch/arm/mach-rockchip/rk3128/Kconfig"
 source "arch/arm/mach-rockchip/rk3188/Kconfig"
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index 83afdac99d..c88700f10d 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -9,6 +9,8 @@
 obj-spl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
 obj-tpl-$(CONFIG_ROCKCHIP_BROM_HELPER) += bootrom.o
 
+obj-tpl-$(CONFIG_TPL_TINY_FRAMEWORK) += tiny_tpl.o
+
 obj-tpl-$(CONFIG_ROCKCHIP_RK3288) += rk3288-board-tpl.o
 obj-tpl-$(CONFIG_ROCKCHIP_RK3368) += rk3368-board-tpl.o
 obj-tpl-$(CONFIG_ROCKCHIP_RK322X) += rk322x-board-tpl.o
diff --git a/arch/arm/mach-rockchip/tiny_tpl.c 
b/arch/arm/mach-rockchip/tiny_tpl.c
new file mode 100644
index 00..47f15c0af1
--- /dev/null
+++ b/arch/arm/mach-rockchip/tiny_tpl.c
@@ -0,0 +1,106 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2018 Rockchip Electronics Co., Ltd
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef CONFIG_TPL_LIBGENERIC_SUPPORT
+#ifdef CONFIG_ARM64
+/* for ARM64,it don't have define timer_init and __udelay except lib/timer.c */
+int __weak timer_init(void)
+{
+   return 0;
+}
+
+void __weak __udelay(unsigned long usec)
+{
+   u64 i, j, count;
+
+   asm volatile ("MRS %0, CNTPCT_EL0" : "=r"(count));
+   i = count;
+   /* usec to count,24MHz */
+   j = usec * 24;
+   i += j;
+   while (1) {
+   asm volatile ("MRS %0, CNTPCT_EL0" : "=r"(count));
+   if (count > i)
+   

Re: [U-Boot] [PATCH v2 8/8] powerpc: dts: Enable device tree support for T2080QDS

[Bin Meng]

On Tue, Aug 28, 2018 at 11:53 AM Jagdish Gediya  wrote:
>
> Add device tree for T2080QDS board and enable CONFIG_OF_CONTROL
> so that device tree can be compiled.
>
> Update board README for device tree usage.
>
> Signed-off-by: Jagdish Gediya 
> ---
>  Changes for v2:
> - Enable CONFIG_MPC85XX_HAVE_RESET_VECTOR in T2080QDS_defconfig
> - README and commit message changes as per Bin Meng's comments
>
>  arch/powerpc/dts/Makefile |  2 ++
>  arch/powerpc/dts/e6500_power_isa.dtsi | 39 ++
>  arch/powerpc/dts/t2080.dtsi   | 62 
> +++
>  arch/powerpc/dts/t2080qds.dts | 17 ++
>  board/freescale/t208xqds/README   | 19 +++
>  configs/T2080QDS_NAND_defconfig   |  3 +-
>  configs/T2080QDS_SDCARD_defconfig |  3 +-
>  configs/T2080QDS_SPIFLASH_defconfig   |  3 +-
>  configs/T2080QDS_defconfig|  4 ++-
>  9 files changed, 148 insertions(+), 4 deletions(-)
>  create mode 100644 arch/powerpc/dts/e6500_power_isa.dtsi
>  create mode 100644 arch/powerpc/dts/t2080.dtsi
>  create mode 100644 arch/powerpc/dts/t2080qds.dts
>

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

Re: [U-Boot] [PATCH v2 7/8] powerpc: dts: Add u-boot.dtsi to use binman for MPC85xx boards

[Bin Meng]

On Tue, Aug 28, 2018 at 11:53 AM Jagdish Gediya  wrote:
>
> Signed-off-by: Jagdish Gediya 
> ---
> Changes for v2:
> - Remove mpc85xx-u-boot.dtsi
> - Update u-boot.dtsi to use CONFIG_MPC85XX_HAVE_RESET_VECTOR
>
>  arch/powerpc/dts/u-boot.dtsi | 32 
>  1 file changed, 32 insertions(+)
>  create mode 100644 arch/powerpc/dts/u-boot.dtsi
>

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

Re: [U-Boot] [PATCH v2 3/8] binman: Add a new "skip-at-start" property in Section class

[Bin Meng]

On Tue, Aug 28, 2018 at 11:53 AM Jagdish Gediya  wrote:
>
> Currently binman calculates '_skip_at_start' based on 'end-at-4gb'
> property and it is used for x86 images.
>
> For Powerpc mpc85xx based CPU, CONFIG_SYS_TEXT_BASE is the first

nits: PowerPC

> entry offset which can be 0xeff4 or 0xfff4 for nor flash boot,
> 0x201000 for sd boot etc, so "_skip_at_start" should be set to
> CONFIG_SYS_TEXT_BASE.
>
> 'end-at-4gb' property is not applicable where CONFIG_SYS_TEXT_BASE +
> Image size != 4gb.
>
> Add new property "skip-at-start" in Section class so that
> '_skip_at_start' can be calculated either based on "end-at-4gb"
> or based on "skip-at-start".
>
> Signed-off-by: Jagdish Gediya 
> ---
> Changes for v2:
> - Renamed 'start-pos' property to 'skip-at-start'
> - Updated README
>
>  tools/binman/README  | 9 +
>  tools/binman/bsection.py | 1 +
>  2 files changed, 10 insertions(+)
>

Reviewed-by: Bin Meng 

But two nits below:

> diff --git a/tools/binman/README b/tools/binman/README
> index cb34171..7b4bf2e 100644
> --- a/tools/binman/README
> +++ b/tools/binman/README
> @@ -397,6 +397,15 @@ end-at-4gb:
> 8MB ROM, the offset of the first entry would be 0xfff8 with
> this option, instead of 0 without this option.
>
> +skip-at-start:
> +   This property specifies the first entry offset if not 0.
> +
> +   For Powerpc Book-E architecture, CONFIG_SYS_TEXT_BASE is the first

nits: PowerPC

> +   entry offset which can be 0xeff4 or 0xfff4 for nor flash boot,
> +   0x201000 for sd boot etc.
> +
> +   'end-at-4gb' property is not applicable where CONFIG_SYS_TEXT_BASE +
> +   Image size != 4gb.
>
>  Examples of the above options can be found in the tests. See the
>  tools/binman/test directory.
> diff --git a/tools/binman/bsection.py b/tools/binman/bsection.py
> index a0bd1b6..68997b7 100644
> --- a/tools/binman/bsection.py
> +++ b/tools/binman/bsection.py
> @@ -79,6 +79,7 @@ class Section(object):
>  self._pad_byte = fdt_util.GetInt(self._node, 'pad-byte', 0)
>  self._sort = fdt_util.GetBool(self._node, 'sort-by-offset')
>  self._end_4gb = fdt_util.GetBool(self._node, 'end-at-4gb')
> +self._skip_at_start = fdt_util.GetInt(self._node, 'skip-at-start', 0)
>  if self._end_4gb and not self._size:
>  self._Raise("Section size must be provided when using 
> end-at-4gb")
>  if self._end_4gb:
> --

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

Re: [U-Boot] [PATCH v2 4/8] binman: Add support for Powerpc mpc85xx 'bootpg + resetvec' entry

[Bin Meng]

On Tue, Aug 28, 2018 at 11:53 AM Jagdish Gediya  wrote:
>
> This entry contains the Powerpc mpc85xx boot page and resetvec

nits: PowerPC

Please fix the title as well

> sections.
>
> Signed-off-by: Jagdish Gediya 
> ---
> Changes for v2:
> - Updated README for new binman entry
> - Added test
>
>  tools/binman/README.entries| 14 +++-
>  .../etype/powerpc_mpc85xx_bootpg_resetvec.py   | 25 
> ++
>  tools/binman/ftest.py  |  8 +++
>  .../test/80_powerpc_mpc85xx_bootpg_resetvec.dts| 16 ++
>  4 files changed, 62 insertions(+), 1 deletion(-)
>  create mode 100644 tools/binman/etype/powerpc_mpc85xx_bootpg_resetvec.py
>  create mode 100644 tools/binman/test/80_powerpc_mpc85xx_bootpg_resetvec.dts
>
> diff --git a/tools/binman/README.entries b/tools/binman/README.entries
> index c6e7b22..99440d6 100644
> --- a/tools/binman/README.entries
> +++ b/tools/binman/README.entries
> @@ -221,6 +221,18 @@ See README.x86 for information about Intel binary blobs.
>
>
>
> +Entry: powerpc-mpc85xx-bootpg-resetvec: Powerpc mpc85xx bootpg + resetvec 
> code for U-Boot

nits: PowerPC, please fix this globally in this patch

> +-
> +
> +Properties / Entry arguments:
> +- filename: Filename of u-boot-br.bin (default 'u-boot-br.bin')
> +
> +This enrty is valid for Powerpc mpc85xx cpus. This entry holds
> +'bootpg + resetvec' code for Powerpc mpc85xx CPUs which needs to be
> +placed at offset 'RESET_VECTOR_ADDRESS - 0xffc'.
> +
> +
> +
>  Entry: section: Entry that contains other entries
>  -
>
> @@ -543,7 +555,7 @@ Properties / Entry arguments:
>  - kernelkey: Name of the kernel key to use (inside keydir)
>  - preamble-flags: Value of the vboot preamble flags (typically 0)
>
> -Chromium OS  signs the read-write firmware and kernel, writing the signature
> +Chromium OS signs the read-write firmware and kernel, writing the signature
>  in this block. This allows U-Boot to verify that the next firmware stage
>  and kernel are genuine.
>
> diff --git a/tools/binman/etype/powerpc_mpc85xx_bootpg_resetvec.py 
> b/tools/binman/etype/powerpc_mpc85xx_bootpg_resetvec.py
> new file mode 100644
> index 000..37cf408
> --- /dev/null
> +++ b/tools/binman/etype/powerpc_mpc85xx_bootpg_resetvec.py
> @@ -0,0 +1,25 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +# Copyright 2018 NXP
> +#
> +# Entry-type module for the Powerpc mpc85xx bootpg and resetvec code for 
> U-Boot
> +#
> +
> +from entry import Entry
> +from blob import Entry_blob
> +
> +class Entry_powerpc_mpc85xx_bootpg_resetvec(Entry_blob):
> +"""Powerpc mpc85xx bootpg + resetvec code for U-Boot
> +
> +Properties / Entry arguments:
> +- filename: Filename of u-boot-br.bin (default 'u-boot-br.bin')
> +
> +This enrty is valid for Powerpc mpc85xx cpus. This entry holds
> +'bootpg + resetvec' code for Powerpc mpc85xx CPUs which needs to be
> +placed at offset 'RESET_VECTOR_ADDRESS - 0xffc'.
> +"""
> +
> +def __init__(self, section, etype, node):
> +Entry_blob.__init__(self, section, etype, node)
> +
> +def GetDefaultFilename(self):
> +return 'u-boot-br.bin'
> diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
> index a8456c2..7a6a5ae 100644
> --- a/tools/binman/ftest.py
> +++ b/tools/binman/ftest.py
> @@ -39,6 +39,7 @@ U_BOOT_SPL_DTB_DATA   = 'spldtb'
>  U_BOOT_TPL_DTB_DATA   = 'tpldtb'
>  X86_START16_DATA  = 'start16'
>  X86_START16_SPL_DATA  = 'start16spl'
> +PPC_MPC85XX_BR_DATA   = 'ppcmpc85xxbr'
>  U_BOOT_NODTB_DATA = 'nodtb with microcode pointer somewhere in here'
>  U_BOOT_SPL_NODTB_DATA = 'splnodtb with microcode pointer somewhere in here'
>  FSP_DATA  = 'fsp'
> @@ -90,6 +91,7 @@ class TestFunctional(unittest.TestCase):
>  TestFunctional._MakeInputFile('vga.bin', VGA_DATA)
>  self._ResetDtbs()
>  TestFunctional._MakeInputFile('u-boot-x86-16bit.bin', 
> X86_START16_DATA)
> +TestFunctional._MakeInputFile('u-boot-br.bin', PPC_MPC85XX_BR_DATA)
>  TestFunctional._MakeInputFile('spl/u-boot-x86-16bit-spl.bin',
>X86_START16_SPL_DATA)
>  TestFunctional._MakeInputFile('u-boot-nodtb.bin', U_BOOT_NODTB_DATA)
> @@ -756,6 +758,12 @@ class TestFunctional(unittest.TestCase):
>  data = self._DoReadFile('33_x86-start16.dts')
>  self.assertEqual(X86_START16_DATA, data[:len(X86_START16_DATA)])
>
> +def testPackPowerpcMpc85xxBootpgResetvec(self):
> +"""Test that an image with powerpc-mpc85xx-bootpg-resetvec can be
> +created"""
> +data = self._DoReadFile('80_powerpc_mpc85xx_bootpg_resetvec.dts')
> +self.assertEqual(PPC_MPC85XX_BR_DATA, 
> data[:len(PPC_MPC85XX_BR_DATA)])
> +
>  def _RunMicrocodeTest(self, dts_fname, 

Re: [U-Boot] [PATCH v2 6/8] powerpc: mpc85xx: Use binman to embed dtb inside u-boot

[Bin Meng]

On Tue, Aug 28, 2018 at 11:53 AM Jagdish Gediya  wrote:
>
> Below is the sequence to embed dtb inside u-boot,

nits: U-Boot

> 1. Remove bootpg and resetvec section if needed
> 2. Append dtb
> 3. Append bootpg and resetvec section back if removed in step 1
>
> Above procedure is required only when CONFIG_MPC85xx and
> CONFIG_OF_SEPARATE are defined.
>
> Add new config CONFIG_MPC85XX_HAVE_RESET_VECTOR to indicate that
> image have resetvec section. step 1 and step 3 described above are

have -> has. step 1 -> Step 1

> required only if this config is y.
>
> Signed-off-by: Jagdish Gediya 
> ---
> Changes for v2:
> - Don't change the generic target
> - Add new config option to use binman
>
>  Makefile | 23 ++-
>  arch/powerpc/cpu/mpc85xx/Kconfig |  4 
>  2 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index b5bf8ab..03baa74 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -861,6 +861,10 @@ ifneq ($(CONFIG_SYS_INIT_SP_BSS_OFFSET),)
>  ALL-y += init_sp_bss_offset_check
>  endif
>
> +ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
> +ALL-y += u-boot-with-dtb.bin
> +endif
> +
>  LDFLAGS_u-boot += $(LDFLAGS_FINAL)
>
>  # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
> @@ -983,7 +987,8 @@ spl/u-boot-spl.srec: spl/u-boot-spl FORCE
> $(call if_changed,objcopy)
>
>  OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
> -   $(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec)
> +   $(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec) \
> +   $(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR),-R .bootpg -R 
> .resetvec)
>
>  binary_size_check: u-boot-nodtb.bin FORCE
> @file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
> @@ -1202,6 +1207,18 @@ u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img 
> FORCE
> $(call if_changed,socboot)
>  endif
>
> +ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)

This looks odd. Both CONFIG_OF_SEPARATE and CONFIG_OF_EMBED should be
supported by binman.

> +u-boot-with-dtb.bin: u-boot.bin u-boot.dtb \
> +   $(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR), u-boot-br.bin) FORCE
> +   $(call if_changed,binman)
> +
> +ifeq ($(CONFIG_MPC85XX_HAVE_RESET_VECTOR),y)
> +OBJCOPYFLAGS_u-boot-br.bin := -O binary -j .bootpg -j .resetvec
> +u-boot-br.bin: u-boot FORCE
> +   $(call if_changed,objcopy)
> +endif
> +endif
> +
>  # x86 uses a large ROM. We fill it with 0xff, put the 16-bit stuff (including
>  # reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in
>  # the middle. This is handled by binman based on an image description in the
> @@ -1296,8 +1313,12 @@ spl/u-boot-spl.pbl: spl/u-boot-spl.bin FORCE
>  ifeq ($(ARCH),arm)
>  UBOOT_BINLOAD := u-boot.img
>  else
> +ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
> +UBOOT_BINLOAD := u-boot-with-dtb.bin
> +else
>  UBOOT_BINLOAD := u-boot.bin
>  endif
> +endif
>
>  OBJCOPYFLAGS_u-boot-with-spl-pbl.bin = -I binary -O binary 
> --pad-to=$(CONFIG_SPL_PAD_TO) \
>   --gap-fill=0xff
> diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig 
> b/arch/powerpc/cpu/mpc85xx/Kconfig
> index 19e8d02..7d139ff 100644
> --- a/arch/powerpc/cpu/mpc85xx/Kconfig
> +++ b/arch/powerpc/cpu/mpc85xx/Kconfig
> @@ -1143,6 +1143,10 @@ config ARCH_T4240
> imply CMD_REGINFO
> imply FSL_SATA
>
> +config MPC85XX_HAVE_RESET_VECTOR
> +   bool "Indicate reset vector at CONFIG_RESET_VECTOR_ADDRESS - 0xffc"

I don't think you want people to turn this option on and off, no? You
probably need move the "string" to the help paragraph.

> +   depends on MPC85xx
> +
>  config BOOKE
> bool
> default y
> --

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

Re: [U-Boot] [PATCH v2 5/8] powerpc: mpc85xx: Select BINMAN by default

[Bin Meng]

On Tue, Aug 28, 2018 at 11:53 AM Jagdish Gediya  wrote:
>
> Signed-off-by: Jagdish Gediya 
> ---
>  arch/powerpc/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
>

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

Re: [U-Boot] [PATCH v2 2/8] powerpc/dts: Makefile changes to clean and build dts

[Bin Meng]

On Tue, Aug 28, 2018 at 11:53 AM Jagdish Gediya  wrote:
>
> Signed-off-by: Jagdish Gediya 
> ---
>  arch/powerpc/dts/Makefile | 12 
>  dts/Makefile  |  2 +-
>  2 files changed, 13 insertions(+), 1 deletion(-)
>  create mode 100644 arch/powerpc/dts/Makefile
>

Reviewed-by: Bin Meng 

I think I reviewed this already, and you did not mention any v2
changes. So can you please preserve the review tags in the future when
sending new version series, so that people know they have reviewed the
patch?

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

Re: [U-Boot] [PATCH v2 1/8] powerpc/dts: Define '_end' symbol in mpc85xx u-boot lds files

[Bin Meng]

On Tue, Aug 28, 2018 at 11:53 AM Jagdish Gediya  wrote:
>
> 'board_fdt_blob_setup' function sets up fdt blob at '&_end' so
> define '_end' symbol in mpc85xx lds files.
>
> Signed-off-by: Jagdish Gediya 
> ---
> Changes for v2:
> - Defined '_end' symbol in lds file instead of defining new
>   'board_fdt_blob_setup' function using existing '_init_end' symbol.
>
>  arch/powerpc/cpu/mpc85xx/u-boot-nand.lds | 1 +
>  arch/powerpc/cpu/mpc85xx/u-boot.lds  | 1 +
>  2 files changed, 2 insertions(+)
>

This only updates 2 lds files. Can you update all mpc85xx lds files so
that they are consistent?

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

Re: [U-Boot] [PATCH 11/25] clk: Allow clock defaults to be set also during re-reloc state

[Lokesh Vutla]

On Monday 27 August 2018 09:36 PM, Andreas Dannenberg wrote:
> Hi Kever,
> 
> On Mon, Aug 27, 2018 at 11:26:52AM +0800, Kever Yang wrote:
>> Hi Philipp, Andreas,
>>
>>
>> On 08/25/2018 12:00 AM, Dr. Philipp Tomsich wrote:
 On 24 Aug 2018, at 17:54, Andreas Dannenberg  wrote:

 Philipp,

 On Fri, Aug 24, 2018 at 04:42:15PM +0200, Dr. Philipp Tomsich wrote:
> +Kever
>
>> On 24 Aug 2018, at 16:12, Tom Rini  wrote:
>>
>> On Tue, Aug 21, 2018 at 08:01:49PM +0530, Lokesh Vutla wrote:
>>
>>> From: Andreas Dannenberg 
>>>
>>> The earlier commit f4fcba5c5ba ("clk: implement clk_set_defaults()")
>>> which introduced the functionality for setting clock defaults such as
>>> rates and parents will skip the processing when executing in a re-reloc
>>> state. This for example can prevent the assigning of clock parents
>>> when running in SPL code. Go ahead and remove this limitation.
>>>
>>> Signed-off-by: Andreas Dannenberg 
>>> Signed-off-by: Lokesh Vutla 
>>> ---
>>> drivers/clk/clk-uclass.c | 4 
>>> 1 file changed, 4 deletions(-)
>>>
>>> diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
>>> index 2b15978e14..04b369aa5a 100644
>>> --- a/drivers/clk/clk-uclass.c
>>> +++ b/drivers/clk/clk-uclass.c
>>> @@ -243,10 +243,6 @@ int clk_set_defaults(struct udevice *dev)
>>> {
>>> int ret;
>>>
>>> -   /* If this is running pre-reloc state, don't take any action. */
>>> -   if (!(gd->flags & GD_FLG_RELOC))
>>> -   return 0;
>>> -
>>> debug("%s(%s)\n", __func__, dev_read_name(dev));
>>>
>>> ret = clk_set_default_parents(dev);
>> Philipp? David?  Comments?  Thanks!
> If I remember correctly, David had a concern regarding an increase in
> boottime if we ran this twice… adding Kever, as he was also involved
> in the discussion.
>
> I settled on skipping it for pre-reloc, but it’s an imperfect solution: 
> the
> boottime increase comes from the fact that some devices have a large
> number of assigned-clocks, that the device-tree processing has a cost,
> and that we don’t have a way of synchronising between SPL and full
> U-Boot to avoid redoing the complete init-flow.
 Good to know some of the background; when I did this patch initially it
 was not really clear why this was removed and it obviously was an issue
 for what I was doing that I had to overcome and re-adding this was the
 simpliest thing to do at that time.

> Maybe we should have a SPL-specific property for the assigned-clocks
> to be set pre-reloc?
 Need to think about this some more. Generally we probably want to do as
 little as possible before relocation. Unfortunately for the K3 family of
 SoCs much is dependent on loading/installing the system firmware (SYSFW)
 image including to get DDR operational which itself requires us to use a
 lot of DT/DM stuff pre-reloc. So a little bit of a chicken and egg
 problem…
>> 'pre-reloc' is used in SPL and U-Boot before relocate, I think this
>> should be
>> clear to be as simple as possible, but now it's going to much like U-Boot
>> proper. It have 2 problem: code size and boot time．
>> Every feature will increase the code size, in Rockchip platform, we run SPL
>> in sram which have size limit, and the common code of upstream feature
>> update often break the size limit. In this case I want to add TPL for
>> all Rockchip
>> SoCs and used for ddr init only so that SPL will not have the size limit.
>> For boot time, you need to understand that the module tag as 'pre-reloc'
>> will
>> be binded twice in U-Boot proper and also twice in SPL. I hope we only
>> do things
>> we need for SPL and U-Boot proper, but not too much overhead by framework.
>> The API like clk_set_defaults() is able to used in every module, better
>> to use in
>> U-Boot Proper while the SPL should have a clear white list modules.
>>
>> For example, we get everything from DTS for ddr node, but not using the
>> clk_set_defaults().
> 
> As Lokesh noted in the other email, we technically no longer need the
> patch to undo the setting of the clock defaults as we since hard-coded
> the UART clock frequency which in an earlier (pre-public) version of our
> tree was derived from the central "System Management Controller" and
> was dependent on this patch.
> 
> Yes doing the same thing twice or three times is not efficient also from
> a boot time POV. In addition, parsing the DT over and over takes a
> significant amount of time (I work on "simulated" devices in a silicon
> design environment so I know exactly how many minutes in that case are
> spent parsing the DT... :)
> 
> But I think it would be cleaner to not abort clk_set_defaults() if
> GD_FLG_RELOC is not set, but rather what Lokesh suggested to use
> CONFIG_OF_SPL_REMOVE_PROPS? Would that work 

[U-Boot] [PATCH v3] usb: dwc2: Add reset ctrl to driver

[Ley Foon Tan]

Add code to reset all reset signals as in usb DT node. A reset property
is an optional feature, so only print out a warning and do not fail if a
reset property is not present.

If a reset property is discovered, then use it to deassert, thus
bringing the IP out of reset.

Signed-off-by: Ley Foon Tan 

---
v3:
- Add error handling when return non-zero from reset_get_bulk().

v2:
- Add reset_release_bulk() in _remove function.
---
 drivers/usb/host/dwc2.c |   37 +
 1 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index cbe065b..b6f008a 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dwc2.h"
 
@@ -49,6 +50,8 @@ struct dwc2_priv {
 */
bool hnp_srp_disable;
bool oc_disable;
+
+   struct reset_ctl_bulk   resets;
 };
 
 #ifndef CONFIG_DM_USB
@@ -1124,11 +1127,43 @@ int _submit_int_msg(struct dwc2_priv *priv, struct 
usb_device *dev,
}
 }
 
+static int dwc2_reset(struct udevice *dev)
+{
+   int ret;
+   struct dwc2_priv *priv = dev_get_priv(dev);
+
+   ret = reset_get_bulk(dev, >resets);
+   if (ret) {
+   dev_warn(dev, "Can't get reset: %d\n", ret);
+   /* Return 0 if error due to !CONFIG_DM_RESET and reset
+* DT property is not present.
+*/
+   if (ret == -ENOENT || ret == -ENOTSUPP)
+   return 0;
+   else
+   return ret;
+   }
+
+   ret = reset_deassert_bulk(>resets);
+   if (ret) {
+   reset_release_bulk(>resets);
+   dev_err(dev, "Failed to reset: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
 {
struct dwc2_core_regs *regs = priv->regs;
uint32_t snpsid;
int i, j;
+   int ret;
+
+   ret = dwc2_reset(dev);
+   if (ret)
+   return ret;
 
snpsid = readl(>gsnpsid);
dev_info(dev, "Core Release: %x.%03x\n",
@@ -1303,6 +1338,8 @@ static int dwc2_usb_remove(struct udevice *dev)
 
dwc2_uninit_common(priv->regs);
 
+   reset_release_bulk(>resets);
+
return 0;
 }
 
-- 
1.7.1

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

[U-Boot] [PATCH v3 2/2] gpio: dwapb_gpio: Add reset ctrl to driver

[Ley Foon Tan]

Add code to reset all reset signals as in gpio DT node. A reset property
is an optional feature, so only print out a warning and do not fail if a
reset property is not present.

If a reset property is discovered, then use it to deassert, thus
bringing the IP out of reset.

Signed-off-by: Ley Foon Tan 

---
v3:
- Add .remove function.
- Add error handling when return non-zero from reset_get_bulk().

v2:
- Move reset to probe() function.
---
 drivers/gpio/dwapb_gpio.c |   42 --
 1 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
index 7cf2d47..6394fa9 100644
--- a/drivers/gpio/dwapb_gpio.c
+++ b/drivers/gpio/dwapb_gpio.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -99,13 +100,42 @@ static const struct dm_gpio_ops gpio_dwapb_ops = {
.get_function   = dwapb_gpio_get_function,
 };
 
+static int gpio_dwapb_reset(struct udevice *dev)
+{
+   int ret;
+   struct gpio_dev_priv *priv = dev_get_uclass_priv(dev);
+
+   ret = reset_get_bulk(dev, >resets);
+   if (ret) {
+   dev_warn(dev, "Can't get reset: %d\n", ret);
+   /* Return 0 if error due to !CONFIG_DM_RESET and reset
+* DT property is not present.
+*/
+   if (ret == -ENOENT || ret == -ENOTSUPP)
+   return 0;
+   else
+   return ret;
+   }
+
+   ret = reset_deassert_bulk(>resets);
+   if (ret) {
+   reset_release_bulk(>resets);
+   dev_err(dev, "Failed to reset: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 static int gpio_dwapb_probe(struct udevice *dev)
 {
struct gpio_dev_priv *priv = dev_get_uclass_priv(dev);
struct gpio_dwapb_platdata *plat = dev->platdata;
 
-   if (!plat)
-   return 0;
+   if (!plat) {
+   /* Reset on parent device only */
+   return gpio_dwapb_reset(dev);
+   }
 
priv->gpio_count = plat->pins;
priv->bank_name = plat->name;
@@ -166,6 +196,13 @@ err:
return ret;
 }
 
+static int gpio_dwapb_remove(struct udevice *dev)
+{
+   struct gpio_dev_priv *priv = dev_get_uclass_priv(dev);
+
+   return reset_release_bulk(>resets);
+}
+
 static const struct udevice_id gpio_dwapb_ids[] = {
{ .compatible = "snps,dw-apb-gpio" },
{ }
@@ -178,4 +215,5 @@ U_BOOT_DRIVER(gpio_dwapb) = {
.ops= _dwapb_ops,
.bind   = gpio_dwapb_bind,
.probe  = gpio_dwapb_probe,
+   .remove = gpio_dwapb_remove,
 };
-- 
1.7.1

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

[U-Boot] [PATCH v3 1/2] gpio: Add struct reset_ctl_bulk

[Ley Foon Tan]

Add struct reset_ctl_bulk to struct gpio_dev_priv to support reset control
in GPIO driver.

Signed-off-by: Ley Foon Tan 
---
 include/asm-generic/gpio.h |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index d036026..9fd5808 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -8,6 +8,7 @@
 #define _ASM_GENERIC_GPIO_H_
 
 #include 
+#include 
 
 struct ofnode_phandle_args;
 
@@ -318,6 +319,7 @@ struct gpio_dev_priv {
unsigned gpio_count;
unsigned gpio_base;
char **name;
+   struct reset_ctl_bulk resets;
 };
 
 /* Access the GPIO operations for a device */
-- 
1.7.1

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

Re: [U-Boot] [PATCH v2 07/13] x86: Fix signed shift overflow in MSR_IA32_APICBASE_BASE

[Andy Shevchenko]

On Tue, Aug 28, 2018 at 5:06 AM Bin Meng  wrote:
> On Mon, Aug 27, 2018 at 7:19 AM Eugeniu Rosca  wrote:


> > -#define MSR_IA32_APICBASE_BASE (0xf<<12)
> > +#define MSR_IA32_APICBASE_BASE (0xfUL << 12)
>
> I don't understand why such warnings is emitted: "left shift of
> 1048575 by 12 places cannot be represented in type 'int'"

Because it can't.

1 << 30 (fine)
1 << 31 (UB!)

This is good explained in the C standard for ages.

> Compilers don't complain this code and Linux kernel has the same
> definition here.

Someone suppressed those warnings. But they are valid.

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

[U-Boot] u-boot release and feature set

[Prabhakar Kushwaha]

Hi Tom,

Every u-boot release announcement has a very high level feature set.
I am wondering, if you also maintain detailed feature list  per u-boot release? 

I can see "Statistics" details per release from 
https://www.denx.de/wiki/U-Boot/ReleaseCycle but not the feature set.
May be I am looking at wrong place ☹

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

Re: [U-Boot] [PATCH v2 07/13] x86: Fix signed shift overflow in MSR_IA32_APICBASE_BASE

[Eugeniu Rosca]

Hi Bin,

cc: Masahiro, Andrey

On Tue, Aug 28, 2018 at 10:05:51AM +0800, Bin Meng wrote:
> Hi Eugeniu,
> 
> On Mon, Aug 27, 2018 at 7:19 AM Eugeniu Rosca  wrote:
> >
> > Fix the following UBSAN report:
> >  ==
> >  UBSAN: Undefined behaviour in arch/x86/cpu/lapic.c:73:14
> >  left shift of 1048575 by 12 places cannot be represented in type 'int'
> >  ==
> >
> > Steps to reproduce the above:
> > * echo CONFIG_UBSAN=y >> configs/qemu-x86_defconfig
> > * make ARCH=x86 qemu-x86_defconfig all
> > * qemu-system-i386 --version
> >   QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.31)
> > * qemu-system-i386 --nographic -bios u-boot.rom
> >
> > Fixes: 98568f0fa96b ("x86: Import MSR/MTRR code from Linux")
> > Signed-off-by: Eugeniu Rosca 
> > ---
> >
> > Changes in v2:
> >  - None. Newly pushed.
> > ---
> >  arch/x86/include/asm/msr-index.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/msr-index.h 
> > b/arch/x86/include/asm/msr-index.h
> > index 9c1dbe61d596..d8b7b8013c74 100644
> > --- a/arch/x86/include/asm/msr-index.h
> > +++ b/arch/x86/include/asm/msr-index.h
> > @@ -370,7 +370,7 @@
> >  #define MSR_IA32_APICBASE  0x001b
> >  #define MSR_IA32_APICBASE_BSP  (1<<8)
> >  #define MSR_IA32_APICBASE_ENABLE   (1<<11)
> > -#define MSR_IA32_APICBASE_BASE (0xf<<12)
> > +#define MSR_IA32_APICBASE_BASE (0xfUL << 12)
> 
> I don't understand why such warnings is emitted: "left shift of
> 1048575 by 12 places cannot be represented in type 'int'"
> 
> Compilers don't complain this code and Linux kernel has the same
> definition here.

I wrote a basic kernel module printing the result of "(0xf << 12)"
and kernel UBSAN doesn't complain indeed.

I started to compare the compiler flags between Linux and U-Boot and
nailed down empirically that Linux UBSAN warning is inhibited by the
-fno-strict-overflow gcc option, introduced in Linux commit [1]. The
latter actually replaces another gcc option -fwrapv, introduced in [2].

Any of the two flags makes the UBSAN error vanish in the kernel.
Neither of the two flags is used in U-Boot.

I am in the process of browsing some documentation related to -fwrapv
and -fno-strict-overflow (e.g. [3]). Please, feel free to share any
thoughts and/or cc anybody who might have dealt with these topics
in the past. I will come back with more feedback later.

[1] v2.6.31 commit a137802ee839 ("Don't use '-fwrapv' compiler option: it's 
buggy in gcc-4.1.x")
[2] v2.6.29 commit 68df3755e383 ("Add '-fwrapv' to gcc CFLAGS")
[3] https://www.airs.com/blog/archives/120

> Regards,
> Bin

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

[U-Boot] [PATCH v4 4/7] ARM: dts: rockchip: ADD dp83867 CLK_OUT muxing

[Janine Hagemann]

The CLK_O_SEL default is synchronus to XI input clock,
which is 25 MHz. Set CLK_O_SEL to channel A transmit
clock so we have 125 MHz on CLK_OUT.

Signed-off-by: Janine Hagemann 
---
v4: No changes
---
 arch/arm/dts/rk3288-phycore-som.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/rk3288-phycore-som.dtsi 
b/arch/arm/dts/rk3288-phycore-som.dtsi
index 02d1196..2dba0aa 100644
--- a/arch/arm/dts/rk3288-phycore-som.dtsi
+++ b/arch/arm/dts/rk3288-phycore-som.dtsi
@@ -191,6 +191,7 @@
ti,tx-internal-delay = ;
ti,fifo-depth = ;
enet-phy-lane-no-swap;
+   ti,clk-output-sel = ;
};
};
 };
-- 
2.7.4

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

[U-Boot] [PATCH v4 7/7] net: gmac_rockchip: Add handeling for RGMII_ID/RXID/TXID

[Janine Hagemann]

Using PHY internal delays in combination with the phy-mode
rgmii-id/rxid/txid was not possible. Only rgmii was supported.

Now we can disable rockchip's gmac delay lines and also use
rgmii-id/rxid/txid.

Based on commit eaf70ad14cbb ("net: stmmac: dwmac-rk: Add
handling for RGMII_ID/RXID/TXID") for mainline linux kernel.

Signed-off-by: Janine Hagemann 
Acked-by: Joe Hershberger 
---
v4: No changes
---
 drivers/net/gmac_rockchip.c | 80 +++--
 1 file changed, 63 insertions(+), 17 deletions(-)

diff --git a/drivers/net/gmac_rockchip.c b/drivers/net/gmac_rockchip.c
index 0f91731..c01ae75 100644
--- a/drivers/net/gmac_rockchip.c
+++ b/drivers/net/gmac_rockchip.c
@@ -24,6 +24,11 @@
 #include 
 #include "designware.h"
 
+DECLARE_GLOBAL_DATA_PTR;
+#define DELAY_ENABLE(soc, tx, rx) \
+   (((tx) ? soc##_TXCLK_DLY_ENA_GMAC_ENABLE : 
soc##_TXCLK_DLY_ENA_GMAC_DISABLE) | \
+   ((rx) ? soc##_RXCLK_DLY_ENA_GMAC_ENABLE : 
soc##_RXCLK_DLY_ENA_GMAC_DISABLE))
+
 /*
  * Platform data for the gmac
  *
@@ -286,8 +291,7 @@ static void rk3228_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 RK3228_RXCLK_DLY_ENA_GMAC_MASK |
 RK3228_TXCLK_DLY_ENA_GMAC_MASK,
 RK3228_GMAC_PHY_INTF_SEL_RGMII |
-RK3228_RXCLK_DLY_ENA_GMAC_ENABLE |
-RK3228_TXCLK_DLY_ENA_GMAC_ENABLE);
+DELAY_ENABLE(RK3228, pdata->tx_delay, pdata->rx_delay));
 
rk_clrsetreg(>mac_con[0],
 RK3228_CLK_RX_DL_CFG_GMAC_MASK |
@@ -310,8 +314,7 @@ static void rk3288_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 RK3288_TXCLK_DLY_ENA_GMAC_MASK |
 RK3288_CLK_RX_DL_CFG_GMAC_MASK |
 RK3288_CLK_TX_DL_CFG_GMAC_MASK,
-RK3288_RXCLK_DLY_ENA_GMAC_ENABLE |
-RK3288_TXCLK_DLY_ENA_GMAC_ENABLE |
+DELAY_ENABLE(RK3288, pdata->rx_delay, pdata->tx_delay) |
 pdata->rx_delay << RK3288_CLK_RX_DL_CFG_GMAC_SHIFT |
 pdata->tx_delay << RK3288_CLK_TX_DL_CFG_GMAC_SHIFT);
 }
@@ -350,8 +353,7 @@ static void rk3328_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 RK3328_RXCLK_DLY_ENA_GMAC_MASK |
 RK3328_TXCLK_DLY_ENA_GMAC_MASK,
 RK3328_GMAC_PHY_INTF_SEL_RGMII |
-RK3328_RXCLK_DLY_ENA_GMAC_ENABLE |
-RK3328_TXCLK_DLY_ENA_GMAC_ENABLE);
+DELAY_ENABLE(RK3328, pdata->tx_delay, pdata->rx_delay));
 
rk_clrsetreg(>mac_con[0],
 RK3328_CLK_RX_DL_CFG_GMAC_MASK |
@@ -392,8 +394,7 @@ static void rk3368_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 RK3368_TXCLK_DLY_ENA_GMAC_MASK |
 RK3368_CLK_RX_DL_CFG_GMAC_MASK |
 RK3368_CLK_TX_DL_CFG_GMAC_MASK,
-RK3368_RXCLK_DLY_ENA_GMAC_ENABLE |
-RK3368_TXCLK_DLY_ENA_GMAC_ENABLE |
+DELAY_ENABLE(RK3368, pdata->tx_delay, pdata->rx_delay) |
 pdata->rx_delay << RK3368_CLK_RX_DL_CFG_GMAC_SHIFT |
 pdata->tx_delay << RK3368_CLK_TX_DL_CFG_GMAC_SHIFT);
 }
@@ -413,8 +414,7 @@ static void rk3399_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 RK3399_TXCLK_DLY_ENA_GMAC_MASK |
 RK3399_CLK_RX_DL_CFG_GMAC_MASK |
 RK3399_CLK_TX_DL_CFG_GMAC_MASK,
-RK3399_RXCLK_DLY_ENA_GMAC_ENABLE |
-RK3399_TXCLK_DLY_ENA_GMAC_ENABLE |
+DELAY_ENABLE(RK3399, pdata->tx_delay, pdata->rx_delay) |
 pdata->rx_delay << RK3399_CLK_RX_DL_CFG_GMAC_SHIFT |
 pdata->tx_delay << RK3399_CLK_TX_DL_CFG_GMAC_SHIFT);
 }
@@ -451,40 +451,86 @@ static int gmac_rockchip_probe(struct udevice *dev)
 
switch (eth_pdata->phy_interface) {
case PHY_INTERFACE_MODE_RGMII:
+   /* Set to RGMII mode */
+   if (ops->set_to_rgmii)
+   ops->set_to_rgmii(pdata);
+   else
+   return -EPERM;
+
/*
 * If the gmac clock is from internal pll, need to set and
 * check the return value for gmac clock at RGMII mode. If
 * the gmac clock is from external source, the clock rate
 * is not set, because of it is bypassed.
 */
+
if (!pdata->clock_input) {
rate = clk_set_rate(, 12500);
if (rate != 12500)
return -EINVAL;
}
+   break;
 
+   case PHY_INTERFACE_MODE_RGMII_ID:
/* Set to RGMII mode */
-   if (ops->set_to_rgmii)
+   if (ops->set_to_rgmii) {
+

[U-Boot] [PATCH v4 6/7] net: gmac_rockchip: Fix a register write in rk3328_gmac_set_to_rgmii

[Janine Hagemann]

We have to use RK3328_RXCLK_DLY_ENA_GMAC_ENABLE instead of
RK3328_RXCLK_DLY_ENA_GMAC_MASK in rk3328_gmac_set_to_rgmii()
to enable the RX delay.
The MASK was used in a wrong way.

Signed-off-by: Janine Hagemann 
Reviewed-by: Philipp Tomisch 
Acked-by: Joe Hershberger 
---
v4: No changes
---
 drivers/net/gmac_rockchip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/gmac_rockchip.c b/drivers/net/gmac_rockchip.c
index 30a24d1..0f91731 100644
--- a/drivers/net/gmac_rockchip.c
+++ b/drivers/net/gmac_rockchip.c
@@ -350,7 +350,7 @@ static void rk3328_gmac_set_to_rgmii(struct 
gmac_rockchip_platdata *pdata)
 RK3328_RXCLK_DLY_ENA_GMAC_MASK |
 RK3328_TXCLK_DLY_ENA_GMAC_MASK,
 RK3328_GMAC_PHY_INTF_SEL_RGMII |
-RK3328_RXCLK_DLY_ENA_GMAC_MASK |
+RK3328_RXCLK_DLY_ENA_GMAC_ENABLE |
 RK3328_TXCLK_DLY_ENA_GMAC_ENABLE);
 
rk_clrsetreg(>mac_con[0],
-- 
2.7.4

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

[U-Boot] [PATCH v4 3/3] net: phy: ti: Add binding for the CLK_OUT pin muxing

[Janine Hagemann]

The DP83867 has a muxing option for the CLK_OUT pin. It is possible
to set CLK_OUT for different channels.
Create a binding to select a specific clock for CLK_OUT pin.

Based on commit 9708fb630d19 ("net: phy: dp83867: Add binding for
the CLK_OUT pin muxing option") of mainline linux kernel.

Signed-off-by: Janine Hagemann 
---
 doc/device-tree-bindings/net/ti,dp83867.txt |  3 +++
 drivers/net/phy/ti.c| 26 ++
 include/dt-bindings/net/ti-dp83867.h| 15 +++
 3 files changed, 44 insertions(+)

diff --git a/doc/device-tree-bindings/net/ti,dp83867.txt 
b/doc/device-tree-bindings/net/ti,dp83867.txt
index f31c2da..034146f 100644
--- a/doc/device-tree-bindings/net/ti,dp83867.txt
+++ b/doc/device-tree-bindings/net/ti,dp83867.txt
@@ -12,6 +12,8 @@ Required properties:
compensate for the board being designed with the lanes swapped.
- enet-phy-no-lane-swap - Indicates that PHY will disable swap of the
TX/RX lanes.
+   - ti,clk-output-sel - Clock output select - see 
dt-bindings/net/ti-dp83867.h
+   for applicable values
 
 Default child nodes are standard Ethernet PHY device
 nodes as described in doc/devicetree/bindings/net/ethernet.txt
@@ -24,6 +26,7 @@ Example:
ti,tx-internal-delay = ;
ti,fifo-depth = ;
enet-phy-lane-no-swap;
+   ti,clk-output-sel = ;
};
 
 Datasheet can be found:
diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index 120867e..d443266 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -93,6 +93,8 @@
 
 #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX0x0
 #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN0x1f
+#define DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT 8
+#define DP83867_IO_MUX_CFG_CLK_O_SEL_MASK  GENMASK(0x1f, 
DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT)
 
 /* CFG4 bits */
 #define DP83867_CFG4_PORT_MIRROR_ENBIT(0)
@@ -110,6 +112,7 @@ struct dp83867_private {
int io_impedance;
bool rxctrl_strap_quirk;
int port_mirroring;
+   int clk_output_sel;
 };
 
 /**
@@ -208,6 +211,18 @@ static int dp83867_of_init(struct phy_device *phydev)
 {
struct dp83867_private *dp83867 = phydev->priv;
ofnode node;
+   u16 val;
+
+   /* Optional configuration */
+
+   /*
+* Keep the default value if ti,clk-output-sel is not set
+* or to high
+*/
+
+   dp83867->clk_output_sel = ofnode_read_u32_default(node,
+ "ti,clk-output-sel",
+  DP83867_CLK_O_SEL_REF_CLK);
 
node = phy_get_ofnode(phydev);
if (!ofnode_valid(node))
@@ -239,6 +254,17 @@ static int dp83867_of_init(struct phy_device *phydev)
dp83867->port_mirroring = DP83867_PORT_MIRRORING_DIS;
 
 
+   /* Clock output selection if muxing property is set */
+   if (dp83867->clk_output_sel != DP83867_CLK_O_SEL_REF_CLK) {
+   val = phy_read_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+   DP83867_DEVADDR, phydev->addr);
+   val &= ~DP83867_IO_MUX_CFG_CLK_O_SEL_MASK;
+   val |= (dp83867->clk_output_sel <<
+   DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT);
+   phy_write_mmd_indirect(phydev, DP83867_IO_MUX_CFG,
+   DP83867_DEVADDR, phydev->addr, val);
+   }
+
return 0;
 }
 #else
diff --git a/include/dt-bindings/net/ti-dp83867.h 
b/include/dt-bindings/net/ti-dp83867.h
index b8e5df6..85d08f6 100644
--- a/include/dt-bindings/net/ti-dp83867.h
+++ b/include/dt-bindings/net/ti-dp83867.h
@@ -31,4 +31,19 @@
 #define DP83867_RGMIIDCTL_3_75_NS  0xe
 #define DP83867_RGMIIDCTL_4_00_NS  0xf
 
+/* IO_MUX_CFG - Clock output selection */
+#define DP83867_CLK_O_SEL_CHN_A_RCLK   0x0
+#define DP83867_CLK_O_SEL_CHN_B_RCLK   0x1
+#define DP83867_CLK_O_SEL_CHN_C_RCLK   0x2
+#define DP83867_CLK_O_SEL_CHN_D_RCLK   0x3
+#define DP83867_CLK_O_SEL_CHN_A_RCLK_DIV5  0x4
+#define DP83867_CLK_O_SEL_CHN_B_RCLK_DIV5  0x5
+#define DP83867_CLK_O_SEL_CHN_C_RCLK_DIV5  0x6
+#define DP83867_CLK_O_SEL_CHN_D_RCLK_DIV5  0x7
+#define DP83867_CLK_O_SEL_CHN_A_TCLK   0x8
+#define DP83867_CLK_O_SEL_CHN_B_TCLK   0x9
+#define DP83867_CLK_O_SEL_CHN_C_TCLK   0xA
+#define DP83867_CLK_O_SEL_CHN_D_TCLK   0xB
+#define DP83867_CLK_O_SEL_REF_CLK  0xC
+
 #endif
-- 
2.7.4

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

[U-Boot] [PATCH v4 2/3] net: phy: ti: Recover from "port mirroring" N/A MODE4

[Janine Hagemann]

The DP83867 when not properly bootstrapped - especially with LED_0 pin -
can enter N/A MODE4 for "port mirroring" feature.

To provide normal operation of the PHY, one needs not only to explicitly
disable the port mirroring feature, but as well stop some IC internal
testing (which disables RGMII communication).

To do that the STRAP_STS1 (0x006E) register must be read and RESERVED bit
11 examined. When it is set, the another RESERVED bit (11) at PHYCR
(0x0010) register must be clear to disable testing mode and enable RGMII
communication.

Thorough explanation of the problem can be found at following e2e thread:
"DP83867IR: Problem with RESERVED bits in PHY Control Register (PHYCR) -
Linux driver"

https://e2e.ti.com/support/interface/ethernet/f/903/p/571313/2096954#2096954

Based on commit ac6e058b75be ("net: phy: dp83867: Recover from "port mirroring"
N/A MODE4") of mainline linux kernel.

Signed-off-by: Janine Hagemann 
Acked-by: Joe Hershberger 
Acked-by: Lukasz Majewski 
---
 drivers/net/phy/ti.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index b5fa687..120867e 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -24,6 +24,7 @@
 /* Extended Registers */
 #define DP83867_CFG4   0x0031
 #define DP83867_RGMIICTL   0x0032
+#define DP83867_STRAP_STS1 0x006E
 #define DP83867_RGMIIDCTL  0x0086
 #define DP83867_IO_MUX_CFG 0x0170
 
@@ -48,8 +49,12 @@
 #define DP83867_RGMII_TX_CLK_DELAY_EN  BIT(1)
 #define DP83867_RGMII_RX_CLK_DELAY_EN  BIT(0)
 
+/* STRAP_STS1 bits */
+#define DP83867_STRAP_STS1_RESERVEDBIT(11)
+
 /* PHY CTRL bits */
 #define DP83867_PHYCR_FIFO_DEPTH_SHIFT 14
+#define DP83867_PHYCR_RESERVED_MASKBIT(11)
 #define DP83867_MDI_CROSSOVER  5
 #define DP83867_MDI_CROSSOVER_AUTO 2
 #define DP83867_MDI_CROSSOVER_MDIX 2
@@ -254,7 +259,7 @@ static int dp83867_config(struct phy_device *phydev)
 {
struct dp83867_private *dp83867;
unsigned int val, delay, cfg2;
-   int ret;
+   int ret, bs;
 
if (!phydev->priv) {
dp83867 = kzalloc(sizeof(*dp83867), GFP_KERNEL);
@@ -289,6 +294,25 @@ static int dp83867_config(struct phy_device *phydev)
(dp83867->fifo_depth << 
DP83867_PHYCR_FIFO_DEPTH_SHIFT));
if (ret)
goto err_out;
+
+   /* The code below checks if "port mirroring" N/A MODE4 has been
+* enabled during power on bootstrap.
+*
+* Such N/A mode enabled by mistake can put PHY IC in some
+* internal testing mode and disable RGMII transmission.
+*
+* In this particular case one needs to check STRAP_STS1
+* register's bit 11 (marked as RESERVED).
+*/
+
+   bs = phy_read_mmd_indirect(phydev, DP83867_STRAP_STS1,
+   DP83867_DEVADDR, phydev->addr);
+   val = phy_read(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL);
+   if (bs & DP83867_STRAP_STS1_RESERVED) {
+   val &= ~DP83867_PHYCR_RESERVED_MASK;
+   phy_write(phydev, MDIO_DEVAD_NONE, MII_DP83867_PHYCTRL, 
val);
+   }
+
} else if (phy_interface_is_sgmii(phydev)) {
phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR,
  (BMCR_ANENABLE | BMCR_FULLDPLX | BMCR_SPEED1000));
-- 
2.7.4

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

[U-Boot] [PATCH v4 1/3] net: phy: ti: Add lane swapping support in the DP83867 TI's PHY driver

[Janine Hagemann]

This patch adds support for enabling or disabling the lane swapping
(called "port mirroring" in PHY's CFG4 register) feature of the DP83867
TI's PHY device.

One use case is when bootstrap configuration enables this feature (because
of e.g. LED_0 wrong wiring) so then one needs to disable it in software
(at u-boot/Linux).

Based on commit fc6d39c39581 ("net: phy: dp83867: Add lane swapping
support in the DP83867 TI's PHY driver") of mainline linux kernel.

Signed-off-by: Janine Hagemann 
Acked-by: Lukasz Majewski 
Acked-by: Joe Hershberger 
---
 doc/device-tree-bindings/net/ti,dp83867.txt |  5 
 drivers/net/phy/ti.c| 39 +
 2 files changed, 44 insertions(+)

diff --git a/doc/device-tree-bindings/net/ti,dp83867.txt 
b/doc/device-tree-bindings/net/ti,dp83867.txt
index cb77fdf..f31c2da 100644
--- a/doc/device-tree-bindings/net/ti,dp83867.txt
+++ b/doc/device-tree-bindings/net/ti,dp83867.txt
@@ -8,6 +8,10 @@ Required properties:
for applicable values
- ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h
for applicable values
+   - enet-phy-lane-swap - Indicates that PHY will swap the TX/RX lanes to
+   compensate for the board being designed with the lanes swapped.
+   - enet-phy-no-lane-swap - Indicates that PHY will disable swap of the
+   TX/RX lanes.
 
 Default child nodes are standard Ethernet PHY device
 nodes as described in doc/devicetree/bindings/net/ethernet.txt
@@ -19,6 +23,7 @@ Example:
ti,rx-internal-delay = ;
ti,tx-internal-delay = ;
ti,fifo-depth = ;
+   enet-phy-lane-no-swap;
};
 
 Datasheet can be found:
diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c
index f870e6d..b5fa687 100644
--- a/drivers/net/phy/ti.c
+++ b/drivers/net/phy/ti.c
@@ -89,12 +89,22 @@
 #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MAX0x0
 #define DP83867_IO_MUX_CFG_IO_IMPEDANCE_MIN0x1f
 
+/* CFG4 bits */
+#define DP83867_CFG4_PORT_MIRROR_ENBIT(0)
+
+enum {
+   DP83867_PORT_MIRRORING_KEEP,
+   DP83867_PORT_MIRRORING_EN,
+   DP83867_PORT_MIRRORING_DIS,
+};
+
 struct dp83867_private {
int rx_id_delay;
int tx_id_delay;
int fifo_depth;
int io_impedance;
bool rxctrl_strap_quirk;
+   int port_mirroring;
 };
 
 /**
@@ -163,6 +173,26 @@ void phy_write_mmd_indirect(struct phy_device *phydev, int 
prtad,
phy_write(phydev, addr, MII_MMD_DATA, data);
 }
 
+static int dp83867_config_port_mirroring(struct phy_device *phydev)
+{
+   struct dp83867_private *dp83867 =
+   (struct dp83867_private *)phydev->priv;
+   u16 val;
+
+   val = phy_read_mmd_indirect(phydev, DP83867_CFG4, DP83867_DEVADDR,
+phydev->addr);
+
+   if (dp83867->port_mirroring == DP83867_PORT_MIRRORING_EN)
+   val |= DP83867_CFG4_PORT_MIRROR_EN;
+   else
+   val &= ~DP83867_CFG4_PORT_MIRROR_EN;
+
+   phy_write_mmd_indirect(phydev, DP83867_CFG4, DP83867_DEVADDR,
+   phydev->addr, val);
+
+   return 0;
+}
+
 #if defined(CONFIG_DM_ETH)
 /**
  * dp83867_data_init - Convenience function for setting PHY specific data
@@ -197,6 +227,12 @@ static int dp83867_of_init(struct phy_device *phydev)
 
dp83867->fifo_depth = ofnode_read_u32_default(node, "ti,fifo-depth",
  -1);
+   if (ofnode_read_bool(node, "enet-phy-lane-swap"))
+   dp83867->port_mirroring = DP83867_PORT_MIRRORING_EN;
+
+   if (ofnode_read_bool(node, "enet-phy-lane-no-swap"))
+   dp83867->port_mirroring = DP83867_PORT_MIRRORING_DIS;
+
 
return 0;
 }
@@ -315,6 +351,9 @@ static int dp83867_config(struct phy_device *phydev)
}
}
 
+   if (dp83867->port_mirroring != DP83867_PORT_MIRRORING_KEEP)
+   dp83867_config_port_mirroring(phydev);
+
genphy_config_aneg(phydev);
return 0;
 
-- 
2.7.4

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

[U-Boot] [PATCH v4 0/3] Expand dp83867-driver

[Janine Hagemann]

- Add enet-phy-lane-(no)-swap to the documentaion

Janine Hagemann (3):
  net: phy: ti: Add lane swapping support in the DP83867 TI's PHY driver
  net: phy: ti: Recover from "port mirroring" N/A MODE4
  net: phy: ti: Add binding for the CLK_OUT pin muxing

 doc/device-tree-bindings/net/ti,dp83867.txt |  8 +++
 drivers/net/phy/ti.c| 91 -
 include/dt-bindings/net/ti-dp83867.h| 15 +
 3 files changed, 113 insertions(+), 1 deletion(-)

-- 
2.7.4

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

[U-Boot] [PATCH v4 3/7] drivers: net: designware: Add reading of DT phy-handle node

[Janine Hagemann]

Add the ability to read the phy-handle node of the
gmac.  Upon reading this handle the phy-id
can be stored based on the reg node in the DT.

The phy-handle also needs to be stored and passed
to the phy to access any phy data that is available.

Signed-off-by: Janine Hagemann 
Acked-by: Joe Hershberger 
---
v4: Change used function from dev_set_of_offset( ) to
offset_to_ofnode( )
---
 drivers/net/designware.c | 11 ++-
 drivers/net/designware.h |  1 +
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 19db0a8..bba12f2 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -477,7 +477,7 @@ static int dw_phy_init(struct dw_eth_dev *priv, void *dev)
 {
struct phy_device *phydev;
int mask = 0x, ret;
-
+   struct dw_eth_pdata *dw_pdata = dev_get_platdata(dev);
 #ifdef CONFIG_PHY_ADDR
mask = 1 << CONFIG_PHY_ADDR;
 #endif
@@ -496,6 +496,11 @@ static int dw_phy_init(struct dw_eth_dev *priv, void *dev)
}
phydev->advertising = phydev->supported;
 
+#ifdef CONFIG_DM_ETH
+   if (dw_pdata->phy_of_handle)
+   phydev->node  = offset_to_ofnode(dw_pdata->phy_of_handle);
+#endif
+
priv->phydev = phydev;
phy_config(phydev);
 
@@ -803,6 +808,7 @@ int designware_eth_ofdata_to_platdata(struct udevice *dev)
int reset_flags = GPIOD_IS_OUT;
 #endif
int ret = 0;
+   int node = dev_of_offset(dev);
 
pdata->iobase = dev_read_addr(dev);
pdata->phy_interface = -1;
@@ -814,6 +820,9 @@ int designware_eth_ofdata_to_platdata(struct udevice *dev)
return -EINVAL;
}
 
+   dw_pdata->phy_of_handle = fdtdec_lookup_phandle(gd->fdt_blob, node,
+"phy-handle");
+
pdata->max_speed = dev_read_u32_default(dev, "max-speed", 0);
 
 #ifdef CONFIG_DM_GPIO
diff --git a/drivers/net/designware.h b/drivers/net/designware.h
index dea12b7..a6b0443 100644
--- a/drivers/net/designware.h
+++ b/drivers/net/designware.h
@@ -255,6 +255,7 @@ extern const struct eth_ops designware_eth_ops;
 struct dw_eth_pdata {
struct eth_pdata eth_pdata;
u32 reset_delays[3];
+   int phy_of_handle;
 };
 
 int designware_eth_init(struct dw_eth_dev *priv, u8 *enetaddr);
-- 
2.7.4

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

[U-Boot] [PATCH v4 2/7] config: phycore-rk3288_defconfig: add PHY_TI

[Janine Hagemann]

add PHY_TI to support dp83867

Signed-off-by: Janine Hagemann 
---
v4: No changes
---
 configs/phycore-rk3288_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/phycore-rk3288_defconfig b/configs/phycore-rk3288_defconfig
index b81b5e6..340ba5d 100644
--- a/configs/phycore-rk3288_defconfig
+++ b/configs/phycore-rk3288_defconfig
@@ -54,6 +54,7 @@ CONFIG_MISC=y
 CONFIG_I2C_EEPROM=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_PHY_TI=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-- 
2.7.4

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

[U-Boot] [PATCH v4 5/7] rockchip: rk3288-phycore: set flash1 iodomain to 1.8V

[Janine Hagemann]

This pin is supplied by 1.8V, but the default iodomain
setting is 3.3V.

Signed-off-by: Janine Hagemann 
---
v4: No changes
---
 board/phytec/phycore_rk3288/phycore-rk3288.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/board/phytec/phycore_rk3288/phycore-rk3288.c 
b/board/phytec/phycore_rk3288/phycore-rk3288.c
index ffe1833..8c1844a 100644
--- a/board/phytec/phycore_rk3288/phycore-rk3288.c
+++ b/board/phytec/phycore_rk3288/phycore-rk3288.c
@@ -11,6 +11,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include "som.h"
 
 static int valid_rk3288_som(struct rk3288_som *som)
@@ -27,6 +32,15 @@ static int valid_rk3288_som(struct rk3288_som *som)
return hw == som->bs;
 }
 
+static void setup_iodomain(void)
+{
+   const u32 GRF_IO_VSEL_FLASH1_SHIFT = 3;
+   struct rk3288_grf *grf =
+   syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+
+   rk_setreg(>io_vsel, 1 << GRF_IO_VSEL_FLASH1_SHIFT);
+}
+
 int rk_board_late_init(void)
 {
int ret;
@@ -34,6 +48,8 @@ int rk_board_late_init(void)
struct rk3288_som opt;
int off;
 
+   setup_iodomain();
+
/* Get the identificatioin page of M24C32-D EEPROM */
off = fdt_path_offset(gd->fdt_blob, "eeprom0");
if (off < 0) {
-- 
2.7.4

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

[U-Boot] [PATCH v4 0/7] Add ethernet support for phyCORE-RK3288

[Janine Hagemann]

- Change a used function

Janine Hagemann (7):
  arch: arm: mach-rockchip: rk3288: Enable regulators in board_init
  config: phycore-rk3288_defconfig: add PHY_TI
  drivers: net: designware: Add reading of DT phy-handle node
  ARM: dts: rockchip: ADD dp83867 CLK_OUT muxing
  rockchip: rk3288-phycore: set flash1 iodomain to 1.8V
  net: gmac_rockchip: Fix a register write in rk3328_gmac_set_to_rgmii
  net: gmac_rockchip: Add handeling for RGMII_ID/RXID/TXID

 arch/arm/dts/rk3288-phycore-som.dtsi |  1 +
 arch/arm/mach-rockchip/rk3288-board.c| 12 ++---
 board/phytec/phycore_rk3288/phycore-rk3288.c | 16 ++
 configs/phycore-rk3288_defconfig |  1 +
 drivers/net/designware.c | 11 +++-
 drivers/net/designware.h |  1 +
 drivers/net/gmac_rockchip.c  | 80 ++--
 7 files changed, 98 insertions(+), 24 deletions(-)

-- 
2.7.4

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

[U-Boot] [PATCH v4 1/7] arch: arm: mach-rockchip: rk3288: Enable regulators in board_init

[Janine Hagemann]

Use regulators_enable_boot_on() to init all the regulators with
regulator-boot-on property. This is relevant for all rk3288-boards.

Signed-off-by: Wadim Egorov 
Signed-off-by: Janine Hagemann 
---
v4: No changes
---
 arch/arm/mach-rockchip/rk3288-board.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-rockchip/rk3288-board.c 
b/arch/arm/mach-rockchip/rk3288-board.c
index 9c4f7f2..067b988 100644
--- a/arch/arm/mach-rockchip/rk3288-board.c
+++ b/arch/arm/mach-rockchip/rk3288-board.c
@@ -132,12 +132,6 @@ static int veyron_init(void)
if (ret)
return ret;
 
-   ret = regulators_enable_boot_on(false);
-   if (ret) {
-   debug("%s: Cannot enable boot on regulators\n", __func__);
-   return ret;
-   }
-
return 0;
 }
 #endif
@@ -175,6 +169,12 @@ err:
 #else
int ret;
 
+   ret = regulators_enable_boot_on(false);
+   if (ret) {
+   debug("%s: Cannot enable boot on regulator\n", __func__);
+   return ret;
+   }
+
/* We do some SoC one time setting here */
if (!fdt_node_check_compatible(gd->fdt_blob, 0, "google,veyron")) {
ret = veyron_init();
-- 
2.7.4

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

Re: [U-Boot] [PATCH 00/10] AVB using OP-TEE

[Jens Wiklander]

On Thu, Aug 23, 2018 at 6:31 PM, Simon Glass  wrote:
> Hi Jens,
>
> On 23 August 2018 at 05:23, Jens Wiklander  wrote:
>> Hi Simon,
>>
>> On Thu, Aug 23, 2018 at 12:45 PM, Simon Glass  wrote:
>>> Hi Jens,
>>>
>>> On 13 August 2018 at 09:53, Jens Wiklander  
>>> wrote:
 Hi,

 This adds support for storing AVB rollback indexes in the RPMB partition.
 The RPMB partition (content and key) is managed by OP-TEE
 (https://www.op-tee.org/) which is a secure OS leveraging ARM TrustZone.

 The Linux kernel can already support OP-TEE with reading and updating
 rollback indexes in the RPMB partition, the catch is that this is needed
 before the kernel has booted.

 The design here is the same as what is in the Linux kernel, with the
 exception that the user space daemon tee-supplicant is integrated in the
 OP-TEE driver here (drivers/tee/optee/supplicant.c) instead. A new uclass
 (UCLASS_TEE) is introduced to provide an abstraction for interfacing with a
 Trusted Execution Environment (TEE). There's also the OP-TEE driver using
 UCLASS_TEE for registration.

 A Trusted Application (TA) interface is added to be used by the AVB verify
 functions which are updated accordingly. The TA is managed by OP-TEE and is
 executed in a secure TrustZone protected environment.

 The header files drivers/tee/optee/optee_{msg,msg_supplicant,smc}.h and
 include/tee/optee_ta_avb.h are copied from
 https://github.com/OP-TEE/optee_os/tree/master more or less unmodified.
 They may need to be updated from time to time in order to support new
 features.

 In MMC there's a new function, mmc_rpmb_route_frames(), which as the name
 suggests is used to route RPMB frames to/from the MMC. This saves OP-TEE
 from implementing an MMC driver which would need to share resources with
 its counterpart here in U-boot.

 This was tested on a Hikey (Kirin 620) board.

 I've added myself as maintainer of the TEE stuff.

 Thanks,
 Jens

 Jens Wiklander (10):
   dm: fdt: scan for devices under /firmware too
   cmd: avb read_rb: print rb_idx in hexadecimal
   mmc: rpmb: add mmc_rpmb_route_frames()
   Add UCLASS_TEE for Trusted Execution Environment
   dt/bindings: add bindings for optee
   tee: add OP-TEE driver
   arm: dt: hikey: Add optee node
   optee: support routing of rpmb data frames to mmc
   tee: optee: support AVB trusted application
   avb_verify: support using OP-TEE TA AVB

  MAINTAINERS   |   7 +
  arch/arm/dts/hi6220-hikey.dts |   7 +
  cmd/avb.c |   2 +-
  common/avb_verify.c   | 132 +++-
  .../firmware/linaro,optee-tz.txt  |  31 +
  drivers/Kconfig   |   2 +
  drivers/Makefile  |   1 +
  drivers/core/root.c   |  15 +-
  drivers/mmc/rpmb.c| 160 +
  drivers/tee/Kconfig   |  18 +
  drivers/tee/Makefile  |   4 +
  drivers/tee/optee/Kconfig |  23 +
  drivers/tee/optee/Makefile|   5 +
  drivers/tee/optee/core.c  | 622 ++
  drivers/tee/optee/optee_msg.h | 423 
  drivers/tee/optee/optee_msg_supplicant.h  | 234 +++
  drivers/tee/optee/optee_private.h |  41 ++
  drivers/tee/optee/optee_smc.h | 444 +
  drivers/tee/optee/rpmb.c  | 184 ++
  drivers/tee/optee/supplicant.c|  92 +++
  drivers/tee/tee-uclass.c  | 180 +
  include/avb_verify.h  |   4 +
  include/dm/uclass-id.h|   1 +
  include/mmc.h |   2 +
  include/tee.h | 141 
  include/tee/optee_ta_avb.h|  48 ++
  26 files changed, 2816 insertions(+), 7 deletions(-)
  create mode 100644 doc/device-tree-bindings/firmware/linaro,optee-tz.txt
  create mode 100644 drivers/tee/Kconfig
  create mode 100644 drivers/tee/Makefile
  create mode 100644 drivers/tee/optee/Kconfig
  create mode 100644 drivers/tee/optee/Makefile
  create mode 100644 drivers/tee/optee/core.c
  create mode 100644 drivers/tee/optee/optee_msg.h
  create mode 100644 drivers/tee/optee/optee_msg_supplicant.h
  create mode 100644 drivers/tee/optee/optee_private.h
  create mode 100644 drivers/tee/optee/optee_smc.h
  create mode 100644 drivers/tee/optee/rpmb.c
  create mode 100644 drivers/tee/optee/supplicant.c
  create mode 100644 drivers/tee/tee-uclass.c
  create