All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3 00/13] rockchip: Add new rk3399 boards
@ 2019-04-25 17:34 ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

This is v3 patchset for New rk3399 boards support wrt previous
version[1]

Overall this series add support below rk3399 boards
- Orangepi RK3399
- NanoPI M4
- NanoPI NEO4
- Orangepi RK3399
- Rock PI 4
- Rockpro64

All the respective dts(i) files are synced from Linux 5.1-rc2 and few
dts(i) from linux-next.

Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support
booting via Rockchip miniloader as of now.

For booting the same with SPL NEO4 would require dynamic dram timing
detection and rest require LPDDR4 code. There is WIP[2] for these
dependencies and this would require big chunk of changes will effect
all the rk3399 boards, so I'm planning to mark it for next MW. 
 
Changes for v3:
- drop NanoPC T4 for now, since board is yet to receive.
- add Rock PI-4 board.
- add separate -u-boot.dtsi file for nanopi4 sdram changes.
- collect Paul, Philipp and Kever Reviewed-by tags

[1] https://patchwork.ozlabs.org/cover/1086213/
[2] https://github.com/amarula/u-boot-amarula/tree/rockdev-lpddr4

Jagan Teki (13):
  rockchip: dts: rk3399: Sync rk3399-opp from Linux
  rockchip: dts: rk3399: Sync pwm2_pin_pull_down from Linux 5.1-rc2
  rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi
  Kconfig: Add default SPL_FIT_GENERATOR for rockchip
  arm: rockchip: rk3399: Move common configs in Kconfig
  rockchip: rk3399: Add Orangepi RK3399 support
  rockchip: dts: rk3399: Sync rk3399-nanopi4.dtsi from Linux
  rockchip: dts: rk3399: nanopi4: Use CD pin as RK_FUNC_1
  rockchip: rk3399: Add Nanopi M4 board support
  rockchip: rk3399: Add Nanopi NEO4 board support
  rockchip: rk3399: Add Rockpro64 board support
  rockchip: rk3399: Add Rock PI 4 support
  doc: rockchip: Add global doc for rk3399 build/flash

 Kconfig                                     |   1 +
 arch/arm/dts/Makefile                       |   5 +
 arch/arm/dts/rk3399-evb.dts                 |   1 -
 arch/arm/dts/rk3399-firefly.dts             |   1 -
 arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi   |   7 +
 arch/arm/dts/rk3399-nanopi-m4.dts           |  66 ++
 arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi |   6 +
 arch/arm/dts/rk3399-nanopi-neo4.dts         |  50 ++
 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi     |  11 +
 arch/arm/dts/rk3399-nanopi4.dtsi            | 703 ++++++++++++++++++
 arch/arm/dts/rk3399-opp.dtsi                | 133 ++++
 arch/arm/dts/rk3399-orangepi-u-boot.dtsi    |   7 +
 arch/arm/dts/rk3399-orangepi.dts            | 771 ++++++++++++++++++++
 arch/arm/dts/rk3399-puma.dtsi               |   1 -
 arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi   |   6 +
 arch/arm/dts/rk3399-rock-pi-4.dts           | 606 +++++++++++++++
 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi   |   6 +
 arch/arm/dts/rk3399-rockpro64.dts           | 712 ++++++++++++++++++
 arch/arm/dts/rk3399-u-boot.dtsi             |   8 +
 arch/arm/dts/rk3399.dtsi                    |   6 +
 arch/arm/mach-rockchip/Kconfig              |  16 +
 board/rockchip/evb_rk3399/MAINTAINERS       |  33 +
 configs/chromebook_bob_defconfig            |  17 -
 configs/evb-rk3399_defconfig                |  17 -
 configs/ficus-rk3399_defconfig              |  17 -
 configs/firefly-rk3399_defconfig            |  17 -
 configs/nanopi-m4-rk3399_defconfig          |  58 ++
 configs/nanopi-neo4-rk3399_defconfig        |  58 ++
 configs/orangepi-rk3399_defconfig           |  58 ++
 configs/puma-rk3399_defconfig               |  16 -
 configs/rock-pi-4-rk3399_defconfig          |  58 ++
 configs/rock960-rk3399_defconfig            |  17 -
 configs/rockpro64-rk3399_defconfig          |  58 ++
 doc/README.rockchip                         | 209 +++++-
 34 files changed, 3651 insertions(+), 105 deletions(-)
 create mode 100644 arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-nanopi-m4.dts
 create mode 100644 arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-nanopi-neo4.dts
 create mode 100644 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-nanopi4.dtsi
 create mode 100644 arch/arm/dts/rk3399-opp.dtsi
 create mode 100644 arch/arm/dts/rk3399-orangepi-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-orangepi.dts
 create mode 100644 arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-rock-pi-4.dts
 create mode 100644 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-rockpro64.dts
 create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi
 create mode 100644 configs/nanopi-m4-rk3399_defconfig
 create mode 100644 configs/nanopi-neo4-rk3399_defconfig
 create mode 100644 configs/orangepi-rk3399_defconfig
 create mode 100644 configs/rock-pi-4-rk3399_defconfig
 create mode 100644 configs/rockpro64-rk3399_defconfig

-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 00/13] rockchip: Add new rk3399 boards
@ 2019-04-25 17:34 ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

This is v3 patchset for New rk3399 boards support wrt previous
version[1]

Overall this series add support below rk3399 boards
- Orangepi RK3399
- NanoPI M4
- NanoPI NEO4
- Orangepi RK3399
- Rock PI 4
- Rockpro64

All the respective dts(i) files are synced from Linux 5.1-rc2 and few
dts(i) from linux-next.

Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support
booting via Rockchip miniloader as of now.

For booting the same with SPL NEO4 would require dynamic dram timing
detection and rest require LPDDR4 code. There is WIP[2] for these
dependencies and this would require big chunk of changes will effect
all the rk3399 boards, so I'm planning to mark it for next MW. 
 
Changes for v3:
- drop NanoPC T4 for now, since board is yet to receive.
- add Rock PI-4 board.
- add separate -u-boot.dtsi file for nanopi4 sdram changes.
- collect Paul, Philipp and Kever Reviewed-by tags

[1] https://patchwork.ozlabs.org/cover/1086213/
[2] https://github.com/amarula/u-boot-amarula/tree/rockdev-lpddr4

Jagan Teki (13):
  rockchip: dts: rk3399: Sync rk3399-opp from Linux
  rockchip: dts: rk3399: Sync pwm2_pin_pull_down from Linux 5.1-rc2
  rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi
  Kconfig: Add default SPL_FIT_GENERATOR for rockchip
  arm: rockchip: rk3399: Move common configs in Kconfig
  rockchip: rk3399: Add Orangepi RK3399 support
  rockchip: dts: rk3399: Sync rk3399-nanopi4.dtsi from Linux
  rockchip: dts: rk3399: nanopi4: Use CD pin as RK_FUNC_1
  rockchip: rk3399: Add Nanopi M4 board support
  rockchip: rk3399: Add Nanopi NEO4 board support
  rockchip: rk3399: Add Rockpro64 board support
  rockchip: rk3399: Add Rock PI 4 support
  doc: rockchip: Add global doc for rk3399 build/flash

 Kconfig                                     |   1 +
 arch/arm/dts/Makefile                       |   5 +
 arch/arm/dts/rk3399-evb.dts                 |   1 -
 arch/arm/dts/rk3399-firefly.dts             |   1 -
 arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi   |   7 +
 arch/arm/dts/rk3399-nanopi-m4.dts           |  66 ++
 arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi |   6 +
 arch/arm/dts/rk3399-nanopi-neo4.dts         |  50 ++
 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi     |  11 +
 arch/arm/dts/rk3399-nanopi4.dtsi            | 703 ++++++++++++++++++
 arch/arm/dts/rk3399-opp.dtsi                | 133 ++++
 arch/arm/dts/rk3399-orangepi-u-boot.dtsi    |   7 +
 arch/arm/dts/rk3399-orangepi.dts            | 771 ++++++++++++++++++++
 arch/arm/dts/rk3399-puma.dtsi               |   1 -
 arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi   |   6 +
 arch/arm/dts/rk3399-rock-pi-4.dts           | 606 +++++++++++++++
 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi   |   6 +
 arch/arm/dts/rk3399-rockpro64.dts           | 712 ++++++++++++++++++
 arch/arm/dts/rk3399-u-boot.dtsi             |   8 +
 arch/arm/dts/rk3399.dtsi                    |   6 +
 arch/arm/mach-rockchip/Kconfig              |  16 +
 board/rockchip/evb_rk3399/MAINTAINERS       |  33 +
 configs/chromebook_bob_defconfig            |  17 -
 configs/evb-rk3399_defconfig                |  17 -
 configs/ficus-rk3399_defconfig              |  17 -
 configs/firefly-rk3399_defconfig            |  17 -
 configs/nanopi-m4-rk3399_defconfig          |  58 ++
 configs/nanopi-neo4-rk3399_defconfig        |  58 ++
 configs/orangepi-rk3399_defconfig           |  58 ++
 configs/puma-rk3399_defconfig               |  16 -
 configs/rock-pi-4-rk3399_defconfig          |  58 ++
 configs/rock960-rk3399_defconfig            |  17 -
 configs/rockpro64-rk3399_defconfig          |  58 ++
 doc/README.rockchip                         | 209 +++++-
 34 files changed, 3651 insertions(+), 105 deletions(-)
 create mode 100644 arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-nanopi-m4.dts
 create mode 100644 arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-nanopi-neo4.dts
 create mode 100644 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-nanopi4.dtsi
 create mode 100644 arch/arm/dts/rk3399-opp.dtsi
 create mode 100644 arch/arm/dts/rk3399-orangepi-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-orangepi.dts
 create mode 100644 arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-rock-pi-4.dts
 create mode 100644 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-rockpro64.dts
 create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi
 create mode 100644 configs/nanopi-m4-rk3399_defconfig
 create mode 100644 configs/nanopi-neo4-rk3399_defconfig
 create mode 100644 configs/orangepi-rk3399_defconfig
 create mode 100644 configs/rock-pi-4-rk3399_defconfig
 create mode 100644 configs/rockpro64-rk3399_defconfig

-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [PATCH v3 01/13] rockchip: dts: rk3399: Sync rk3399-opp from Linux
  2019-04-25 17:34 ` [U-Boot] " Jagan Teki
@ 2019-04-25 17:34     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

Sync rk3399-opp.dtsi from Linux.

Linux commit details about the rk3399-opp.dtsi sync:
"arm64: dts: rockchip: use SPDX-License-Identifier"
(sha1: 4ee99cebd486238ac433da823b95cc5f8d8a6905)

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
---
 arch/arm/dts/rk3399-opp.dtsi | 133 +++++++++++++++++++++++++++++++++++
 1 file changed, 133 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-opp.dtsi

diff --git a/arch/arm/dts/rk3399-opp.dtsi b/arch/arm/dts/rk3399-opp.dtsi
new file mode 100644
index 0000000000..d6f1095abb
--- /dev/null
+++ b/arch/arm/dts/rk3399-opp.dtsi
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2016-2017 Fuzhou Rockchip Electronics Co., Ltd
+ */
+
+/ {
+	cluster0_opp: opp-table0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp00 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <800000>;
+			clock-latency-ns = <40000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <800000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <850000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <1008000000>;
+			opp-microvolt = <925000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <1000000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <1125000>;
+		};
+	};
+
+	cluster1_opp: opp-table1 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp00 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <800000>;
+			clock-latency-ns = <40000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <800000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <825000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <1008000000>;
+			opp-microvolt = <875000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <950000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <1025000>;
+		};
+		opp06 {
+			opp-hz = /bits/ 64 <1608000000>;
+			opp-microvolt = <1100000>;
+		};
+		opp07 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <1200000>;
+		};
+	};
+
+	gpu_opp_table: opp-table2 {
+		compatible = "operating-points-v2";
+
+		opp00 {
+			opp-hz = /bits/ 64 <200000000>;
+			opp-microvolt = <800000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <297000000>;
+			opp-microvolt = <800000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <400000000>;
+			opp-microvolt = <825000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <500000000>;
+			opp-microvolt = <875000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <925000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <800000000>;
+			opp-microvolt = <1100000>;
+		};
+	};
+};
+
+&cpu_l0 {
+	operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_l1 {
+	operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_l2 {
+	operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_l3 {
+	operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_b0 {
+	operating-points-v2 = <&cluster1_opp>;
+};
+
+&cpu_b1 {
+	operating-points-v2 = <&cluster1_opp>;
+};
+
+&gpu {
+	operating-points-v2 = <&gpu_opp_table>;
+};
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 01/13] rockchip: dts: rk3399: Sync rk3399-opp from Linux
@ 2019-04-25 17:34     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

Sync rk3399-opp.dtsi from Linux.

Linux commit details about the rk3399-opp.dtsi sync:
"arm64: dts: rockchip: use SPDX-License-Identifier"
(sha1: 4ee99cebd486238ac433da823b95cc5f8d8a6905)

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm/dts/rk3399-opp.dtsi | 133 +++++++++++++++++++++++++++++++++++
 1 file changed, 133 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-opp.dtsi

diff --git a/arch/arm/dts/rk3399-opp.dtsi b/arch/arm/dts/rk3399-opp.dtsi
new file mode 100644
index 0000000000..d6f1095abb
--- /dev/null
+++ b/arch/arm/dts/rk3399-opp.dtsi
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2016-2017 Fuzhou Rockchip Electronics Co., Ltd
+ */
+
+/ {
+	cluster0_opp: opp-table0 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp00 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <800000>;
+			clock-latency-ns = <40000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <800000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <850000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <1008000000>;
+			opp-microvolt = <925000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <1000000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <1125000>;
+		};
+	};
+
+	cluster1_opp: opp-table1 {
+		compatible = "operating-points-v2";
+		opp-shared;
+
+		opp00 {
+			opp-hz = /bits/ 64 <408000000>;
+			opp-microvolt = <800000>;
+			clock-latency-ns = <40000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <800000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <816000000>;
+			opp-microvolt = <825000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <1008000000>;
+			opp-microvolt = <875000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <1200000000>;
+			opp-microvolt = <950000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <1416000000>;
+			opp-microvolt = <1025000>;
+		};
+		opp06 {
+			opp-hz = /bits/ 64 <1608000000>;
+			opp-microvolt = <1100000>;
+		};
+		opp07 {
+			opp-hz = /bits/ 64 <1800000000>;
+			opp-microvolt = <1200000>;
+		};
+	};
+
+	gpu_opp_table: opp-table2 {
+		compatible = "operating-points-v2";
+
+		opp00 {
+			opp-hz = /bits/ 64 <200000000>;
+			opp-microvolt = <800000>;
+		};
+		opp01 {
+			opp-hz = /bits/ 64 <297000000>;
+			opp-microvolt = <800000>;
+		};
+		opp02 {
+			opp-hz = /bits/ 64 <400000000>;
+			opp-microvolt = <825000>;
+		};
+		opp03 {
+			opp-hz = /bits/ 64 <500000000>;
+			opp-microvolt = <875000>;
+		};
+		opp04 {
+			opp-hz = /bits/ 64 <600000000>;
+			opp-microvolt = <925000>;
+		};
+		opp05 {
+			opp-hz = /bits/ 64 <800000000>;
+			opp-microvolt = <1100000>;
+		};
+	};
+};
+
+&cpu_l0 {
+	operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_l1 {
+	operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_l2 {
+	operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_l3 {
+	operating-points-v2 = <&cluster0_opp>;
+};
+
+&cpu_b0 {
+	operating-points-v2 = <&cluster1_opp>;
+};
+
+&cpu_b1 {
+	operating-points-v2 = <&cluster1_opp>;
+};
+
+&gpu {
+	operating-points-v2 = <&gpu_opp_table>;
+};
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [PATCH v3 02/13] rockchip: dts: rk3399: Sync pwm2_pin_pull_down from Linux 5.1-rc2
  2019-04-25 17:34 ` [U-Boot] " Jagan Teki
@ 2019-04-25 17:34     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

To make successful build with dts(i) files syncing from Linux 5.1-rc2
the rk3399.dtsi would require pwm2_pin_pull_down.

So, sync the pwm2_pin_pull_down node from Linux 5.1-rc2.  Since this
node is strictly not part of any commit alone, I have mentioned
Linux 5.1-rc2 tag for future reference of where would this sync
coming from.

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
---
 arch/arm/dts/rk3399.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index b53e41b4dc..99471f6287 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -2495,6 +2495,12 @@
 				rockchip,pins =
 					<1 RK_PC3 RK_FUNC_1 &pcfg_pull_none>;
 			};
+
+
+			pwm2_pin_pull_down: pwm2-pin-pull-down {
+				rockchip,pins =
+					<1 RK_PC3 RK_FUNC_1 &pcfg_pull_down>;
+			};
 		};
 
 		pwm3a {
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 02/13] rockchip: dts: rk3399: Sync pwm2_pin_pull_down from Linux 5.1-rc2
@ 2019-04-25 17:34     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

To make successful build with dts(i) files syncing from Linux 5.1-rc2
the rk3399.dtsi would require pwm2_pin_pull_down.

So, sync the pwm2_pin_pull_down node from Linux 5.1-rc2.  Since this
node is strictly not part of any commit alone, I have mentioned
Linux 5.1-rc2 tag for future reference of where would this sync
coming from.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm/dts/rk3399.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
index b53e41b4dc..99471f6287 100644
--- a/arch/arm/dts/rk3399.dtsi
+++ b/arch/arm/dts/rk3399.dtsi
@@ -2495,6 +2495,12 @@
 				rockchip,pins =
 					<1 RK_PC3 RK_FUNC_1 &pcfg_pull_none>;
 			};
+
+
+			pwm2_pin_pull_down: pwm2-pin-pull-down {
+				rockchip,pins =
+					<1 RK_PC3 RK_FUNC_1 &pcfg_pull_down>;
+			};
 		};
 
 		pwm3a {
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [PATCH v3 03/13] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi
  2019-04-25 17:34 ` [U-Boot] " Jagan Teki
@ 2019-04-25 17:34     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
which is U-Boot specific devicetrees binding.

Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
bindings will move it future based on the requirement.

This would help to sync the devicetrees from Linux whenever required
instead of adding specific nodes.

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
---
 arch/arm/dts/rk3399-evb.dts     | 1 -
 arch/arm/dts/rk3399-firefly.dts | 1 -
 arch/arm/dts/rk3399-puma.dtsi   | 1 -
 arch/arm/dts/rk3399-u-boot.dtsi | 8 ++++++++
 4 files changed, 8 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index ce004d0d18..9162f3dd50 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -155,7 +155,6 @@
 };
 
 &sdmmc {
-	u-boot,dm-pre-reloc;
 	bus-width = <4>;
 	status = "okay";
 };
diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts
index f90e7e88db..46f2ffaf8d 100644
--- a/arch/arm/dts/rk3399-firefly.dts
+++ b/arch/arm/dts/rk3399-firefly.dts
@@ -592,7 +592,6 @@
 };
 
 &sdmmc {
-	u-boot,dm-pre-reloc;
 	bus-width = <4>;
 	status = "okay";
 };
diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
index 8304f67192..9049694243 100644
--- a/arch/arm/dts/rk3399-puma.dtsi
+++ b/arch/arm/dts/rk3399-puma.dtsi
@@ -492,7 +492,6 @@
 };
 
 &sdmmc {
-	u-boot,dm-pre-reloc;
 	clock-frequency = <150000000>;
 	max-frequency = <40000000>;
 	supports-sd;
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
new file mode 100644
index 0000000000..f533ed95eb
--- /dev/null
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+ */
+
+&sdmmc {
+	u-boot,dm-pre-reloc;
+};
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 03/13] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi
@ 2019-04-25 17:34     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
which is U-Boot specific devicetrees binding.

Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
bindings will move it future based on the requirement.

This would help to sync the devicetrees from Linux whenever required
instead of adding specific nodes.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm/dts/rk3399-evb.dts     | 1 -
 arch/arm/dts/rk3399-firefly.dts | 1 -
 arch/arm/dts/rk3399-puma.dtsi   | 1 -
 arch/arm/dts/rk3399-u-boot.dtsi | 8 ++++++++
 4 files changed, 8 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi

diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
index ce004d0d18..9162f3dd50 100644
--- a/arch/arm/dts/rk3399-evb.dts
+++ b/arch/arm/dts/rk3399-evb.dts
@@ -155,7 +155,6 @@
 };
 
 &sdmmc {
-	u-boot,dm-pre-reloc;
 	bus-width = <4>;
 	status = "okay";
 };
diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts
index f90e7e88db..46f2ffaf8d 100644
--- a/arch/arm/dts/rk3399-firefly.dts
+++ b/arch/arm/dts/rk3399-firefly.dts
@@ -592,7 +592,6 @@
 };
 
 &sdmmc {
-	u-boot,dm-pre-reloc;
 	bus-width = <4>;
 	status = "okay";
 };
diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
index 8304f67192..9049694243 100644
--- a/arch/arm/dts/rk3399-puma.dtsi
+++ b/arch/arm/dts/rk3399-puma.dtsi
@@ -492,7 +492,6 @@
 };
 
 &sdmmc {
-	u-boot,dm-pre-reloc;
 	clock-frequency = <150000000>;
 	max-frequency = <40000000>;
 	supports-sd;
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
new file mode 100644
index 0000000000..f533ed95eb
--- /dev/null
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+&sdmmc {
+	u-boot,dm-pre-reloc;
+};
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [PATCH v3 04/13] Kconfig: Add default SPL_FIT_GENERATOR for rockchip
  2019-04-25 17:34 ` [U-Boot] " Jagan Teki
@ 2019-04-25 17:34     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

Add default SPL_FIT_GENERATOR py script for rockchip platforms if
specific target enabled SPL_LOAD_FIT.

So, this would help get rid of explicitly mentioning the default
SPL FIT generator in defconfigs. however some targets, like puma_rk3399
still require their own FIT generator so in those cases the default will
override with defconfig defined generator.

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
---
 Kconfig                          | 1 +
 configs/chromebook_bob_defconfig | 1 -
 configs/evb-rk3399_defconfig     | 1 -
 configs/ficus-rk3399_defconfig   | 1 -
 configs/firefly-rk3399_defconfig | 1 -
 configs/rock960-rk3399_defconfig | 1 -
 6 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/Kconfig b/Kconfig
index 305b265ed7..5679a288ec 100644
--- a/Kconfig
+++ b/Kconfig
@@ -424,6 +424,7 @@ config SPL_FIT_GENERATOR
 	string ".its file generator script for U-Boot FIT image"
 	depends on SPL_FIT
 	default "board/sunxi/mksunxi_fit_atf.sh" if SPL_LOAD_FIT && ARCH_SUNXI
+	default "arch/arm/mach-rockchip/make_fit_atf.py" if SPL_LOAD_FIT && ARCH_ROCKCHIP
 	help
 	  Specifies a (platform specific) script file to generate the FIT
 	  source file used to build the U-Boot FIT image file. This gets
diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index ce3deccb8a..04e25e1d4f 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -19,7 +19,6 @@ CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index d98535357a..49b2e2e089 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -13,7 +13,6 @@ CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
diff --git a/configs/ficus-rk3399_defconfig b/configs/ficus-rk3399_defconfig
index 94c565efc2..fe3b9964e8 100644
--- a/configs/ficus-rk3399_defconfig
+++ b/configs/ficus-rk3399_defconfig
@@ -13,7 +13,6 @@ CONFIG_SPL_STACK_R_ADDR=0x80000
 CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig
index 6725b48970..914304bb43 100644
--- a/configs/firefly-rk3399_defconfig
+++ b/configs/firefly-rk3399_defconfig
@@ -13,7 +13,6 @@ CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-firefly.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
diff --git a/configs/rock960-rk3399_defconfig b/configs/rock960-rk3399_defconfig
index cb5a35f4f5..5e6778ea20 100644
--- a/configs/rock960-rk3399_defconfig
+++ b/configs/rock960-rk3399_defconfig
@@ -13,7 +13,6 @@ CONFIG_SPL_STACK_R_ADDR=0x80000
 CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock960.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 04/13] Kconfig: Add default SPL_FIT_GENERATOR for rockchip
@ 2019-04-25 17:34     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

Add default SPL_FIT_GENERATOR py script for rockchip platforms if
specific target enabled SPL_LOAD_FIT.

So, this would help get rid of explicitly mentioning the default
SPL FIT generator in defconfigs. however some targets, like puma_rk3399
still require their own FIT generator so in those cases the default will
override with defconfig defined generator.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 Kconfig                          | 1 +
 configs/chromebook_bob_defconfig | 1 -
 configs/evb-rk3399_defconfig     | 1 -
 configs/ficus-rk3399_defconfig   | 1 -
 configs/firefly-rk3399_defconfig | 1 -
 configs/rock960-rk3399_defconfig | 1 -
 6 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/Kconfig b/Kconfig
index 305b265ed7..5679a288ec 100644
--- a/Kconfig
+++ b/Kconfig
@@ -424,6 +424,7 @@ config SPL_FIT_GENERATOR
 	string ".its file generator script for U-Boot FIT image"
 	depends on SPL_FIT
 	default "board/sunxi/mksunxi_fit_atf.sh" if SPL_LOAD_FIT && ARCH_SUNXI
+	default "arch/arm/mach-rockchip/make_fit_atf.py" if SPL_LOAD_FIT && ARCH_ROCKCHIP
 	help
 	  Specifies a (platform specific) script file to generate the FIT
 	  source file used to build the U-Boot FIT image file. This gets
diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index ce3deccb8a..04e25e1d4f 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -19,7 +19,6 @@ CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index d98535357a..49b2e2e089 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -13,7 +13,6 @@ CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
diff --git a/configs/ficus-rk3399_defconfig b/configs/ficus-rk3399_defconfig
index 94c565efc2..fe3b9964e8 100644
--- a/configs/ficus-rk3399_defconfig
+++ b/configs/ficus-rk3399_defconfig
@@ -13,7 +13,6 @@ CONFIG_SPL_STACK_R_ADDR=0x80000
 CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig
index 6725b48970..914304bb43 100644
--- a/configs/firefly-rk3399_defconfig
+++ b/configs/firefly-rk3399_defconfig
@@ -13,7 +13,6 @@ CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-firefly.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
diff --git a/configs/rock960-rk3399_defconfig b/configs/rock960-rk3399_defconfig
index cb5a35f4f5..5e6778ea20 100644
--- a/configs/rock960-rk3399_defconfig
+++ b/configs/rock960-rk3399_defconfig
@@ -13,7 +13,6 @@ CONFIG_SPL_STACK_R_ADDR=0x80000
 CONFIG_DEBUG_UART=y
 CONFIG_FIT=y
 CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock960.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [PATCH v3 05/13] arm: rockchip: rk3399: Move common configs in Kconfig
  2019-04-25 17:34 ` [U-Boot] " Jagan Teki
@ 2019-04-25 17:34     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

Few SPL and U-Boot proper configs are common to all rk3399 target
defconfigs, move them and select it from platform kconfig.

Moved configs:
-  SPL_ATF
-  SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
-  SPL_LOAD_FIT
-  SPL_CLK if SPL
-  SPL_PINCTRL if SPL
-  SPL_RAM if SPL
-  SPL_REGMAP if SPL
-  SPL_SYSCON if SPL
-  CLK
-  FIT
-  PINCTRL
-  RAM
-  REGMAP
-  SYSCON
-  DM_PMIC
-  DM_REGULATOR_FIXED

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
---
 arch/arm/mach-rockchip/Kconfig   | 16 ++++++++++++++++
 configs/chromebook_bob_defconfig | 16 ----------------
 configs/evb-rk3399_defconfig     | 16 ----------------
 configs/ficus-rk3399_defconfig   | 16 ----------------
 configs/firefly-rk3399_defconfig | 16 ----------------
 configs/puma-rk3399_defconfig    | 16 ----------------
 configs/rock960-rk3399_defconfig | 16 ----------------
 7 files changed, 16 insertions(+), 96 deletions(-)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index b9a026abb5..dbe7f11d39 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -132,9 +132,25 @@ config ROCKCHIP_RK3399
 	select ARM64
 	select SUPPORT_SPL
 	select SPL
+	select SPL_ATF
+	select SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
+	select SPL_LOAD_FIT
+	select SPL_CLK if SPL
+	select SPL_PINCTRL if SPL
+	select SPL_RAM if SPL
+	select SPL_REGMAP if SPL
+	select SPL_SYSCON if SPL
 	select SPL_SEPARATE_BSS
 	select SPL_SERIAL_SUPPORT
 	select SPL_DRIVERS_MISC_SUPPORT
+	select CLK
+	select FIT
+	select PINCTRL
+	select RAM
+	select REGMAP
+	select SYSCON
+	select DM_PMIC
+	select DM_REGULATOR_FIXED
 	select DEBUG_UART_BOARD_INIT
 	select BOARD_LATE_INIT
 	select ROCKCHIP_BROM_HELPER
diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index 04e25e1d4f..fdcbabf912 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -17,16 +17,12 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
 CONFIG_SPL_SPI_LOAD=y
-CONFIG_SPL_ATF=y
-CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
@@ -45,12 +41,6 @@ CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-gru-bob"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_MMC=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_SPL_SYSCON=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_I2C_CROS_EC_TUNNEL=y
 CONFIG_SYS_I2C_ROCKCHIP=y
@@ -70,16 +60,10 @@ CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PINCTRL=y
-CONFIG_SPL_PINCTRL=y
-CONFIG_DM_PMIC=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_REGULATOR_PWM=y
-CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
-CONFIG_RAM=y
-CONFIG_SPL_RAM=y
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_ROCKCHIP_SPI=y
 CONFIG_SYSRESET=y
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 49b2e2e089..1ba9dcba62 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -11,15 +11,11 @@ CONFIG_DEBUG_UART_CLOCK=24000000
 CONFIG_SPL_STACK_R_ADDR=0x80000
 CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
-CONFIG_SPL_ATF=y
-CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_MMC=y
@@ -32,12 +28,6 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3399-evb"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_NET_RANDOM_ETHADDR=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_SPL_SYSCON=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MMC_DW=y
@@ -47,16 +37,10 @@ CONFIG_SF_DEFAULT_SPEED=20000000
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PINCTRL=y
-CONFIG_SPL_PINCTRL=y
-CONFIG_DM_PMIC=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_REGULATOR_PWM=y
-CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
-CONFIG_RAM=y
-CONFIG_SPL_RAM=y
 CONFIG_BAUDRATE=1500000
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYSRESET=y
diff --git a/configs/ficus-rk3399_defconfig b/configs/ficus-rk3399_defconfig
index fe3b9964e8..67c62065aa 100644
--- a/configs/ficus-rk3399_defconfig
+++ b/configs/ficus-rk3399_defconfig
@@ -11,14 +11,10 @@ CONFIG_DEBUG_UART_BASE=0xFF1A0000
 CONFIG_DEBUG_UART_CLOCK=24000000
 CONFIG_SPL_STACK_R_ADDR=0x80000
 CONFIG_DEBUG_UART=y
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
-CONFIG_SPL_ATF=y
-CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_MMC=y
@@ -31,12 +27,6 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3399-ficus"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_NET_RANDOM_ETHADDR=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_SPL_SYSCON=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MMC_DW=y
@@ -48,17 +38,11 @@ CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_RGMII=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PINCTRL=y
-CONFIG_SPL_PINCTRL=y
-CONFIG_DM_PMIC=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_REGULATOR_PWM=y
-CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
-CONFIG_RAM=y
-CONFIG_SPL_RAM=y
 CONFIG_BAUDRATE=1500000
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYSRESET=y
diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig
index 914304bb43..1d3a7f2982 100644
--- a/configs/firefly-rk3399_defconfig
+++ b/configs/firefly-rk3399_defconfig
@@ -11,15 +11,11 @@ CONFIG_DEBUG_UART_CLOCK=24000000
 CONFIG_SPL_STACK_R_ADDR=0x80000
 CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-firefly.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
-CONFIG_SPL_ATF=y
-CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_MMC=y
@@ -31,12 +27,6 @@ CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-firefly"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_MMC=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_SPL_SYSCON=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MMC_DW=y
@@ -47,16 +37,10 @@ CONFIG_SF_DEFAULT_SPEED=20000000
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PINCTRL=y
-CONFIG_SPL_PINCTRL=y
-CONFIG_DM_PMIC=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_REGULATOR_PWM=y
-CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
-CONFIG_RAM=y
-CONFIG_SPL_RAM=y
 CONFIG_BAUDRATE=1500000
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYSRESET=y
diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index 3547ec6b27..e5ea2fe0b3 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -15,8 +15,6 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_SOURCE="board/theobroma-systems/puma_rk3399/fit_spl_atf.its"
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-puma-haikou.dtb"
 CONFIG_MISC_INIT_R=y
@@ -31,8 +29,6 @@ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_POWER_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
-CONFIG_SPL_ATF=y
-CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
@@ -51,12 +47,6 @@ CONFIG_OF_LIVE=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-puma-ddr1600"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_MMC=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_SPL_SYSCON=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
@@ -74,20 +64,14 @@ CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PINCTRL=y
-CONFIG_SPL_PINCTRL=y
-CONFIG_DM_PMIC=y
 CONFIG_DM_PMIC_FAN53555=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_SPL_DM_REGULATOR=y
 CONFIG_REGULATOR_PWM=y
-CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_SPL_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
-CONFIG_RAM=y
-CONFIG_SPL_RAM=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_ISL1208=y
 CONFIG_DEBUG_UART_SHIFT=2
diff --git a/configs/rock960-rk3399_defconfig b/configs/rock960-rk3399_defconfig
index 5e6778ea20..cc7d6f89b1 100644
--- a/configs/rock960-rk3399_defconfig
+++ b/configs/rock960-rk3399_defconfig
@@ -11,15 +11,11 @@ CONFIG_DEBUG_UART_BASE=0xFF1A0000
 CONFIG_DEBUG_UART_CLOCK=24000000
 CONFIG_SPL_STACK_R_ADDR=0x80000
 CONFIG_DEBUG_UART=y
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock960.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
-CONFIG_SPL_ATF=y
-CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_SYS_PROMPT="rock960 => "
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
@@ -32,12 +28,6 @@ CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-rock960"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_MMC=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_SPL_SYSCON=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MMC_DW=y
@@ -45,16 +35,10 @@ CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ROCKCHIP=y
 CONFIG_SF_DEFAULT_SPEED=20000000
-CONFIG_PINCTRL=y
-CONFIG_SPL_PINCTRL=y
-CONFIG_DM_PMIC=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_REGULATOR_PWM=y
-CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
-CONFIG_RAM=y
-CONFIG_SPL_RAM=y
 CONFIG_BAUDRATE=1500000
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYSRESET=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 05/13] arm: rockchip: rk3399: Move common configs in Kconfig
@ 2019-04-25 17:34     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

Few SPL and U-Boot proper configs are common to all rk3399 target
defconfigs, move them and select it from platform kconfig.

Moved configs:
-  SPL_ATF
-  SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
-  SPL_LOAD_FIT
-  SPL_CLK if SPL
-  SPL_PINCTRL if SPL
-  SPL_RAM if SPL
-  SPL_REGMAP if SPL
-  SPL_SYSCON if SPL
-  CLK
-  FIT
-  PINCTRL
-  RAM
-  REGMAP
-  SYSCON
-  DM_PMIC
-  DM_REGULATOR_FIXED

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm/mach-rockchip/Kconfig   | 16 ++++++++++++++++
 configs/chromebook_bob_defconfig | 16 ----------------
 configs/evb-rk3399_defconfig     | 16 ----------------
 configs/ficus-rk3399_defconfig   | 16 ----------------
 configs/firefly-rk3399_defconfig | 16 ----------------
 configs/puma-rk3399_defconfig    | 16 ----------------
 configs/rock960-rk3399_defconfig | 16 ----------------
 7 files changed, 16 insertions(+), 96 deletions(-)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index b9a026abb5..dbe7f11d39 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -132,9 +132,25 @@ config ROCKCHIP_RK3399
 	select ARM64
 	select SUPPORT_SPL
 	select SPL
+	select SPL_ATF
+	select SPL_ATF_NO_PLATFORM_PARAM if SPL_ATF
+	select SPL_LOAD_FIT
+	select SPL_CLK if SPL
+	select SPL_PINCTRL if SPL
+	select SPL_RAM if SPL
+	select SPL_REGMAP if SPL
+	select SPL_SYSCON if SPL
 	select SPL_SEPARATE_BSS
 	select SPL_SERIAL_SUPPORT
 	select SPL_DRIVERS_MISC_SUPPORT
+	select CLK
+	select FIT
+	select PINCTRL
+	select RAM
+	select REGMAP
+	select SYSCON
+	select DM_PMIC
+	select DM_REGULATOR_FIXED
 	select DEBUG_UART_BOARD_INIT
 	select BOARD_LATE_INIT
 	select ROCKCHIP_BROM_HELPER
diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index 04e25e1d4f..fdcbabf912 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -17,16 +17,12 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
 CONFIG_SPL_SPI_LOAD=y
-CONFIG_SPL_ATF=y
-CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
@@ -45,12 +41,6 @@ CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-gru-bob"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_MMC=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_SPL_SYSCON=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_I2C_CROS_EC_TUNNEL=y
 CONFIG_SYS_I2C_ROCKCHIP=y
@@ -70,16 +60,10 @@ CONFIG_SPI_FLASH_GIGADEVICE=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PINCTRL=y
-CONFIG_SPL_PINCTRL=y
-CONFIG_DM_PMIC=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_REGULATOR_PWM=y
-CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
-CONFIG_RAM=y
-CONFIG_SPL_RAM=y
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_ROCKCHIP_SPI=y
 CONFIG_SYSRESET=y
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 49b2e2e089..1ba9dcba62 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -11,15 +11,11 @@ CONFIG_DEBUG_UART_CLOCK=24000000
 CONFIG_SPL_STACK_R_ADDR=0x80000
 CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
-CONFIG_SPL_ATF=y
-CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_MMC=y
@@ -32,12 +28,6 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3399-evb"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_NET_RANDOM_ETHADDR=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_SPL_SYSCON=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MMC_DW=y
@@ -47,16 +37,10 @@ CONFIG_SF_DEFAULT_SPEED=20000000
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PINCTRL=y
-CONFIG_SPL_PINCTRL=y
-CONFIG_DM_PMIC=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_REGULATOR_PWM=y
-CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
-CONFIG_RAM=y
-CONFIG_SPL_RAM=y
 CONFIG_BAUDRATE=1500000
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYSRESET=y
diff --git a/configs/ficus-rk3399_defconfig b/configs/ficus-rk3399_defconfig
index fe3b9964e8..67c62065aa 100644
--- a/configs/ficus-rk3399_defconfig
+++ b/configs/ficus-rk3399_defconfig
@@ -11,14 +11,10 @@ CONFIG_DEBUG_UART_BASE=0xFF1A0000
 CONFIG_DEBUG_UART_CLOCK=24000000
 CONFIG_SPL_STACK_R_ADDR=0x80000
 CONFIG_DEBUG_UART=y
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
-CONFIG_SPL_ATF=y
-CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_MMC=y
@@ -31,12 +27,6 @@ CONFIG_DEFAULT_DEVICE_TREE="rk3399-ficus"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_NET_RANDOM_ETHADDR=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_SPL_SYSCON=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MMC_DW=y
@@ -48,17 +38,11 @@ CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_RGMII=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PINCTRL=y
-CONFIG_SPL_PINCTRL=y
-CONFIG_DM_PMIC=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_REGULATOR_PWM=y
-CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
-CONFIG_RAM=y
-CONFIG_SPL_RAM=y
 CONFIG_BAUDRATE=1500000
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYSRESET=y
diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig
index 914304bb43..1d3a7f2982 100644
--- a/configs/firefly-rk3399_defconfig
+++ b/configs/firefly-rk3399_defconfig
@@ -11,15 +11,11 @@ CONFIG_DEBUG_UART_CLOCK=24000000
 CONFIG_SPL_STACK_R_ADDR=0x80000
 CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-firefly.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
-CONFIG_SPL_ATF=y
-CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_MMC=y
@@ -31,12 +27,6 @@ CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-firefly"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_MMC=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_SPL_SYSCON=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MMC_DW=y
@@ -47,16 +37,10 @@ CONFIG_SF_DEFAULT_SPEED=20000000
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PINCTRL=y
-CONFIG_SPL_PINCTRL=y
-CONFIG_DM_PMIC=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_REGULATOR_PWM=y
-CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
-CONFIG_RAM=y
-CONFIG_SPL_RAM=y
 CONFIG_BAUDRATE=1500000
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYSRESET=y
diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index 3547ec6b27..e5ea2fe0b3 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -15,8 +15,6 @@ CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI_SUPPORT=y
 CONFIG_DEBUG_UART=y
 CONFIG_NR_DRAM_BANKS=1
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_SOURCE="board/theobroma-systems/puma_rk3399/fit_spl_atf.its"
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-puma-haikou.dtb"
 CONFIG_MISC_INIT_R=y
@@ -31,8 +29,6 @@ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
 CONFIG_SPL_I2C_SUPPORT=y
 CONFIG_SPL_POWER_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
-CONFIG_SPL_ATF=y
-CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
@@ -51,12 +47,6 @@ CONFIG_OF_LIVE=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-puma-ddr1600"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_MMC=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_SPL_SYSCON=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
@@ -74,20 +64,14 @@ CONFIG_PHY_MICREL_KSZ90X1=y
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PINCTRL=y
-CONFIG_SPL_PINCTRL=y
-CONFIG_DM_PMIC=y
 CONFIG_DM_PMIC_FAN53555=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_SPL_DM_REGULATOR=y
 CONFIG_REGULATOR_PWM=y
-CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_SPL_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
-CONFIG_RAM=y
-CONFIG_SPL_RAM=y
 CONFIG_DM_RTC=y
 CONFIG_RTC_ISL1208=y
 CONFIG_DEBUG_UART_SHIFT=2
diff --git a/configs/rock960-rk3399_defconfig b/configs/rock960-rk3399_defconfig
index 5e6778ea20..cc7d6f89b1 100644
--- a/configs/rock960-rk3399_defconfig
+++ b/configs/rock960-rk3399_defconfig
@@ -11,15 +11,11 @@ CONFIG_DEBUG_UART_BASE=0xFF1A0000
 CONFIG_DEBUG_UART_CLOCK=24000000
 CONFIG_SPL_STACK_R_ADDR=0x80000
 CONFIG_DEBUG_UART=y
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock960.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
-CONFIG_SPL_ATF=y
-CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_SYS_PROMPT="rock960 => "
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
@@ -32,12 +28,6 @@ CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-rock960"
 CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_IS_IN_MMC=y
-CONFIG_REGMAP=y
-CONFIG_SPL_REGMAP=y
-CONFIG_SYSCON=y
-CONFIG_SPL_SYSCON=y
-CONFIG_CLK=y
-CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MMC_DW=y
@@ -45,16 +35,10 @@ CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_ROCKCHIP=y
 CONFIG_SF_DEFAULT_SPEED=20000000
-CONFIG_PINCTRL=y
-CONFIG_SPL_PINCTRL=y
-CONFIG_DM_PMIC=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_REGULATOR_PWM=y
-CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
-CONFIG_RAM=y
-CONFIG_SPL_RAM=y
 CONFIG_BAUDRATE=1500000
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYSRESET=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-25 17:34 ` [U-Boot] " Jagan Teki
@ 2019-04-25 17:34     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

Add initial support for Orangepi RK3399 board.

Specification
- Rockchip RK3399
- 2GB/4GB DDR3
- 16GB eMMC
- SD card slot
- RTL8211E 1Gbps
- AP6356S WiFI/BT
- HDMI In/Out, DP, MIPI DSI/CSI
- Mini PCIe
- Sensors, Keys etc
- DC12V-2A and DC5V-2A

Commit details about Linux DTS sync:
"arm64: dts: rockchip: Add support for the Orange Pi RK3399"
(sha1: d3e71487a790979057c0fdbf32f85033639c16e6)

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
---
 arch/arm/dts/Makefile                    |   1 +
 arch/arm/dts/rk3399-orangepi-u-boot.dtsi |   7 +
 arch/arm/dts/rk3399-orangepi.dts         | 771 +++++++++++++++++++++++
 board/rockchip/evb_rk3399/MAINTAINERS    |   7 +
 configs/orangepi-rk3399_defconfig        |  58 ++
 5 files changed, 844 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-orangepi-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-orangepi.dts
 create mode 100644 configs/orangepi-rk3399_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0e2ffdb87f..6d55b0caf8 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -87,6 +87,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3399-evb.dtb \
 	rk3399-firefly.dtb \
 	rk3399-gru-bob.dtb \
+	rk3399-orangepi.dtb \
 	rk3399-puma-ddr1333.dtb \
 	rk3399-puma-ddr1600.dtb \
 	rk3399-puma-ddr1866.dtb \
diff --git a/arch/arm/dts/rk3399-orangepi-u-boot.dtsi b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
new file mode 100644
index 0000000000..236b61d78d
--- /dev/null
+++ b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+ */
+
+#include "rk3399-u-boot.dtsi"
+#include "rk3399-sdram-ddr3-1333.dtsi"
diff --git a/arch/arm/dts/rk3399-orangepi.dts b/arch/arm/dts/rk3399-orangepi.dts
new file mode 100644
index 0000000000..cf37b96a6b
--- /dev/null
+++ b/arch/arm/dts/rk3399-orangepi.dts
@@ -0,0 +1,771 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+
+#include "dt-bindings/pwm/pwm.h"
+#include "dt-bindings/input/input.h"
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+	model = "Orange Pi RK3399 Board";
+	compatible = "rockchip,rk3399-orangepi", "rockchip,rk3399";
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	clkin_gmac: external-gmac-clock {
+		compatible = "fixed-clock";
+		clock-frequency = <125000000>;
+		clock-output-names = "clkin_gmac";
+		#clock-cells = <0>;
+	};
+
+	adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 1>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-up {
+			label = "Volume Up";
+			linux,code = <KEY_VOLUMEUP>;
+			press-threshold-microvolt = <100000>;
+		};
+
+		button-down {
+			label = "Volume Down";
+			linux,code = <KEY_VOLUMEDOWN>;
+			press-threshold-microvolt = <300000>;
+		};
+
+		back {
+			label = "Back";
+			linux,code = <KEY_BACK>;
+			press-threshold-microvolt = <985000>;
+		};
+
+		menu {
+			label = "Menu";
+			linux,code = <KEY_MENU>;
+			press-threshold-microvolt = <1314000>;
+		};
+	};
+
+	dc_12v: dc-12v {
+		compatible = "regulator-fixed";
+		regulator-name = "dc_12v";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	keys: gpio-keys {
+		compatible = "gpio-keys";
+		autorepeat;
+
+		power {
+			debounce-interval = <100>;
+			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
+			label = "GPIO Power";
+			linux,code = <KEY_POWER>;
+			linux,input-type = <1>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pwr_btn>;
+			wakeup-source;
+		};
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&rk808 1>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_reg_on_h>;
+		reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
+	};
+
+	/* switched by pmic_sleep */
+	vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc1v8_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc_1v8>;
+	};
+
+	vcc3v0_sd: vcc3v0-sd {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmmc0_pwr_h>;
+		regulator-boot-on;
+		regulator-max-microvolt = <3000000>;
+		regulator-min-microvolt = <3000000>;
+		regulator-name = "vcc3v0_sd";
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc5v0_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PD1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host_en>;
+		regulator-name = "vcc5v0_host";
+		regulator-always-on;
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc5v0_typec0: vcc5v0-typec0-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_typec0_en>;
+		regulator-name = "vcc5v0_typec0";
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc_sys: vcc-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&dc_12v>;
+	};
+
+	vdd_log: vdd-log {
+		compatible = "pwm-regulator";
+		pwms = <&pwm2 0 25000 1>;
+		regulator-name = "vdd_log";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <1400000>;
+		vin-supply = <&vcc_sys>;
+	};
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+	status = "okay";
+};
+
+&gmac {
+	assigned-clocks = <&cru SCLK_RMII_SRC>;
+	assigned-clock-parents = <&clkin_gmac>;
+	clock_in_out = "input";
+	phy-supply = <&vcc3v3_s3>;
+	phy-mode = "rgmii";
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_pins>;
+	snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+	snps,reset-active-low;
+	snps,reset-delays-us = <0 10000 50000>;
+	tx_delay = <0x28>;
+	rx_delay = <0x11>;
+	status = "okay";
+};
+
+&gpu {
+	mali-supply = <&vdd_gpu>;
+	status = "okay";
+};
+
+&hdmi {
+	ddc-i2c-bus = <&i2c3>;
+	status = "okay";
+};
+
+&hdmi_sound {
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	i2c-scl-rising-time-ns = <168>;
+	i2c-scl-falling-time-ns = <4>;
+	status = "okay";
+
+	rk808: pmic@1b {
+		compatible = "rockchip,rk808";
+		reg = <0x1b>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+		#clock-cells = <1>;
+		clock-output-names = "rtc_clko_soc", "rtc_clko_wifi";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int_l>;
+		rockchip,system-power-controller;
+		wakeup-source;
+
+		vcc1-supply = <&vcc3v3_sys>;
+		vcc2-supply = <&vcc3v3_sys>;
+		vcc3-supply = <&vcc3v3_sys>;
+		vcc4-supply = <&vcc3v3_sys>;
+		vcc6-supply = <&vcc3v3_sys>;
+		vcc7-supply = <&vcc3v3_sys>;
+		vcc8-supply = <&vcc3v3_sys>;
+		vcc9-supply = <&vcc3v3_sys>;
+		vcc10-supply = <&vcc3v3_sys>;
+		vcc11-supply = <&vcc3v3_sys>;
+		vcc12-supply = <&vcc3v3_sys>;
+		vddio-supply = <&vcc_3v0>;
+
+		regulators {
+			vdd_center: DCDC_REG1 {
+				regulator-name = "vdd_center";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <700000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_l: DCDC_REG2 {
+				regulator-name = "vdd_cpu_l";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <700000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-name = "vcc_ddr";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_1v8: DCDC_REG4 {
+				regulator-name = "vcc_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc1v8_dvp: LDO_REG1 {
+				regulator-name = "vcc1v8_dvp";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v0_tp: LDO_REG2 {
+				regulator-name = "vcc3v0_tp";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc1v8_pmupll: LDO_REG3 {
+				regulator-name = "vcc1v8_pmupll";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc_sdio: LDO_REG4 {
+				regulator-name = "vcc_sdio";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcca3v0_codec: LDO_REG5 {
+				regulator-name = "vcca3v0_codec";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v5: LDO_REG6 {
+				regulator-name = "vcc_1v5";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1500000>;
+				};
+			};
+
+			vcca1v8_codec: LDO_REG7 {
+				regulator-name = "vcca1v8_codec";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v0: LDO_REG8 {
+				regulator-name = "vcc_3v0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcc3v3_s3: SWITCH_REG1 {
+				regulator-name = "vcc3v3_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_s0: SWITCH_REG2 {
+				regulator-name = "vcc3v3_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+
+	vdd_cpu_b: regulator@40 {
+		compatible = "silergy,syr827";
+		reg = <0x40>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_b";
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-ramp-delay = <1000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc3v3_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_gpu: regulator@41 {
+		compatible = "silergy,syr828";
+		reg = <0x41>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_gpu";
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-ramp-delay = <1000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc3v3_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c1 {
+	i2c-scl-rising-time-ns = <450>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+};
+
+&i2c3 {
+	i2c-scl-rising-time-ns = <450>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+};
+
+&i2c4 {
+	clock-frequency = <400000>;
+	i2c-scl-rising-time-ns = <450>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+
+	ak09911@c {
+		compatible = "asahi-kasei,ak09911";
+		reg = <0x0c>;
+		vdd-supply = <&vcc3v3_s3>;
+	};
+
+	mpu6500@68 {
+		compatible = "invensense,mpu6500";
+		reg = <0x68>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <RK_PC6 IRQ_TYPE_EDGE_RISING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gsensor_int_l>;
+		vddio-supply = <&vcc3v3_s3>;
+	};
+
+	lsm6ds3@6a {
+		compatible = "st,lsm6ds3";
+		reg = <0x6a>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <RK_PD0 IRQ_TYPE_EDGE_RISING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gyr_int_l>;
+		vdd-supply = <&vcc3v3_s3>;
+		vddio-supply = <&vcc3v3_s3>;
+	};
+
+	cm32181@10 {
+		compatible = "capella,cm32181";
+		reg = <0x10>;
+		interrupt-parent = <&gpio4>;
+		interrupts = <RK_PD0 IRQ_TYPE_EDGE_RISING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&light_int_l>;
+		vdd-supply = <&vcc3v3_s3>;
+	};
+};
+
+&io_domains {
+	status = "okay";
+	bt656-supply = <&vcc_3v0>;
+	audio-supply = <&vcca1v8_codec>;
+	sdmmc-supply = <&vcc_sdio>;
+	gpio1830-supply = <&vcc_3v0>;
+};
+
+&pmu_io_domains {
+	status = "okay";
+	pmu1830-supply = <&vcc_3v0>;
+};
+
+&pinctrl {
+	buttons {
+		pwr_btn: pwr-btn {
+			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	pmic {
+		pmic_int_l: pmic-int-l {
+			rockchip,pins =
+				<1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	sd {
+		sdmmc0_pwr_h: sdmmc0-pwr-h {
+			rockchip,pins =
+				<RK_GPIO0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb2 {
+		vcc5v0_host_en: vcc5v0-host-en {
+			rockchip,pins =
+				<4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		vcc5v0_typec0_en: vcc5v0-typec0-en {
+			rockchip,pins =
+				<1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	sdio-pwrseq {
+		wifi_reg_on_h: wifi-reg-on-h {
+			rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	wifi {
+		wifi_host_wake_l: wifi-host-wake-l {
+			rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	bluetooth {
+		bt_reg_on_h: bt-enable-h {
+			rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_host_wake_l: bt-host-wake-l {
+			rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_l: bt-wake-l {
+			rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	mpu6500 {
+		gsensor_int_l: gsensor-int-l {
+			rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	lsm6ds3 {
+		gyr_int_l: gyr-int-l {
+			rockchip,pins = <1 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	cm32181 {
+		light_int_l: light-int-l {
+			rockchip,pins = <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&pwm0 {
+	status = "okay";
+};
+
+&pwm2 {
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcca1v8_s3>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	non-removable;
+	status = "okay";
+};
+
+&sdio0 {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	clock-frequency = <50000000>;
+	disable-wp;
+	keep-power-in-suspend;
+	max-frequency = <50000000>;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
+	sd-uhs-sdr104;
+	status = "okay";
+
+	brcmf: wifi@1 {
+		compatible = "brcm,bcm4329-fmac";
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;
+		interrupt-names = "host-wake";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_host_wake_l>;
+	};
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+	clock-frequency = <150000000>;
+	disable-wp;
+	max-frequency = <150000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
+	vmmc-supply = <&vcc3v0_sd>;
+	vqmmc-supply = <&vcc_sdio>;
+	status = "okay";
+};
+
+&tcphy0 {
+	status = "okay";
+};
+
+&tcphy1 {
+	status = "okay";
+};
+
+&tsadc {
+	rockchip,hw-tshut-mode = <1>;
+	rockchip,hw-tshut-polarity = <1>;
+	status = "okay";
+};
+
+&u2phy0 {
+	status = "okay";
+
+	u2phy0_otg: otg-port {
+		phy-supply = <&vcc5v0_typec0>;
+		status = "okay";
+	};
+
+	u2phy0_host: host-port {
+		phy-supply = <&vcc5v0_host>;
+		status = "okay";
+	};
+};
+
+&u2phy1 {
+	status = "okay";
+
+	u2phy1_otg: otg-port {
+		status = "okay";
+	};
+
+	u2phy1_host: host-port {
+		phy-supply = <&vcc5v0_host>;
+		status = "okay";
+	};
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_xfer &uart0_cts &uart0_rts>;
+	status = "okay";
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		clocks = <&rk808 1>;
+		clock-names = "ext_clock";
+		device-wakeup-gpios = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>;
+		host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>;
+		shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_host_wake_l &bt_wake_l &bt_reg_on_h>;
+	};
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&usbdrd3_0 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_0 {
+	status = "okay";
+	dr_mode = "otg";
+};
+
+&usbdrd3_1 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+	status = "okay";
+	dr_mode = "host";
+};
+
+&vopb {
+	status = "okay";
+};
+
+&vopb_mmu {
+	status = "okay";
+};
+
+&vopl {
+	status = "okay";
+};
+
+&vopl_mmu {
+	status = "okay";
+};
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index caad30641e..07ee8ce92c 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -5,3 +5,10 @@ F:      board/rockchip/evb_rk3399
 F:      include/configs/evb_rk3399.h
 F:      configs/evb-rk3399_defconfig
 F:      configs/firefly-rk3399_defconfig
+
+ORANGEPI-RK3399
+M:	Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+S:	Maintained
+F:	configs/orangepi-rk3399_defconfig
+F:	arch/arm/dts/rk3399-u-boot.dtsi
+F:	arch/arm/dts/rk3399-orangepi-u-boot.dtsi
diff --git a/configs/orangepi-rk3399_defconfig b/configs/orangepi-rk3399_defconfig
new file mode 100644
index 0000000000..deb7bc1388
--- /dev/null
+++ b/configs/orangepi-rk3399_defconfig
@@ -0,0 +1,58 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-orangepi.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-orangepi"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_BAUDRATE=1500000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_ERRNO_STR=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-25 17:34     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

Add initial support for Orangepi RK3399 board.

Specification
- Rockchip RK3399
- 2GB/4GB DDR3
- 16GB eMMC
- SD card slot
- RTL8211E 1Gbps
- AP6356S WiFI/BT
- HDMI In/Out, DP, MIPI DSI/CSI
- Mini PCIe
- Sensors, Keys etc
- DC12V-2A and DC5V-2A

Commit details about Linux DTS sync:
"arm64: dts: rockchip: Add support for the Orange Pi RK3399"
(sha1: d3e71487a790979057c0fdbf32f85033639c16e6)

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm/dts/Makefile                    |   1 +
 arch/arm/dts/rk3399-orangepi-u-boot.dtsi |   7 +
 arch/arm/dts/rk3399-orangepi.dts         | 771 +++++++++++++++++++++++
 board/rockchip/evb_rk3399/MAINTAINERS    |   7 +
 configs/orangepi-rk3399_defconfig        |  58 ++
 5 files changed, 844 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-orangepi-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-orangepi.dts
 create mode 100644 configs/orangepi-rk3399_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0e2ffdb87f..6d55b0caf8 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -87,6 +87,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3399-evb.dtb \
 	rk3399-firefly.dtb \
 	rk3399-gru-bob.dtb \
+	rk3399-orangepi.dtb \
 	rk3399-puma-ddr1333.dtb \
 	rk3399-puma-ddr1600.dtb \
 	rk3399-puma-ddr1866.dtb \
diff --git a/arch/arm/dts/rk3399-orangepi-u-boot.dtsi b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
new file mode 100644
index 0000000000..236b61d78d
--- /dev/null
+++ b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+#include "rk3399-u-boot.dtsi"
+#include "rk3399-sdram-ddr3-1333.dtsi"
diff --git a/arch/arm/dts/rk3399-orangepi.dts b/arch/arm/dts/rk3399-orangepi.dts
new file mode 100644
index 0000000000..cf37b96a6b
--- /dev/null
+++ b/arch/arm/dts/rk3399-orangepi.dts
@@ -0,0 +1,771 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ */
+
+/dts-v1/;
+
+#include "dt-bindings/pwm/pwm.h"
+#include "dt-bindings/input/input.h"
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+	model = "Orange Pi RK3399 Board";
+	compatible = "rockchip,rk3399-orangepi", "rockchip,rk3399";
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	clkin_gmac: external-gmac-clock {
+		compatible = "fixed-clock";
+		clock-frequency = <125000000>;
+		clock-output-names = "clkin_gmac";
+		#clock-cells = <0>;
+	};
+
+	adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 1>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-up {
+			label = "Volume Up";
+			linux,code = <KEY_VOLUMEUP>;
+			press-threshold-microvolt = <100000>;
+		};
+
+		button-down {
+			label = "Volume Down";
+			linux,code = <KEY_VOLUMEDOWN>;
+			press-threshold-microvolt = <300000>;
+		};
+
+		back {
+			label = "Back";
+			linux,code = <KEY_BACK>;
+			press-threshold-microvolt = <985000>;
+		};
+
+		menu {
+			label = "Menu";
+			linux,code = <KEY_MENU>;
+			press-threshold-microvolt = <1314000>;
+		};
+	};
+
+	dc_12v: dc-12v {
+		compatible = "regulator-fixed";
+		regulator-name = "dc_12v";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	keys: gpio-keys {
+		compatible = "gpio-keys";
+		autorepeat;
+
+		power {
+			debounce-interval = <100>;
+			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
+			label = "GPIO Power";
+			linux,code = <KEY_POWER>;
+			linux,input-type = <1>;
+			pinctrl-names = "default";
+			pinctrl-0 = <&pwr_btn>;
+			wakeup-source;
+		};
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&rk808 1>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_reg_on_h>;
+		reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
+	};
+
+	/* switched by pmic_sleep */
+	vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc1v8_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc_1v8>;
+	};
+
+	vcc3v0_sd: vcc3v0-sd {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmmc0_pwr_h>;
+		regulator-boot-on;
+		regulator-max-microvolt = <3000000>;
+		regulator-min-microvolt = <3000000>;
+		regulator-name = "vcc3v0_sd";
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc5v0_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PD1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host_en>;
+		regulator-name = "vcc5v0_host";
+		regulator-always-on;
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc5v0_typec0: vcc5v0-typec0-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_typec0_en>;
+		regulator-name = "vcc5v0_typec0";
+		vin-supply = <&vcc_sys>;
+	};
+
+	vcc_sys: vcc-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&dc_12v>;
+	};
+
+	vdd_log: vdd-log {
+		compatible = "pwm-regulator";
+		pwms = <&pwm2 0 25000 1>;
+		regulator-name = "vdd_log";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <1400000>;
+		vin-supply = <&vcc_sys>;
+	};
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+	status = "okay";
+};
+
+&gmac {
+	assigned-clocks = <&cru SCLK_RMII_SRC>;
+	assigned-clock-parents = <&clkin_gmac>;
+	clock_in_out = "input";
+	phy-supply = <&vcc3v3_s3>;
+	phy-mode = "rgmii";
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_pins>;
+	snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+	snps,reset-active-low;
+	snps,reset-delays-us = <0 10000 50000>;
+	tx_delay = <0x28>;
+	rx_delay = <0x11>;
+	status = "okay";
+};
+
+&gpu {
+	mali-supply = <&vdd_gpu>;
+	status = "okay";
+};
+
+&hdmi {
+	ddc-i2c-bus = <&i2c3>;
+	status = "okay";
+};
+
+&hdmi_sound {
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	i2c-scl-rising-time-ns = <168>;
+	i2c-scl-falling-time-ns = <4>;
+	status = "okay";
+
+	rk808: pmic at 1b {
+		compatible = "rockchip,rk808";
+		reg = <0x1b>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+		#clock-cells = <1>;
+		clock-output-names = "rtc_clko_soc", "rtc_clko_wifi";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int_l>;
+		rockchip,system-power-controller;
+		wakeup-source;
+
+		vcc1-supply = <&vcc3v3_sys>;
+		vcc2-supply = <&vcc3v3_sys>;
+		vcc3-supply = <&vcc3v3_sys>;
+		vcc4-supply = <&vcc3v3_sys>;
+		vcc6-supply = <&vcc3v3_sys>;
+		vcc7-supply = <&vcc3v3_sys>;
+		vcc8-supply = <&vcc3v3_sys>;
+		vcc9-supply = <&vcc3v3_sys>;
+		vcc10-supply = <&vcc3v3_sys>;
+		vcc11-supply = <&vcc3v3_sys>;
+		vcc12-supply = <&vcc3v3_sys>;
+		vddio-supply = <&vcc_3v0>;
+
+		regulators {
+			vdd_center: DCDC_REG1 {
+				regulator-name = "vdd_center";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <700000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_l: DCDC_REG2 {
+				regulator-name = "vdd_cpu_l";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <700000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-name = "vcc_ddr";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_1v8: DCDC_REG4 {
+				regulator-name = "vcc_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc1v8_dvp: LDO_REG1 {
+				regulator-name = "vcc1v8_dvp";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v0_tp: LDO_REG2 {
+				regulator-name = "vcc3v0_tp";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc1v8_pmupll: LDO_REG3 {
+				regulator-name = "vcc1v8_pmupll";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc_sdio: LDO_REG4 {
+				regulator-name = "vcc_sdio";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcca3v0_codec: LDO_REG5 {
+				regulator-name = "vcca3v0_codec";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v5: LDO_REG6 {
+				regulator-name = "vcc_1v5";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1500000>;
+				};
+			};
+
+			vcca1v8_codec: LDO_REG7 {
+				regulator-name = "vcca1v8_codec";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <2500000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v0: LDO_REG8 {
+				regulator-name = "vcc_3v0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3400000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcc3v3_s3: SWITCH_REG1 {
+				regulator-name = "vcc3v3_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_s0: SWITCH_REG2 {
+				regulator-name = "vcc3v3_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+
+	vdd_cpu_b: regulator at 40 {
+		compatible = "silergy,syr827";
+		reg = <0x40>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_cpu_b";
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-ramp-delay = <1000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc3v3_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_gpu: regulator at 41 {
+		compatible = "silergy,syr828";
+		reg = <0x41>;
+		fcs,suspend-voltage-selector = <1>;
+		regulator-name = "vdd_gpu";
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-ramp-delay = <1000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc3v3_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c1 {
+	i2c-scl-rising-time-ns = <450>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+};
+
+&i2c3 {
+	i2c-scl-rising-time-ns = <450>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+};
+
+&i2c4 {
+	clock-frequency = <400000>;
+	i2c-scl-rising-time-ns = <450>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+
+	ak09911 at c {
+		compatible = "asahi-kasei,ak09911";
+		reg = <0x0c>;
+		vdd-supply = <&vcc3v3_s3>;
+	};
+
+	mpu6500 at 68 {
+		compatible = "invensense,mpu6500";
+		reg = <0x68>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <RK_PC6 IRQ_TYPE_EDGE_RISING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gsensor_int_l>;
+		vddio-supply = <&vcc3v3_s3>;
+	};
+
+	lsm6ds3 at 6a {
+		compatible = "st,lsm6ds3";
+		reg = <0x6a>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <RK_PD0 IRQ_TYPE_EDGE_RISING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gyr_int_l>;
+		vdd-supply = <&vcc3v3_s3>;
+		vddio-supply = <&vcc3v3_s3>;
+	};
+
+	cm32181 at 10 {
+		compatible = "capella,cm32181";
+		reg = <0x10>;
+		interrupt-parent = <&gpio4>;
+		interrupts = <RK_PD0 IRQ_TYPE_EDGE_RISING>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&light_int_l>;
+		vdd-supply = <&vcc3v3_s3>;
+	};
+};
+
+&io_domains {
+	status = "okay";
+	bt656-supply = <&vcc_3v0>;
+	audio-supply = <&vcca1v8_codec>;
+	sdmmc-supply = <&vcc_sdio>;
+	gpio1830-supply = <&vcc_3v0>;
+};
+
+&pmu_io_domains {
+	status = "okay";
+	pmu1830-supply = <&vcc_3v0>;
+};
+
+&pinctrl {
+	buttons {
+		pwr_btn: pwr-btn {
+			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	pmic {
+		pmic_int_l: pmic-int-l {
+			rockchip,pins =
+				<1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	sd {
+		sdmmc0_pwr_h: sdmmc0-pwr-h {
+			rockchip,pins =
+				<RK_GPIO0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb2 {
+		vcc5v0_host_en: vcc5v0-host-en {
+			rockchip,pins =
+				<4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		vcc5v0_typec0_en: vcc5v0-typec0-en {
+			rockchip,pins =
+				<1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	sdio-pwrseq {
+		wifi_reg_on_h: wifi-reg-on-h {
+			rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	wifi {
+		wifi_host_wake_l: wifi-host-wake-l {
+			rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	bluetooth {
+		bt_reg_on_h: bt-enable-h {
+			rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_host_wake_l: bt-host-wake-l {
+			rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_l: bt-wake-l {
+			rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	mpu6500 {
+		gsensor_int_l: gsensor-int-l {
+			rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	lsm6ds3 {
+		gyr_int_l: gyr-int-l {
+			rockchip,pins = <1 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	cm32181 {
+		light_int_l: light-int-l {
+			rockchip,pins = <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&pwm0 {
+	status = "okay";
+};
+
+&pwm2 {
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcca1v8_s3>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	non-removable;
+	status = "okay";
+};
+
+&sdio0 {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	clock-frequency = <50000000>;
+	disable-wp;
+	keep-power-in-suspend;
+	max-frequency = <50000000>;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
+	sd-uhs-sdr104;
+	status = "okay";
+
+	brcmf: wifi at 1 {
+		compatible = "brcm,bcm4329-fmac";
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;
+		interrupt-names = "host-wake";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_host_wake_l>;
+	};
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+	clock-frequency = <150000000>;
+	disable-wp;
+	max-frequency = <150000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
+	vmmc-supply = <&vcc3v0_sd>;
+	vqmmc-supply = <&vcc_sdio>;
+	status = "okay";
+};
+
+&tcphy0 {
+	status = "okay";
+};
+
+&tcphy1 {
+	status = "okay";
+};
+
+&tsadc {
+	rockchip,hw-tshut-mode = <1>;
+	rockchip,hw-tshut-polarity = <1>;
+	status = "okay";
+};
+
+&u2phy0 {
+	status = "okay";
+
+	u2phy0_otg: otg-port {
+		phy-supply = <&vcc5v0_typec0>;
+		status = "okay";
+	};
+
+	u2phy0_host: host-port {
+		phy-supply = <&vcc5v0_host>;
+		status = "okay";
+	};
+};
+
+&u2phy1 {
+	status = "okay";
+
+	u2phy1_otg: otg-port {
+		status = "okay";
+	};
+
+	u2phy1_host: host-port {
+		phy-supply = <&vcc5v0_host>;
+		status = "okay";
+	};
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_xfer &uart0_cts &uart0_rts>;
+	status = "okay";
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		clocks = <&rk808 1>;
+		clock-names = "ext_clock";
+		device-wakeup-gpios = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>;
+		host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>;
+		shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_host_wake_l &bt_wake_l &bt_reg_on_h>;
+	};
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&usbdrd3_0 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_0 {
+	status = "okay";
+	dr_mode = "otg";
+};
+
+&usbdrd3_1 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+	status = "okay";
+	dr_mode = "host";
+};
+
+&vopb {
+	status = "okay";
+};
+
+&vopb_mmu {
+	status = "okay";
+};
+
+&vopl {
+	status = "okay";
+};
+
+&vopl_mmu {
+	status = "okay";
+};
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index caad30641e..07ee8ce92c 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -5,3 +5,10 @@ F:      board/rockchip/evb_rk3399
 F:      include/configs/evb_rk3399.h
 F:      configs/evb-rk3399_defconfig
 F:      configs/firefly-rk3399_defconfig
+
+ORANGEPI-RK3399
+M:	Jagan Teki <jagan@amarulasolutions.com>
+S:	Maintained
+F:	configs/orangepi-rk3399_defconfig
+F:	arch/arm/dts/rk3399-u-boot.dtsi
+F:	arch/arm/dts/rk3399-orangepi-u-boot.dtsi
diff --git a/configs/orangepi-rk3399_defconfig b/configs/orangepi-rk3399_defconfig
new file mode 100644
index 0000000000..deb7bc1388
--- /dev/null
+++ b/configs/orangepi-rk3399_defconfig
@@ -0,0 +1,58 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-orangepi.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-orangepi"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_BAUDRATE=1500000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_ERRNO_STR=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [PATCH v3 07/13] rockchip: dts: rk3399: Sync rk3399-nanopi4.dtsi from Linux
  2019-04-25 17:34 ` [U-Boot] " Jagan Teki
@ 2019-04-25 17:34     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

Sync rk3399-nanopi4.dtsi from Linux 5.1-rc2 tag.

Linux commit details about the rk3399-nanopi4.dtsi sync:
"arm64: dts: rockchip: Add nanopi4 bluetooth"
(sha1: 3e2f0bb72be36aa6c14ee7f11ac4dd8014801030)

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
---
 arch/arm/dts/rk3399-nanopi4.dtsi | 703 +++++++++++++++++++++++++++++++
 1 file changed, 703 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-nanopi4.dtsi

diff --git a/arch/arm/dts/rk3399-nanopi4.dtsi b/arch/arm/dts/rk3399-nanopi4.dtsi
new file mode 100644
index 0000000000..d325e11728
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi4.dtsi
@@ -0,0 +1,703 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * RK3399-based FriendlyElec boards device tree source
+ *
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2019 Arm Ltd.
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	clkin_gmac: external-gmac-clock {
+		compatible = "fixed-clock";
+		clock-frequency = <125000000>;
+		clock-output-names = "clkin_gmac";
+		#clock-cells = <0>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys {
+		compatible = "regulator-fixed";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-name = "vcc3v3_sys";
+	};
+
+	vcc5v0_sys: vcc5v0-sys {
+		compatible = "regulator-fixed";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-name = "vcc5v0_sys";
+		vin-supply = <&vdd_5v>;
+	};
+
+	/* switched by pmic_sleep */
+	vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
+		compatible = "regulator-fixed";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-name = "vcc1v8_s3";
+		vin-supply = <&vcc_1v8>;
+	};
+
+	vcc3v0_sd: vcc3v0-sd {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmmc0_pwr_h>;
+		regulator-always-on;
+		regulator-min-microvolt = <3000000>;
+		regulator-max-microvolt = <3000000>;
+		regulator-name = "vcc3v0_sd";
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	vbus_typec: vbus-typec {
+		compatible = "regulator-fixed";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-name = "vbus_typec";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		autorepeat;
+		pinctrl-names = "default";
+		pinctrl-0 = <&power_key>;
+
+		power {
+			debounce-interval = <100>;
+			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
+			label = "GPIO Key Power";
+			linux,code = <KEY_POWER>;
+			wakeup-source;
+		};
+	};
+
+	leds: gpio-leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&leds_gpio>;
+
+		status {
+			gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
+			label = "status_led";
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&rk808 1>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_reg_on_h>;
+		reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&emmc_phy {
+	status = "okay";
+};
+
+&gmac {
+	assigned-clock-parents = <&clkin_gmac>;
+	assigned-clocks = <&cru SCLK_RMII_SRC>;
+	clock_in_out = "input";
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_pins>;
+	phy-mode = "rgmii";
+	phy-supply = <&vcc3v3_s3>;
+	snps,reset-active-low;
+	snps,reset-delays-us = <0 10000 50000>;
+	snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+	tx_delay = <0x28>;
+	rx_delay = <0x11>;
+	status = "okay";
+};
+
+&gpu {
+	mali-supply = <&vdd_gpu>;
+	status = "okay";
+};
+
+&hdmi {
+	ddc-i2c-bus = <&i2c7>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&hdmi_cec>;
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	i2c-scl-rising-time-ns = <160>;
+	i2c-scl-falling-time-ns = <30>;
+	status = "okay";
+
+	vdd_cpu_b: regulator@40 {
+		compatible = "silergy,syr827";
+		reg = <0x40>;
+		fcs,suspend-voltage-selector = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&cpu_b_sleep>;
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-name = "vdd_cpu_b";
+		regulator-ramp-delay = <1000>;
+		vin-supply = <&vcc3v3_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_gpu: regulator@41 {
+		compatible = "silergy,syr828";
+		reg = <0x41>;
+		fcs,suspend-voltage-selector = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gpu_sleep>;
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-name = "vdd_gpu";
+		regulator-ramp-delay = <1000>;
+		vin-supply = <&vcc3v3_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	rk808: pmic@1b {
+		compatible = "rockchip,rk808";
+		reg = <0x1b>;
+		clock-output-names = "xin32k", "rtc_clko_wifi";
+		#clock-cells = <1>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int_l>;
+		rockchip,system-power-controller;
+		wakeup-source;
+
+		vcc1-supply = <&vcc3v3_sys>;
+		vcc2-supply = <&vcc3v3_sys>;
+		vcc3-supply = <&vcc3v3_sys>;
+		vcc4-supply = <&vcc3v3_sys>;
+		vcc6-supply = <&vcc3v3_sys>;
+		vcc7-supply = <&vcc3v3_sys>;
+		vcc8-supply = <&vcc3v3_sys>;
+		vcc9-supply = <&vcc3v3_sys>;
+		vcc10-supply = <&vcc3v3_sys>;
+		vcc11-supply = <&vcc3v3_sys>;
+		vcc12-supply = <&vcc3v3_sys>;
+		vddio-supply = <&vcc_3v0>;
+
+		regulators {
+			vdd_center: DCDC_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-name = "vdd_center";
+				regulator-ramp-delay = <6001>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_l: DCDC_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-name = "vdd_cpu_l";
+				regulator-ramp-delay = <6001>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vcc_ddr";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_1v8: DCDC_REG4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc1v8_cam: LDO_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc1v8_cam";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v0_touch: LDO_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc3v0_touch";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc1v8_pmupll: LDO_REG3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc1v8_pmupll";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc_sdio: LDO_REG4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-init-microvolt = <3000000>;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc_sdio";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcca3v0_codec: LDO_REG5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcca3v0_codec";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v5: LDO_REG6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-name = "vcc_1v5";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1500000>;
+				};
+			};
+
+			vcca1v8_codec: LDO_REG7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcca1v8_codec";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v0: LDO_REG8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc_3v0";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcc3v3_s3: SWITCH_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vcc3v3_s3";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_s0: SWITCH_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vcc3v3_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&i2c1 {
+	clock-frequency = <200000>;
+	i2c-scl-rising-time-ns = <150>;
+	i2c-scl-falling-time-ns = <30>;
+	status = "okay";
+};
+
+&i2c2 {
+	status = "okay";
+};
+
+&i2c4 {
+	clock-frequency = <400000>;
+	i2c-scl-rising-time-ns = <160>;
+	i2c-scl-falling-time-ns = <30>;
+	status = "okay";
+
+	fusb0: typec-portc@22 {
+		compatible = "fcs,fusb302";
+		reg = <0x22>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&fusb0_int>;
+		vbus-supply = <&vbus_typec>;
+	};
+};
+
+&i2c7 {
+	status = "okay";
+};
+
+&io_domains {
+	bt656-supply = <&vcc_1v8>;
+	audio-supply = <&vcca1v8_codec>;
+	sdmmc-supply = <&vcc_sdio>;
+	gpio1830-supply = <&vcc_3v0>;
+	status = "okay";
+};
+
+&pcie_phy {
+	assigned-clock-parents = <&cru SCLK_PCIEPHY_REF100M>;
+	assigned-clock-rates = <100000000>;
+	assigned-clocks = <&cru SCLK_PCIEPHY_REF>;
+	status = "okay";
+};
+
+&pcie0 {
+	ep-gpios = <&gpio2 RK_PA4 GPIO_ACTIVE_HIGH>;
+	max-link-speed = <2>;
+	num-lanes = <4>;
+	status = "okay";
+};
+
+&pinctrl {
+	fusb30x {
+		fusb0_int: fusb0-int {
+			rockchip,pins = <1 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	gpio-leds {
+		leds_gpio: leds-gpio {
+			rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		cpu_b_sleep: cpu-b-sleep {
+			rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		gpu_sleep: gpu-sleep {
+			rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		pmic_int_l: pmic-int-l {
+			rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	rockchip-key {
+		power_key: power-key {
+			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	sdio {
+		bt_host_wake_l: bt-host-wake-l {
+			rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_reg_on_h: bt-reg-on-h {
+			/* external pullup to VCC1V8_PMUPLL */
+			rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_l: bt-wake-l {
+			rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wifi_reg_on_h: wifi-reg_on-h {
+			rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	sdmmc {
+		sdmmc0_det_l: sdmmc0-det-l {
+			rockchip,pins = <0 RK_PA7 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		sdmmc0_pwr_h: sdmmc0-pwr-h {
+			rockchip,pins = <0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&pmu_io_domains {
+	pmu1830-supply = <&vcc_3v0>;
+	status = "okay";
+};
+
+&pwm0 {
+	status = "okay";
+};
+
+&pwm1 {
+	status = "okay";
+};
+
+&pwm2 {
+	pinctrl-names = "active";
+	pinctrl-0 = <&pwm2_pin_pull_down>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcca1v8_s3>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	mmc-hs200-1_8v;
+	non-removable;
+	status = "okay";
+};
+
+&sdio0 {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	keep-power-in-suspend;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
+	sd-uhs-sdr104;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-mmc-highspeed;
+	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+	disable-wp;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd &sdmmc0_det_l>;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc3v0_sd>;
+	vqmmc-supply = <&vcc_sdio>;
+	status = "okay";
+};
+
+&tcphy0 {
+	status = "okay";
+};
+
+&tcphy1 {
+	status = "okay";
+};
+
+&tsadc {
+	/* tshut mode 0:CRU 1:GPIO */
+	rockchip,hw-tshut-mode = <1>;
+	/* tshut polarity 0:LOW 1:HIGH */
+	rockchip,hw-tshut-polarity = <1>;
+	status = "okay";
+};
+
+&u2phy0 {
+	status = "okay";
+};
+
+&u2phy0_host {
+	status = "okay";
+};
+
+&u2phy0_otg {
+	status = "okay";
+};
+
+&u2phy1 {
+	status = "okay";
+};
+
+&u2phy1_host {
+	status = "okay";
+};
+
+&u2phy1_otg {
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_xfer &uart0_rts &uart0_cts>;
+	status = "okay";
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		clocks = <&rk808 1>;
+		clock-names = "lpo";
+		device-wakeup-gpios = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>;
+		host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>;
+		shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>;
+		max-speed = <4000000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_reg_on_h &bt_host_wake_l &bt_wake_l>;
+		vbat-supply = <&vcc3v3_sys>;
+		vddio-supply = <&vcc_1v8>;
+	};
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usbdrd3_0 {
+	status = "okay";
+};
+
+&usbdrd3_1 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_0 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&vopb {
+	status = "okay";
+};
+
+&vopb_mmu {
+	status = "okay";
+};
+
+&vopl {
+	status = "okay";
+};
+
+&vopl_mmu {
+	status = "okay";
+};
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 07/13] rockchip: dts: rk3399: Sync rk3399-nanopi4.dtsi from Linux
@ 2019-04-25 17:34     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

Sync rk3399-nanopi4.dtsi from Linux 5.1-rc2 tag.

Linux commit details about the rk3399-nanopi4.dtsi sync:
"arm64: dts: rockchip: Add nanopi4 bluetooth"
(sha1: 3e2f0bb72be36aa6c14ee7f11ac4dd8014801030)

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm/dts/rk3399-nanopi4.dtsi | 703 +++++++++++++++++++++++++++++++
 1 file changed, 703 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-nanopi4.dtsi

diff --git a/arch/arm/dts/rk3399-nanopi4.dtsi b/arch/arm/dts/rk3399-nanopi4.dtsi
new file mode 100644
index 0000000000..d325e11728
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi4.dtsi
@@ -0,0 +1,703 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * RK3399-based FriendlyElec boards device tree source
+ *
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2019 Arm Ltd.
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	clkin_gmac: external-gmac-clock {
+		compatible = "fixed-clock";
+		clock-frequency = <125000000>;
+		clock-output-names = "clkin_gmac";
+		#clock-cells = <0>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys {
+		compatible = "regulator-fixed";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-name = "vcc3v3_sys";
+	};
+
+	vcc5v0_sys: vcc5v0-sys {
+		compatible = "regulator-fixed";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-name = "vcc5v0_sys";
+		vin-supply = <&vdd_5v>;
+	};
+
+	/* switched by pmic_sleep */
+	vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
+		compatible = "regulator-fixed";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-name = "vcc1v8_s3";
+		vin-supply = <&vcc_1v8>;
+	};
+
+	vcc3v0_sd: vcc3v0-sd {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmmc0_pwr_h>;
+		regulator-always-on;
+		regulator-min-microvolt = <3000000>;
+		regulator-max-microvolt = <3000000>;
+		regulator-name = "vcc3v0_sd";
+		vin-supply = <&vcc3v3_sys>;
+	};
+
+	vbus_typec: vbus-typec {
+		compatible = "regulator-fixed";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		regulator-name = "vbus_typec";
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		autorepeat;
+		pinctrl-names = "default";
+		pinctrl-0 = <&power_key>;
+
+		power {
+			debounce-interval = <100>;
+			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
+			label = "GPIO Key Power";
+			linux,code = <KEY_POWER>;
+			wakeup-source;
+		};
+	};
+
+	leds: gpio-leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&leds_gpio>;
+
+		status {
+			gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
+			label = "status_led";
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&rk808 1>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_reg_on_h>;
+		reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&emmc_phy {
+	status = "okay";
+};
+
+&gmac {
+	assigned-clock-parents = <&clkin_gmac>;
+	assigned-clocks = <&cru SCLK_RMII_SRC>;
+	clock_in_out = "input";
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_pins>;
+	phy-mode = "rgmii";
+	phy-supply = <&vcc3v3_s3>;
+	snps,reset-active-low;
+	snps,reset-delays-us = <0 10000 50000>;
+	snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+	tx_delay = <0x28>;
+	rx_delay = <0x11>;
+	status = "okay";
+};
+
+&gpu {
+	mali-supply = <&vdd_gpu>;
+	status = "okay";
+};
+
+&hdmi {
+	ddc-i2c-bus = <&i2c7>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&hdmi_cec>;
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	i2c-scl-rising-time-ns = <160>;
+	i2c-scl-falling-time-ns = <30>;
+	status = "okay";
+
+	vdd_cpu_b: regulator at 40 {
+		compatible = "silergy,syr827";
+		reg = <0x40>;
+		fcs,suspend-voltage-selector = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&cpu_b_sleep>;
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-name = "vdd_cpu_b";
+		regulator-ramp-delay = <1000>;
+		vin-supply = <&vcc3v3_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_gpu: regulator at 41 {
+		compatible = "silergy,syr828";
+		reg = <0x41>;
+		fcs,suspend-voltage-selector = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gpu_sleep>;
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-name = "vdd_gpu";
+		regulator-ramp-delay = <1000>;
+		vin-supply = <&vcc3v3_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	rk808: pmic at 1b {
+		compatible = "rockchip,rk808";
+		reg = <0x1b>;
+		clock-output-names = "xin32k", "rtc_clko_wifi";
+		#clock-cells = <1>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int_l>;
+		rockchip,system-power-controller;
+		wakeup-source;
+
+		vcc1-supply = <&vcc3v3_sys>;
+		vcc2-supply = <&vcc3v3_sys>;
+		vcc3-supply = <&vcc3v3_sys>;
+		vcc4-supply = <&vcc3v3_sys>;
+		vcc6-supply = <&vcc3v3_sys>;
+		vcc7-supply = <&vcc3v3_sys>;
+		vcc8-supply = <&vcc3v3_sys>;
+		vcc9-supply = <&vcc3v3_sys>;
+		vcc10-supply = <&vcc3v3_sys>;
+		vcc11-supply = <&vcc3v3_sys>;
+		vcc12-supply = <&vcc3v3_sys>;
+		vddio-supply = <&vcc_3v0>;
+
+		regulators {
+			vdd_center: DCDC_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-name = "vdd_center";
+				regulator-ramp-delay = <6001>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_l: DCDC_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-name = "vdd_cpu_l";
+				regulator-ramp-delay = <6001>;
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vcc_ddr";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_1v8: DCDC_REG4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc_1v8";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc1v8_cam: LDO_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc1v8_cam";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v0_touch: LDO_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc3v0_touch";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc1v8_pmupll: LDO_REG3 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcc1v8_pmupll";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc_sdio: LDO_REG4 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-init-microvolt = <3000000>;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-name = "vcc_sdio";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcca3v0_codec: LDO_REG5 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcca3v0_codec";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v5: LDO_REG6 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-name = "vcc_1v5";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1500000>;
+				};
+			};
+
+			vcca1v8_codec: LDO_REG7 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-name = "vcca1v8_codec";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v0: LDO_REG8 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-name = "vcc_3v0";
+
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcc3v3_s3: SWITCH_REG1 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vcc3v3_s3";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_s0: SWITCH_REG2 {
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-name = "vcc3v3_s0";
+
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+};
+
+&i2c1 {
+	clock-frequency = <200000>;
+	i2c-scl-rising-time-ns = <150>;
+	i2c-scl-falling-time-ns = <30>;
+	status = "okay";
+};
+
+&i2c2 {
+	status = "okay";
+};
+
+&i2c4 {
+	clock-frequency = <400000>;
+	i2c-scl-rising-time-ns = <160>;
+	i2c-scl-falling-time-ns = <30>;
+	status = "okay";
+
+	fusb0: typec-portc at 22 {
+		compatible = "fcs,fusb302";
+		reg = <0x22>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&fusb0_int>;
+		vbus-supply = <&vbus_typec>;
+	};
+};
+
+&i2c7 {
+	status = "okay";
+};
+
+&io_domains {
+	bt656-supply = <&vcc_1v8>;
+	audio-supply = <&vcca1v8_codec>;
+	sdmmc-supply = <&vcc_sdio>;
+	gpio1830-supply = <&vcc_3v0>;
+	status = "okay";
+};
+
+&pcie_phy {
+	assigned-clock-parents = <&cru SCLK_PCIEPHY_REF100M>;
+	assigned-clock-rates = <100000000>;
+	assigned-clocks = <&cru SCLK_PCIEPHY_REF>;
+	status = "okay";
+};
+
+&pcie0 {
+	ep-gpios = <&gpio2 RK_PA4 GPIO_ACTIVE_HIGH>;
+	max-link-speed = <2>;
+	num-lanes = <4>;
+	status = "okay";
+};
+
+&pinctrl {
+	fusb30x {
+		fusb0_int: fusb0-int {
+			rockchip,pins = <1 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	gpio-leds {
+		leds_gpio: leds-gpio {
+			rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		cpu_b_sleep: cpu-b-sleep {
+			rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		gpu_sleep: gpu-sleep {
+			rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		pmic_int_l: pmic-int-l {
+			rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	rockchip-key {
+		power_key: power-key {
+			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	sdio {
+		bt_host_wake_l: bt-host-wake-l {
+			rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_reg_on_h: bt-reg-on-h {
+			/* external pullup to VCC1V8_PMUPLL */
+			rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_l: bt-wake-l {
+			rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wifi_reg_on_h: wifi-reg_on-h {
+			rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	sdmmc {
+		sdmmc0_det_l: sdmmc0-det-l {
+			rockchip,pins = <0 RK_PA7 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		sdmmc0_pwr_h: sdmmc0-pwr-h {
+			rockchip,pins = <0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&pmu_io_domains {
+	pmu1830-supply = <&vcc_3v0>;
+	status = "okay";
+};
+
+&pwm0 {
+	status = "okay";
+};
+
+&pwm1 {
+	status = "okay";
+};
+
+&pwm2 {
+	pinctrl-names = "active";
+	pinctrl-0 = <&pwm2_pin_pull_down>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcca1v8_s3>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	mmc-hs200-1_8v;
+	non-removable;
+	status = "okay";
+};
+
+&sdio0 {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	keep-power-in-suspend;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	non-removable;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
+	sd-uhs-sdr104;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-mmc-highspeed;
+	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+	disable-wp;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd &sdmmc0_det_l>;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc3v0_sd>;
+	vqmmc-supply = <&vcc_sdio>;
+	status = "okay";
+};
+
+&tcphy0 {
+	status = "okay";
+};
+
+&tcphy1 {
+	status = "okay";
+};
+
+&tsadc {
+	/* tshut mode 0:CRU 1:GPIO */
+	rockchip,hw-tshut-mode = <1>;
+	/* tshut polarity 0:LOW 1:HIGH */
+	rockchip,hw-tshut-polarity = <1>;
+	status = "okay";
+};
+
+&u2phy0 {
+	status = "okay";
+};
+
+&u2phy0_host {
+	status = "okay";
+};
+
+&u2phy0_otg {
+	status = "okay";
+};
+
+&u2phy1 {
+	status = "okay";
+};
+
+&u2phy1_host {
+	status = "okay";
+};
+
+&u2phy1_otg {
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_xfer &uart0_rts &uart0_cts>;
+	status = "okay";
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		clocks = <&rk808 1>;
+		clock-names = "lpo";
+		device-wakeup-gpios = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>;
+		host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>;
+		shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>;
+		max-speed = <4000000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_reg_on_h &bt_host_wake_l &bt_wake_l>;
+		vbat-supply = <&vcc3v3_sys>;
+		vddio-supply = <&vcc_1v8>;
+	};
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usbdrd3_0 {
+	status = "okay";
+};
+
+&usbdrd3_1 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_0 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+	dr_mode = "host";
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&vopb {
+	status = "okay";
+};
+
+&vopb_mmu {
+	status = "okay";
+};
+
+&vopl {
+	status = "okay";
+};
+
+&vopl_mmu {
+	status = "okay";
+};
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [PATCH v3 08/13] rockchip: dts: rk3399: nanopi4: Use CD pin as RK_FUNC_1
  2019-04-25 17:34 ` [U-Boot] " Jagan Teki
@ 2019-04-25 17:34     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

sdmmc cd pin is configured as RK_FUNC_GPIO which is wrong and
indeed failed to detect the sdcard on the board with below error

  Card did not respond to voltage select!

So, fix it by replacing RK_FUNC_GPIO with RK_FUNC_1 which
is already defined in rk3399.dts so make use of same like
other boards.

Add these changes in -u-boot.dtsi to make Linux sync easy for future
changes.

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi

diff --git a/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi b/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
new file mode 100644
index 0000000000..20db99c0b8
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+ */
+
+&sdmmc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd &sdmmc_cd>;
+};
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 08/13] rockchip: dts: rk3399: nanopi4: Use CD pin as RK_FUNC_1
@ 2019-04-25 17:34     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

sdmmc cd pin is configured as RK_FUNC_GPIO which is wrong and
indeed failed to detect the sdcard on the board with below error

  Card did not respond to voltage select!

So, fix it by replacing RK_FUNC_GPIO with RK_FUNC_1 which
is already defined in rk3399.dts so make use of same like
other boards.

Add these changes in -u-boot.dtsi to make Linux sync easy for future
changes.

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi

diff --git a/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi b/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
new file mode 100644
index 0000000000..20db99c0b8
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+&sdmmc {
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd &sdmmc_cd>;
+};
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [PATCH v3 09/13] rockchip: rk3399: Add Nanopi M4 board support
  2019-04-25 17:34 ` [U-Boot] " Jagan Teki
@ 2019-04-25 17:34     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

Add initial support for Nanopi M4 board.

Specification
- Rockchip RK3399
- Dual-Channel 4GB LPDDR3-1866
- SD card slot
- eMMC socket
- RTL8211E 1Gbps
- AP6356S WiFI/BT
- HDMI In/Out, DP, MIPI DSI/CSI
- USB 3.0 x4
- USB Type C power and data
- GPIO1, GPIO2 expansion ports
- DC5V/3A

Commit details of rk3399-nanopi-m4.dts sync from Linux 5.1-rc2:
"arm64: dts: rockchip: Refine nanopi4 differences"
(sha1: c62ffaf5026d0b7633e62b2cea8450b5543c349a)

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Reviewed-by: Kever Yang <kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Reviewed-by: Philipp Tomsich <philipp.tomsich-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
---
 arch/arm/dts/Makefile                     |  1 +
 arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi |  7 +++
 arch/arm/dts/rk3399-nanopi-m4.dts         | 66 +++++++++++++++++++++++
 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi   |  2 +
 board/rockchip/evb_rk3399/MAINTAINERS     |  6 +++
 configs/nanopi-m4-rk3399_defconfig        | 58 ++++++++++++++++++++
 6 files changed, 140 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-nanopi-m4.dts
 create mode 100644 configs/nanopi-m4-rk3399_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 6d55b0caf8..d2ac26b556 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -87,6 +87,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3399-evb.dtb \
 	rk3399-firefly.dtb \
 	rk3399-gru-bob.dtb \
+	rk3399-nanopi-m4.dtb \
 	rk3399-orangepi.dtb \
 	rk3399-puma-ddr1333.dtb \
 	rk3399-puma-ddr1600.dtb \
diff --git a/arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi b/arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
new file mode 100644
index 0000000000..17201bcf41
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+ */
+
+#include "rk3399-nanopi4-u-boot.dtsi"
+#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi"
diff --git a/arch/arm/dts/rk3399-nanopi-m4.dts b/arch/arm/dts/rk3399-nanopi-m4.dts
new file mode 100644
index 0000000000..60358ab8c7
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-m4.dts
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec NanoPi M4 board device tree source
+ *
+ * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2019 Arm Ltd.
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+	model = "FriendlyElec NanoPi M4";
+	compatible = "friendlyarm,nanopi-m4", "rockchip,rk3399";
+
+	vdd_5v: vdd-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_5v";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	vcc5v0_core: vcc5v0-core {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_core";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vdd_5v>;
+	};
+
+	vcc5v0_usb1: vcc5v0-usb1 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb1";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_usb2: vcc5v0-usb2 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb2";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&vcc3v3_sys {
+	vin-supply = <&vcc5v0_core>;
+};
+
+&u2phy0_host {
+	phy-supply = <&vcc5v0_usb1>;
+};
+
+&u2phy1_host {
+	phy-supply = <&vcc5v0_usb2>;
+};
+
+&vbus_typec {
+	regulator-always-on;
+	vin-supply = <&vdd_5v>;
+};
diff --git a/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi b/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
index 20db99c0b8..05708b6f55 100644
--- a/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
@@ -3,6 +3,8 @@
  * Copyright (C) 2019 Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
  */
 
+#include "rk3399-u-boot.dtsi"
+
 &sdmmc {
 	pinctrl-names = "default";
 	pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd &sdmmc_cd>;
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index 07ee8ce92c..ae43805a6a 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -6,6 +6,12 @@ F:      include/configs/evb_rk3399.h
 F:      configs/evb-rk3399_defconfig
 F:      configs/firefly-rk3399_defconfig
 
+NANOPI-M4
+M:	Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+S:	Maintained
+F:	configs/nanopi-m4-rk3399_defconfig
+F:	arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
+
 ORANGEPI-RK3399
 M:	Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
 S:	Maintained
diff --git a/configs/nanopi-m4-rk3399_defconfig b/configs/nanopi-m4-rk3399_defconfig
new file mode 100644
index 0000000000..be36a28315
--- /dev/null
+++ b/configs/nanopi-m4-rk3399_defconfig
@@ -0,0 +1,58 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopi-m4.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-nanopi-m4"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_BAUDRATE=1500000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_ERRNO_STR=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 09/13] rockchip: rk3399: Add Nanopi M4 board support
@ 2019-04-25 17:34     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

Add initial support for Nanopi M4 board.

Specification
- Rockchip RK3399
- Dual-Channel 4GB LPDDR3-1866
- SD card slot
- eMMC socket
- RTL8211E 1Gbps
- AP6356S WiFI/BT
- HDMI In/Out, DP, MIPI DSI/CSI
- USB 3.0 x4
- USB Type C power and data
- GPIO1, GPIO2 expansion ports
- DC5V/3A

Commit details of rk3399-nanopi-m4.dts sync from Linux 5.1-rc2:
"arm64: dts: rockchip: Refine nanopi4 differences"
(sha1: c62ffaf5026d0b7633e62b2cea8450b5543c349a)

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
 arch/arm/dts/Makefile                     |  1 +
 arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi |  7 +++
 arch/arm/dts/rk3399-nanopi-m4.dts         | 66 +++++++++++++++++++++++
 arch/arm/dts/rk3399-nanopi4-u-boot.dtsi   |  2 +
 board/rockchip/evb_rk3399/MAINTAINERS     |  6 +++
 configs/nanopi-m4-rk3399_defconfig        | 58 ++++++++++++++++++++
 6 files changed, 140 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-nanopi-m4.dts
 create mode 100644 configs/nanopi-m4-rk3399_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 6d55b0caf8..d2ac26b556 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -87,6 +87,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3399-evb.dtb \
 	rk3399-firefly.dtb \
 	rk3399-gru-bob.dtb \
+	rk3399-nanopi-m4.dtb \
 	rk3399-orangepi.dtb \
 	rk3399-puma-ddr1333.dtb \
 	rk3399-puma-ddr1600.dtb \
diff --git a/arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi b/arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
new file mode 100644
index 0000000000..17201bcf41
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+#include "rk3399-nanopi4-u-boot.dtsi"
+#include "rk3399-sdram-lpddr3-samsung-4GB-1866.dtsi"
diff --git a/arch/arm/dts/rk3399-nanopi-m4.dts b/arch/arm/dts/rk3399-nanopi-m4.dts
new file mode 100644
index 0000000000..60358ab8c7
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-m4.dts
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * FriendlyElec NanoPi M4 board device tree source
+ *
+ * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2019 Arm Ltd.
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+	model = "FriendlyElec NanoPi M4";
+	compatible = "friendlyarm,nanopi-m4", "rockchip,rk3399";
+
+	vdd_5v: vdd-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_5v";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	vcc5v0_core: vcc5v0-core {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_core";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vdd_5v>;
+	};
+
+	vcc5v0_usb1: vcc5v0-usb1 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb1";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_usb2: vcc5v0-usb2 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb2";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&vcc3v3_sys {
+	vin-supply = <&vcc5v0_core>;
+};
+
+&u2phy0_host {
+	phy-supply = <&vcc5v0_usb1>;
+};
+
+&u2phy1_host {
+	phy-supply = <&vcc5v0_usb2>;
+};
+
+&vbus_typec {
+	regulator-always-on;
+	vin-supply = <&vdd_5v>;
+};
diff --git a/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi b/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
index 20db99c0b8..05708b6f55 100644
--- a/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-nanopi4-u-boot.dtsi
@@ -3,6 +3,8 @@
  * Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
  */
 
+#include "rk3399-u-boot.dtsi"
+
 &sdmmc {
 	pinctrl-names = "default";
 	pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd &sdmmc_cd>;
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index 07ee8ce92c..ae43805a6a 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -6,6 +6,12 @@ F:      include/configs/evb_rk3399.h
 F:      configs/evb-rk3399_defconfig
 F:      configs/firefly-rk3399_defconfig
 
+NANOPI-M4
+M:	Jagan Teki <jagan@amarulasolutions.com>
+S:	Maintained
+F:	configs/nanopi-m4-rk3399_defconfig
+F:	arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
+
 ORANGEPI-RK3399
 M:	Jagan Teki <jagan@amarulasolutions.com>
 S:	Maintained
diff --git a/configs/nanopi-m4-rk3399_defconfig b/configs/nanopi-m4-rk3399_defconfig
new file mode 100644
index 0000000000..be36a28315
--- /dev/null
+++ b/configs/nanopi-m4-rk3399_defconfig
@@ -0,0 +1,58 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopi-m4.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-nanopi-m4"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_BAUDRATE=1500000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_ERRNO_STR=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [PATCH v3 10/13] rockchip: rk3399: Add Nanopi NEO4 board support
  2019-04-25 17:34 ` [U-Boot] " Jagan Teki
@ 2019-04-25 17:34     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

Add initial support for Nanopi NEO4 board.

Specification
- Rockchip RK3399
- 1GB DDR3-1866
- SD card slot
- eMMC Socket
- RTL8211E 1Gbps
- AP6212 WiFI/BT
- HDMI In/Out, DP, MIPI CSI
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- DC 5V/3A

Commit details of rk3399-nanopi-neo4.dts sync from Linux:
"arm64: dts: rockchip: Add Nanopi NEO4 initial support"
(sha1: 092470b537f19788d957aed12d835a179b606014)

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 arch/arm/dts/Makefile                       |  1 +
 arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi |  6 +++
 arch/arm/dts/rk3399-nanopi-neo4.dts         | 50 ++++++++++++++++++
 board/rockchip/evb_rk3399/MAINTAINERS       |  6 +++
 configs/nanopi-neo4-rk3399_defconfig        | 58 +++++++++++++++++++++
 5 files changed, 121 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-nanopi-neo4.dts
 create mode 100644 configs/nanopi-neo4-rk3399_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d2ac26b556..e909cb8180 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -88,6 +88,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3399-firefly.dtb \
 	rk3399-gru-bob.dtb \
 	rk3399-nanopi-m4.dtb \
+	rk3399-nanopi-neo4.dtb \
 	rk3399-orangepi.dtb \
 	rk3399-puma-ddr1333.dtb \
 	rk3399-puma-ddr1600.dtb \
diff --git a/arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi b/arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi
new file mode 100644
index 0000000000..7d22528f49
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+ */
+
+#include "rk3399-nanopi4-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-nanopi-neo4.dts b/arch/arm/dts/rk3399-nanopi-neo4.dts
new file mode 100644
index 0000000000..195410b089
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-neo4.dts
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 Amarula Solutions B.V.
+ * Author: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+ */
+
+/dts-v1/;
+
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+	model = "FriendlyARM NanoPi NEO4";
+	compatible = "friendlyarm,nanopi-neo4", "rockchip,rk3399";
+
+	vdd_5v: vdd-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_5v";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	vcc5v0_core: vcc5v0-core {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_core";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vdd_5v>;
+	};
+
+	vcc5v0_usb1: vcc5v0-usb1 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb1";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&vcc3v3_sys {
+	vin-supply = <&vcc5v0_core>;
+};
+
+&u2phy0_host {
+	phy-supply = <&vcc5v0_usb1>;
+};
+
+&vbus_typec {
+	regulator-always-on;
+	vin-supply = <&vdd_5v>;
+};
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index ae43805a6a..004916ed1f 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -12,6 +12,12 @@ S:	Maintained
 F:	configs/nanopi-m4-rk3399_defconfig
 F:	arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
 
+NANOPI-NEO4
+M:	Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+S:	Maintained
+F:	configs/nanopi-neo4-rk3399_defconfig
+F:	arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi
+
 ORANGEPI-RK3399
 M:	Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
 S:	Maintained
diff --git a/configs/nanopi-neo4-rk3399_defconfig b/configs/nanopi-neo4-rk3399_defconfig
new file mode 100644
index 0000000000..eb9d81ae87
--- /dev/null
+++ b/configs/nanopi-neo4-rk3399_defconfig
@@ -0,0 +1,58 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopi-neo4.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-nanopi-neo4"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_BAUDRATE=1500000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_ERRNO_STR=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 10/13] rockchip: rk3399: Add Nanopi NEO4 board support
@ 2019-04-25 17:34     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

Add initial support for Nanopi NEO4 board.

Specification
- Rockchip RK3399
- 1GB DDR3-1866
- SD card slot
- eMMC Socket
- RTL8211E 1Gbps
- AP6212 WiFI/BT
- HDMI In/Out, DP, MIPI CSI
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- DC 5V/3A

Commit details of rk3399-nanopi-neo4.dts sync from Linux:
"arm64: dts: rockchip: Add Nanopi NEO4 initial support"
(sha1: 092470b537f19788d957aed12d835a179b606014)

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 arch/arm/dts/Makefile                       |  1 +
 arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi |  6 +++
 arch/arm/dts/rk3399-nanopi-neo4.dts         | 50 ++++++++++++++++++
 board/rockchip/evb_rk3399/MAINTAINERS       |  6 +++
 configs/nanopi-neo4-rk3399_defconfig        | 58 +++++++++++++++++++++
 5 files changed, 121 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-nanopi-neo4.dts
 create mode 100644 configs/nanopi-neo4-rk3399_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d2ac26b556..e909cb8180 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -88,6 +88,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3399-firefly.dtb \
 	rk3399-gru-bob.dtb \
 	rk3399-nanopi-m4.dtb \
+	rk3399-nanopi-neo4.dtb \
 	rk3399-orangepi.dtb \
 	rk3399-puma-ddr1333.dtb \
 	rk3399-puma-ddr1600.dtb \
diff --git a/arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi b/arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi
new file mode 100644
index 0000000000..7d22528f49
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+#include "rk3399-nanopi4-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-nanopi-neo4.dts b/arch/arm/dts/rk3399-nanopi-neo4.dts
new file mode 100644
index 0000000000..195410b089
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-neo4.dts
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2019 Amarula Solutions B.V.
+ * Author: Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+/dts-v1/;
+
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+	model = "FriendlyARM NanoPi NEO4";
+	compatible = "friendlyarm,nanopi-neo4", "rockchip,rk3399";
+
+	vdd_5v: vdd-5v {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_5v";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	vcc5v0_core: vcc5v0-core {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_core";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vdd_5v>;
+	};
+
+	vcc5v0_usb1: vcc5v0-usb1 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb1";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&vcc3v3_sys {
+	vin-supply = <&vcc5v0_core>;
+};
+
+&u2phy0_host {
+	phy-supply = <&vcc5v0_usb1>;
+};
+
+&vbus_typec {
+	regulator-always-on;
+	vin-supply = <&vdd_5v>;
+};
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index ae43805a6a..004916ed1f 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -12,6 +12,12 @@ S:	Maintained
 F:	configs/nanopi-m4-rk3399_defconfig
 F:	arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
 
+NANOPI-NEO4
+M:	Jagan Teki <jagan@amarulasolutions.com>
+S:	Maintained
+F:	configs/nanopi-neo4-rk3399_defconfig
+F:	arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi
+
 ORANGEPI-RK3399
 M:	Jagan Teki <jagan@amarulasolutions.com>
 S:	Maintained
diff --git a/configs/nanopi-neo4-rk3399_defconfig b/configs/nanopi-neo4-rk3399_defconfig
new file mode 100644
index 0000000000..eb9d81ae87
--- /dev/null
+++ b/configs/nanopi-neo4-rk3399_defconfig
@@ -0,0 +1,58 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopi-neo4.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-nanopi-neo4"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_BAUDRATE=1500000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_ERRNO_STR=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [PATCH v3 11/13] rockchip: rk3399: Add Rockpro64 board support
  2019-04-25 17:34 ` [U-Boot] " Jagan Teki
@ 2019-04-25 17:34     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

Add initial support for Rockpro64 board.

Specification
- Rockchip RK3399
- 2/4GB Dual-Channel LPDDR3
- SD card slot
- eMMC socket
- 128Mb SPI Flash
- Gigabit ethernet
- PCIe 4X slot
- WiFI/BT module socket
- HDMI In/Out, DP, MIPI DSI/CSI, eDP
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- DC 12V/2A

Commit details of rk3399-rockpro64.dts sync from Linux 5.1-rc2:
"arm64: dts: rockchip: rockpro64 dts add usb regulator"
(sha1: 6db644c79c8d45d73b56bc389aebd85fc3679beb)

'Akash' has sent an initial patch before, so I keep him as board
maintainer and I'm co-maintainer based on our conversation.

Signed-off-by: Akash Gajjar <akash-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org>
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 arch/arm/dts/Makefile                     |   1 +
 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi |   6 +
 arch/arm/dts/rk3399-rockpro64.dts         | 712 ++++++++++++++++++++++
 board/rockchip/evb_rk3399/MAINTAINERS     |   7 +
 configs/rockpro64-rk3399_defconfig        |  58 ++
 5 files changed, 784 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-rockpro64.dts
 create mode 100644 configs/rockpro64-rk3399_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e909cb8180..65ff42bf28 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -94,6 +94,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3399-puma-ddr1600.dtb \
 	rk3399-puma-ddr1866.dtb \
 	rk3399-rock960.dtb \
+	rk3399-rockpro64.dtb \
 	rv1108-elgin-r1.dtb \
 	rv1108-evb.dtb
 dtb-$(CONFIG_ARCH_MESON) += \
diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
new file mode 100644
index 0000000000..7bddc3acdb
--- /dev/null
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+ */
+
+#include "rk3399-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-rockpro64.dts b/arch/arm/dts/rk3399-rockpro64.dts
new file mode 100644
index 0000000000..1f2394e058
--- /dev/null
+++ b/arch/arm/dts/rk3399-rockpro64.dts
@@ -0,0 +1,712 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ * Copyright (c) 2018 Akash Gajjar <Akash_Gajjar-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+	model = "Pine64 RockPro64";
+	compatible = "pine64,rockpro64", "rockchip,rk3399";
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	clkin_gmac: external-gmac-clock {
+		compatible = "fixed-clock";
+		clock-frequency = <125000000>;
+		clock-output-names = "clkin_gmac";
+		#clock-cells = <0>;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		autorepeat;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pwrbtn>;
+
+		power {
+			debounce-interval = <100>;
+			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
+			label = "GPIO Key Power";
+			linux,code = <KEY_POWER>;
+			wakeup-source;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&work_led_gpio>, <&diy_led_gpio>;
+
+		work-led {
+			label = "work";
+			default-state = "on";
+			gpios = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>;
+		};
+
+		diy-led {
+			label = "diy";
+			default-state = "off";
+			gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&rk808 1>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_enable_h>;
+
+		/*
+		 * On the module itself this is one of these (depending
+		 * on the actual card populated):
+		 * - SDIO_RESET_L_WL_REG_ON
+		 * - PDN (power down when low)
+		 */
+		reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
+	};
+
+	vcc12v_dcin: vcc12v-dcin {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	/* switched by pmic_sleep */
+	vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc1v8_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc_1v8>;
+	};
+
+	vcc3v3_pcie: vcc3v3-pcie-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio1 RK_PD0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pcie_pwr_en>;
+		regulator-name = "vcc3v3_pcie";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	/* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
+	vcc5v0_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host_en>;
+		regulator-name = "vcc5v0_host";
+		regulator-always-on;
+		vin-supply = <&vcc5v0_usb>;
+	};
+
+	vcc5v0_typec: vcc5v0-typec-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_typec_en>;
+		regulator-name = "vcc5v0_typec";
+		regulator-always-on;
+		vin-supply = <&vcc5v0_usb>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_usb: vcc5v0-usb {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vdd_log: vdd-log {
+		compatible = "pwm-regulator";
+		pwms = <&pwm2 0 25000 1>;
+		regulator-name = "vdd_log";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <1400000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+	status = "okay";
+};
+
+&gmac {
+	assigned-clocks = <&cru SCLK_RMII_SRC>;
+	assigned-clock-parents = <&clkin_gmac>;
+	clock_in_out = "input";
+	phy-supply = <&vcc_lan>;
+	phy-mode = "rgmii";
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_pins>;
+	snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+	snps,reset-active-low;
+	snps,reset-delays-us = <0 10000 50000>;
+	tx_delay = <0x28>;
+	rx_delay = <0x11>;
+	status = "okay";
+};
+
+&hdmi {
+	ddc-i2c-bus = <&i2c3>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&hdmi_cec>;
+	status = "okay";
+};
+
+&gpu {
+	mali-supply = <&vdd_gpu>;
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	i2c-scl-rising-time-ns = <168>;
+	i2c-scl-falling-time-ns = <4>;
+	status = "okay";
+
+	rk808: pmic@1b {
+		compatible = "rockchip,rk808";
+		reg = <0x1b>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+		#clock-cells = <1>;
+		clock-output-names = "xin32k", "rk808-clkout2";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int_l>;
+		rockchip,system-power-controller;
+		wakeup-source;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc3v3_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc5v0_sys>;
+		vcc12-supply = <&vcc3v3_sys>;
+		vddio-supply = <&vcca_1v8>;
+
+		regulators {
+			vdd_center: DCDC_REG1 {
+				regulator-name = "vdd_center";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_l: DCDC_REG2 {
+				regulator-name = "vdd_cpu_l";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-name = "vcc_ddr";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_1v8: DCDC_REG4 {
+				regulator-name = "vcc_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc1v8_dvp: LDO_REG1 {
+				regulator-name = "vcc1v8_dvp";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v0_touch: LDO_REG2 {
+				regulator-name = "vcc3v0_touch";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca_1v8: LDO_REG3 {
+				regulator-name = "vcca_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc_sdio: LDO_REG4 {
+				regulator-name = "vcc_sdio";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcca3v0_codec: LDO_REG5 {
+				regulator-name = "vcca3v0_codec";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v5: LDO_REG6 {
+				regulator-name = "vcc_1v5";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1500000>;
+				};
+			};
+
+			vcca1v8_codec: LDO_REG7 {
+				regulator-name = "vcca1v8_codec";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v0: LDO_REG8 {
+				regulator-name = "vcc_3v0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcc3v3_s3: vcc_lan: SWITCH_REG1 {
+				regulator-name = "vcc3v3_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_s0: SWITCH_REG2 {
+				regulator-name = "vcc3v3_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+
+	vdd_cpu_b: regulator@40 {
+		compatible = "silergy,syr827";
+		reg = <0x40>;
+		fcs,suspend-voltage-selector = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vsel1_gpio>;
+		regulator-name = "vdd_cpu_b";
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-ramp-delay = <1000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_gpu: regulator@41 {
+		compatible = "silergy,syr828";
+		reg = <0x41>;
+		fcs,suspend-voltage-selector = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vsel2_gpio>;
+		regulator-name = "vdd_gpu";
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-ramp-delay = <1000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c1 {
+	i2c-scl-rising-time-ns = <300>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+};
+
+&i2c3 {
+	i2c-scl-rising-time-ns = <450>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+};
+
+&i2c4 {
+	i2c-scl-rising-time-ns = <600>;
+	i2c-scl-falling-time-ns = <20>;
+	status = "okay";
+
+	fusb0: typec-portc@22 {
+		compatible = "fcs,fusb302";
+		reg = <0x22>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&fusb0_int>;
+		vbus-supply = <&vcc5v0_typec>;
+		status = "okay";
+	};
+};
+
+&i2s0 {
+	rockchip,playback-channels = <8>;
+	rockchip,capture-channels = <8>;
+	status = "okay";
+};
+
+&i2s1 {
+	rockchip,playback-channels = <2>;
+	rockchip,capture-channels = <2>;
+	status = "okay";
+};
+
+&i2s2 {
+	status = "okay";
+};
+
+&io_domains {
+	status = "okay";
+
+	bt656-supply = <&vcc1v8_dvp>;
+	audio-supply = <&vcca1v8_codec>;
+	sdmmc-supply = <&vcc_sdio>;
+	gpio1830-supply = <&vcc_3v0>;
+};
+
+&pmu_io_domains {
+	pmu1830-supply = <&vcc_3v0>;
+	status = "okay";
+};
+
+&pinctrl {
+	buttons {
+		pwrbtn: pwrbtn {
+			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	fusb302x {
+		fusb0_int: fusb0-int {
+			rockchip,pins = <1 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	leds {
+		work_led_gpio: work_led-gpio {
+			rockchip,pins = <0 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		diy_led_gpio: diy_led-gpio {
+			rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pcie {
+		pcie_pwr_en: pcie-pwr-en {
+			rockchip,pins = <1 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		pmic_int_l: pmic-int-l {
+			rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		vsel1_gpio: vsel1-gpio {
+			rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		vsel2_gpio: vsel2-gpio {
+			rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	sdio-pwrseq {
+		wifi_enable_h: wifi-enable-h {
+			rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb-typec {
+		vcc5v0_typec_en: vcc5v0_typec_en {
+			rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	usb2 {
+		vcc5v0_host_en: vcc5v0-host-en {
+			rockchip,pins = <4 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&pwm0 {
+	status = "okay";
+};
+
+&pwm2 {
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcca1v8_s3>;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	cd-gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
+	disable-wp;
+	max-frequency = <150000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	non-removable;
+	status = "okay";
+};
+
+&tcphy0 {
+	status = "okay";
+};
+
+&tcphy1 {
+	status = "okay";
+};
+
+&tsadc {
+	/* tshut mode 0:CRU 1:GPIO */
+	rockchip,hw-tshut-mode = <1>;
+	/* tshut polarity 0:LOW 1:HIGH */
+	rockchip,hw-tshut-polarity = <1>;
+	status = "okay";
+};
+
+&u2phy0 {
+	status = "okay";
+
+	u2phy0_otg: otg-port {
+		status = "okay";
+	};
+
+	u2phy0_host: host-port {
+		phy-supply = <&vcc5v0_host>;
+		status = "okay";
+	};
+};
+
+&u2phy1 {
+	status = "okay";
+
+	u2phy1_otg: otg-port {
+		status = "okay";
+	};
+
+	u2phy1_host: host-port {
+		phy-supply = <&vcc5v0_host>;
+		status = "okay";
+	};
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_xfer &uart0_cts>;
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&usbdrd3_0 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_0 {
+	status = "okay";
+	dr_mode = "otg";
+};
+
+&usbdrd3_1 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+	status = "okay";
+	dr_mode = "host";
+};
+
+&vopb {
+	status = "okay";
+};
+
+&vopb_mmu {
+	status = "okay";
+};
+
+&vopl {
+	status = "okay";
+};
+
+&vopl_mmu {
+	status = "okay";
+};
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index 004916ed1f..74a45adc72 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -24,3 +24,10 @@ S:	Maintained
 F:	configs/orangepi-rk3399_defconfig
 F:	arch/arm/dts/rk3399-u-boot.dtsi
 F:	arch/arm/dts/rk3399-orangepi-u-boot.dtsi
+
+ROCKPRO64
+M:	Akash Gajjar <akash-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org>
+M:	Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+S:	Maintained
+F:	configs/rockpro64-rk3399_defconfig
+F:	arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
new file mode 100644
index 0000000000..3d0c7d0c6d
--- /dev/null
+++ b/configs/rockpro64-rk3399_defconfig
@@ -0,0 +1,58 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rockpro64.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-rockpro64"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_BAUDRATE=1500000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_ERRNO_STR=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 11/13] rockchip: rk3399: Add Rockpro64 board support
@ 2019-04-25 17:34     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

Add initial support for Rockpro64 board.

Specification
- Rockchip RK3399
- 2/4GB Dual-Channel LPDDR3
- SD card slot
- eMMC socket
- 128Mb SPI Flash
- Gigabit ethernet
- PCIe 4X slot
- WiFI/BT module socket
- HDMI In/Out, DP, MIPI DSI/CSI, eDP
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- DC 12V/2A

Commit details of rk3399-rockpro64.dts sync from Linux 5.1-rc2:
"arm64: dts: rockchip: rockpro64 dts add usb regulator"
(sha1: 6db644c79c8d45d73b56bc389aebd85fc3679beb)

'Akash' has sent an initial patch before, so I keep him as board
maintainer and I'm co-maintainer based on our conversation.

Signed-off-by: Akash Gajjar <akash@openedev.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 arch/arm/dts/Makefile                     |   1 +
 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi |   6 +
 arch/arm/dts/rk3399-rockpro64.dts         | 712 ++++++++++++++++++++++
 board/rockchip/evb_rk3399/MAINTAINERS     |   7 +
 configs/rockpro64-rk3399_defconfig        |  58 ++
 5 files changed, 784 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-rockpro64.dts
 create mode 100644 configs/rockpro64-rk3399_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e909cb8180..65ff42bf28 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -94,6 +94,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3399-puma-ddr1600.dtb \
 	rk3399-puma-ddr1866.dtb \
 	rk3399-rock960.dtb \
+	rk3399-rockpro64.dtb \
 	rv1108-elgin-r1.dtb \
 	rv1108-evb.dtb
 dtb-$(CONFIG_ARCH_MESON) += \
diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
new file mode 100644
index 0000000000..7bddc3acdb
--- /dev/null
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+#include "rk3399-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-rockpro64.dts b/arch/arm/dts/rk3399-rockpro64.dts
new file mode 100644
index 0000000000..1f2394e058
--- /dev/null
+++ b/arch/arm/dts/rk3399-rockpro64.dts
@@ -0,0 +1,712 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ * Copyright (c) 2018 Akash Gajjar <Akash_Gajjar@mentor.com>
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+	model = "Pine64 RockPro64";
+	compatible = "pine64,rockpro64", "rockchip,rk3399";
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	clkin_gmac: external-gmac-clock {
+		compatible = "fixed-clock";
+		clock-frequency = <125000000>;
+		clock-output-names = "clkin_gmac";
+		#clock-cells = <0>;
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		autorepeat;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pwrbtn>;
+
+		power {
+			debounce-interval = <100>;
+			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
+			label = "GPIO Key Power";
+			linux,code = <KEY_POWER>;
+			wakeup-source;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&work_led_gpio>, <&diy_led_gpio>;
+
+		work-led {
+			label = "work";
+			default-state = "on";
+			gpios = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>;
+		};
+
+		diy-led {
+			label = "diy";
+			default-state = "off";
+			gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
+		};
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&rk808 1>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_enable_h>;
+
+		/*
+		 * On the module itself this is one of these (depending
+		 * on the actual card populated):
+		 * - SDIO_RESET_L_WL_REG_ON
+		 * - PDN (power down when low)
+		 */
+		reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
+	};
+
+	vcc12v_dcin: vcc12v-dcin {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	/* switched by pmic_sleep */
+	vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc1v8_s3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc_1v8>;
+	};
+
+	vcc3v3_pcie: vcc3v3-pcie-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio1 RK_PD0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pcie_pwr_en>;
+		regulator-name = "vcc3v3_pcie";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	/* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
+	vcc5v0_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PD2 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host_en>;
+		regulator-name = "vcc5v0_host";
+		regulator-always-on;
+		vin-supply = <&vcc5v0_usb>;
+	};
+
+	vcc5v0_typec: vcc5v0-typec-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_typec_en>;
+		regulator-name = "vcc5v0_typec";
+		regulator-always-on;
+		vin-supply = <&vcc5v0_usb>;
+	};
+
+	vcc5v0_sys: vcc5v0-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc5v0_usb: vcc5v0-usb {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_usb";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vdd_log: vdd-log {
+		compatible = "pwm-regulator";
+		pwms = <&pwm2 0 25000 1>;
+		regulator-name = "vdd_log";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <1400000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+	status = "okay";
+};
+
+&gmac {
+	assigned-clocks = <&cru SCLK_RMII_SRC>;
+	assigned-clock-parents = <&clkin_gmac>;
+	clock_in_out = "input";
+	phy-supply = <&vcc_lan>;
+	phy-mode = "rgmii";
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_pins>;
+	snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+	snps,reset-active-low;
+	snps,reset-delays-us = <0 10000 50000>;
+	tx_delay = <0x28>;
+	rx_delay = <0x11>;
+	status = "okay";
+};
+
+&hdmi {
+	ddc-i2c-bus = <&i2c3>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&hdmi_cec>;
+	status = "okay";
+};
+
+&gpu {
+	mali-supply = <&vdd_gpu>;
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	i2c-scl-rising-time-ns = <168>;
+	i2c-scl-falling-time-ns = <4>;
+	status = "okay";
+
+	rk808: pmic at 1b {
+		compatible = "rockchip,rk808";
+		reg = <0x1b>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+		#clock-cells = <1>;
+		clock-output-names = "xin32k", "rk808-clkout2";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int_l>;
+		rockchip,system-power-controller;
+		wakeup-source;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc3v3_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc5v0_sys>;
+		vcc12-supply = <&vcc3v3_sys>;
+		vddio-supply = <&vcca_1v8>;
+
+		regulators {
+			vdd_center: DCDC_REG1 {
+				regulator-name = "vdd_center";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_l: DCDC_REG2 {
+				regulator-name = "vdd_cpu_l";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-name = "vcc_ddr";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_1v8: DCDC_REG4 {
+				regulator-name = "vcc_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc1v8_dvp: LDO_REG1 {
+				regulator-name = "vcc1v8_dvp";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v0_touch: LDO_REG2 {
+				regulator-name = "vcc3v0_touch";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca_1v8: LDO_REG3 {
+				regulator-name = "vcca_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc_sdio: LDO_REG4 {
+				regulator-name = "vcc_sdio";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcca3v0_codec: LDO_REG5 {
+				regulator-name = "vcca3v0_codec";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v5: LDO_REG6 {
+				regulator-name = "vcc_1v5";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1500000>;
+				};
+			};
+
+			vcca1v8_codec: LDO_REG7 {
+				regulator-name = "vcca1v8_codec";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v0: LDO_REG8 {
+				regulator-name = "vcc_3v0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcc3v3_s3: vcc_lan: SWITCH_REG1 {
+				regulator-name = "vcc3v3_s3";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc3v3_s0: SWITCH_REG2 {
+				regulator-name = "vcc3v3_s0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+
+	vdd_cpu_b: regulator at 40 {
+		compatible = "silergy,syr827";
+		reg = <0x40>;
+		fcs,suspend-voltage-selector = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vsel1_gpio>;
+		regulator-name = "vdd_cpu_b";
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-ramp-delay = <1000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_gpu: regulator at 41 {
+		compatible = "silergy,syr828";
+		reg = <0x41>;
+		fcs,suspend-voltage-selector = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vsel2_gpio>;
+		regulator-name = "vdd_gpu";
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-ramp-delay = <1000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c1 {
+	i2c-scl-rising-time-ns = <300>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+};
+
+&i2c3 {
+	i2c-scl-rising-time-ns = <450>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+};
+
+&i2c4 {
+	i2c-scl-rising-time-ns = <600>;
+	i2c-scl-falling-time-ns = <20>;
+	status = "okay";
+
+	fusb0: typec-portc at 22 {
+		compatible = "fcs,fusb302";
+		reg = <0x22>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <RK_PA2 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&fusb0_int>;
+		vbus-supply = <&vcc5v0_typec>;
+		status = "okay";
+	};
+};
+
+&i2s0 {
+	rockchip,playback-channels = <8>;
+	rockchip,capture-channels = <8>;
+	status = "okay";
+};
+
+&i2s1 {
+	rockchip,playback-channels = <2>;
+	rockchip,capture-channels = <2>;
+	status = "okay";
+};
+
+&i2s2 {
+	status = "okay";
+};
+
+&io_domains {
+	status = "okay";
+
+	bt656-supply = <&vcc1v8_dvp>;
+	audio-supply = <&vcca1v8_codec>;
+	sdmmc-supply = <&vcc_sdio>;
+	gpio1830-supply = <&vcc_3v0>;
+};
+
+&pmu_io_domains {
+	pmu1830-supply = <&vcc_3v0>;
+	status = "okay";
+};
+
+&pinctrl {
+	buttons {
+		pwrbtn: pwrbtn {
+			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	fusb302x {
+		fusb0_int: fusb0-int {
+			rockchip,pins = <1 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	leds {
+		work_led_gpio: work_led-gpio {
+			rockchip,pins = <0 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		diy_led_gpio: diy_led-gpio {
+			rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pcie {
+		pcie_pwr_en: pcie-pwr-en {
+			rockchip,pins = <1 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		pmic_int_l: pmic-int-l {
+			rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		vsel1_gpio: vsel1-gpio {
+			rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		vsel2_gpio: vsel2-gpio {
+			rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	sdio-pwrseq {
+		wifi_enable_h: wifi-enable-h {
+			rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb-typec {
+		vcc5v0_typec_en: vcc5v0_typec_en {
+			rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	usb2 {
+		vcc5v0_host_en: vcc5v0-host-en {
+			rockchip,pins = <4 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&pwm0 {
+	status = "okay";
+};
+
+&pwm2 {
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcca1v8_s3>;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	cd-gpios = <&gpio0 7 GPIO_ACTIVE_LOW>;
+	disable-wp;
+	max-frequency = <150000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	non-removable;
+	status = "okay";
+};
+
+&tcphy0 {
+	status = "okay";
+};
+
+&tcphy1 {
+	status = "okay";
+};
+
+&tsadc {
+	/* tshut mode 0:CRU 1:GPIO */
+	rockchip,hw-tshut-mode = <1>;
+	/* tshut polarity 0:LOW 1:HIGH */
+	rockchip,hw-tshut-polarity = <1>;
+	status = "okay";
+};
+
+&u2phy0 {
+	status = "okay";
+
+	u2phy0_otg: otg-port {
+		status = "okay";
+	};
+
+	u2phy0_host: host-port {
+		phy-supply = <&vcc5v0_host>;
+		status = "okay";
+	};
+};
+
+&u2phy1 {
+	status = "okay";
+
+	u2phy1_otg: otg-port {
+		status = "okay";
+	};
+
+	u2phy1_host: host-port {
+		phy-supply = <&vcc5v0_host>;
+		status = "okay";
+	};
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0_xfer &uart0_cts>;
+	status = "okay";
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&usbdrd3_0 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_0 {
+	status = "okay";
+	dr_mode = "otg";
+};
+
+&usbdrd3_1 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+	status = "okay";
+	dr_mode = "host";
+};
+
+&vopb {
+	status = "okay";
+};
+
+&vopb_mmu {
+	status = "okay";
+};
+
+&vopl {
+	status = "okay";
+};
+
+&vopl_mmu {
+	status = "okay";
+};
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index 004916ed1f..74a45adc72 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -24,3 +24,10 @@ S:	Maintained
 F:	configs/orangepi-rk3399_defconfig
 F:	arch/arm/dts/rk3399-u-boot.dtsi
 F:	arch/arm/dts/rk3399-orangepi-u-boot.dtsi
+
+ROCKPRO64
+M:	Akash Gajjar <akash@openedev.com>
+M:	Jagan Teki <jagan@amarulasolutions.com>
+S:	Maintained
+F:	configs/rockpro64-rk3399_defconfig
+F:	arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
new file mode 100644
index 0000000000..3d0c7d0c6d
--- /dev/null
+++ b/configs/rockpro64-rk3399_defconfig
@@ -0,0 +1,58 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rockpro64.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-rockpro64"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_BAUDRATE=1500000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_ERRNO_STR=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [PATCH v3 12/13] rockchip: rk3399: Add Rock PI 4 support
  2019-04-25 17:34 ` [U-Boot] " Jagan Teki
@ 2019-04-25 17:34     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

Add initial support for Rock PI 4 board.

Specification
- Rockchip RK3399
- LPDDR4
- eMMC
- SD card slot
- RTL8211E 1Gbps
- HDMI In/Out, DP, MIPI DSI/CSI
- PCIe M.2
- USB 2.0, USB-3.0
- USB C Type

Commit details of rk3399-rock-pi-4.dts sync from Linux 5.1-rc2:
"arm64: dts: rockchip: add ROCK Pi 4 DTS support"
(sha1: 1b5715c602fda7b812af0e190eddcce2812e5417)

Signed-off-by: Akash Gajjar <akash-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org>
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
 arch/arm/dts/Makefile                     |   1 +
 arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi |   6 +
 arch/arm/dts/rk3399-rock-pi-4.dts         | 606 ++++++++++++++++++++++
 board/rockchip/evb_rk3399/MAINTAINERS     |   7 +
 configs/rock-pi-4-rk3399_defconfig        |  58 +++
 5 files changed, 678 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-rock-pi-4.dts
 create mode 100644 configs/rock-pi-4-rk3399_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 65ff42bf28..c96b302ae1 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -93,6 +93,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3399-puma-ddr1333.dtb \
 	rk3399-puma-ddr1600.dtb \
 	rk3399-puma-ddr1866.dtb \
+	rk3399-rock-pi-4.dtb \
 	rk3399-rock960.dtb \
 	rk3399-rockpro64.dtb \
 	rv1108-elgin-r1.dtb \
diff --git a/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi b/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
new file mode 100644
index 0000000000..7bddc3acdb
--- /dev/null
+++ b/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+ */
+
+#include "rk3399-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-rock-pi-4.dts b/arch/arm/dts/rk3399-rock-pi-4.dts
new file mode 100644
index 0000000000..4a543f2117
--- /dev/null
+++ b/arch/arm/dts/rk3399-rock-pi-4.dts
@@ -0,0 +1,606 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Akash Gajjar <Akash_Gajjar-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
+ * Copyright (c) 2019 Pragnesh Patel <Pragnesh_Patel-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+	model = "Radxa ROCK Pi 4";
+	compatible = "radxa,rockpi4", "rockchip,rk3399";
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	clkin_gmac: external-gmac-clock {
+		compatible = "fixed-clock";
+		clock-frequency = <125000000>;
+		clock-output-names = "clkin_gmac";
+		#clock-cells = <0>;
+	};
+
+	vcc12v_dcin: dc-12v {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc5v0_sys: vcc-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_pcie: vcc3v3-pcie-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pcie_pwr_en>;
+		regulator-name = "vcc3v3_pcie";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PD1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host_en>;
+		regulator-name = "vcc5v0_host";
+		regulator-always-on;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_typec: vcc5v0-typec-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_typec_en>;
+		regulator-name = "vcc5v0_typec";
+		regulator-always-on;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_lan: vcc3v3-phy-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_lan";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_log: vdd-log {
+		compatible = "pwm-regulator";
+		pwms = <&pwm2 0 25000 1>;
+		regulator-name = "vdd_log";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <1400000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+	status = "okay";
+};
+
+&gmac {
+	assigned-clocks = <&cru SCLK_RMII_SRC>;
+	assigned-clock-parents = <&clkin_gmac>;
+	clock_in_out = "input";
+	phy-supply = <&vcc_lan>;
+	phy-mode = "rgmii";
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_pins>;
+	snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+	snps,reset-active-low;
+	snps,reset-delays-us = <0 10000 50000>;
+	tx_delay = <0x28>;
+	rx_delay = <0x11>;
+	status = "okay";
+};
+
+&hdmi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&hdmi_cec>;
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	i2c-scl-rising-time-ns = <168>;
+	i2c-scl-falling-time-ns = <4>;
+	status = "okay";
+
+	rk808: pmic@1b {
+		compatible = "rockchip,rk808";
+		reg = <0x1b>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+		#clock-cells = <1>;
+		clock-output-names = "xin32k", "rk808-clkout2";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int_l>;
+		rockchip,system-power-controller;
+		wakeup-source;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc3v3_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc5v0_sys>;
+		vcc12-supply = <&vcc3v3_sys>;
+		vddio-supply = <&vcc_1v8>;
+
+		regulators {
+			vdd_center: DCDC_REG1 {
+				regulator-name = "vdd_center";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_l: DCDC_REG2 {
+				regulator-name = "vdd_cpu_l";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-name = "vcc_ddr";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_1v8: DCDC_REG4 {
+				regulator-name = "vcc_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc1v8_codec: LDO_REG1 {
+				regulator-name = "vcc1v8_codec";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc1v8_hdmi: LDO_REG2 {
+				regulator-name = "vcc1v8_hdmi";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca_1v8: LDO_REG3 {
+				regulator-name = "vcca_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc_sdio: LDO_REG4 {
+				regulator-name = "vcc_sdio";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcca3v0_codec: LDO_REG5 {
+				regulator-name = "vcca3v0_codec";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v5: LDO_REG6 {
+				regulator-name = "vcc_1v5";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1500000>;
+				};
+			};
+
+			vcc0v9_hdmi: LDO_REG7 {
+				regulator-name = "vcc0v9_hdmi";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v0: LDO_REG8 {
+				regulator-name = "vcc_3v0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcc_cam: SWITCH_REG1 {
+				regulator-name = "vcc_cam";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_mipi: SWITCH_REG2 {
+				regulator-name = "vcc_mipi";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+
+	vdd_cpu_b: regulator@40 {
+		compatible = "silergy,syr827";
+		reg = <0x40>;
+		fcs,suspend-voltage-selector = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vsel1_gpio>;
+		regulator-name = "vdd_cpu_b";
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-ramp-delay = <1000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_gpu: regulator@41 {
+		compatible = "silergy,syr828";
+		reg = <0x41>;
+		fcs,suspend-voltage-selector = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vsel2_gpio>;
+		regulator-name = "vdd_gpu";
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-ramp-delay = <1000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c1 {
+	i2c-scl-rising-time-ns = <300>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+};
+
+&i2c3 {
+	i2c-scl-rising-time-ns = <450>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+};
+
+&i2c4 {
+	i2c-scl-rising-time-ns = <600>;
+	i2c-scl-falling-time-ns = <20>;
+	status = "okay";
+};
+
+&i2s0 {
+	rockchip,playback-channels = <8>;
+	rockchip,capture-channels = <8>;
+	status = "okay";
+};
+
+&i2s1 {
+	rockchip,playback-channels = <2>;
+	rockchip,capture-channels = <2>;
+	status = "okay";
+};
+
+&i2s2 {
+	status = "okay";
+};
+
+&io_domains {
+	status = "okay";
+
+	bt656-supply = <&vcc_3v0>;
+	audio-supply = <&vcc_3v0>;
+	sdmmc-supply = <&vcc_sdio>;
+	gpio1830-supply = <&vcc_3v0>;
+};
+
+&pmu_io_domains {
+	status = "okay";
+
+	pmu1830-supply = <&vcc_3v0>;
+};
+
+&pinctrl {
+	pcie {
+		pcie_pwr_en: pcie-pwr-en {
+			rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		pmic_int_l: pmic-int-l {
+			rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		vsel1_gpio: vsel1-gpio {
+			rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		vsel2_gpio: vsel2-gpio {
+			rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	usb-typec {
+		vcc5v0_typec_en: vcc5v0-typec-en {
+			rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	usb2 {
+		vcc5v0_host_en: vcc5v0-host-en {
+			rockchip,pins = <4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&pwm2 {
+	status = "okay";
+};
+
+&saradc {
+	status = "okay";
+
+	vref-supply = <&vcc_1v8>;
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+	disable-wp;
+	max-frequency = <150000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_clk &sdmmc_cd &sdmmc_cmd &sdmmc_bus4>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	non-removable;
+	status = "okay";
+};
+
+&tcphy0 {
+	status = "okay";
+};
+
+&tcphy1 {
+	status = "okay";
+};
+
+&tsadc {
+	status = "okay";
+
+	/* tshut mode 0:CRU 1:GPIO */
+	rockchip,hw-tshut-mode = <1>;
+	/* tshut polarity 0:LOW 1:HIGH */
+	rockchip,hw-tshut-polarity = <1>;
+};
+
+&u2phy0 {
+	status = "okay";
+
+	u2phy0_otg: otg-port {
+		status = "okay";
+	};
+
+	u2phy0_host: host-port {
+		phy-supply = <&vcc5v0_host>;
+		status = "okay";
+	};
+};
+
+&u2phy1 {
+	status = "okay";
+
+	u2phy1_otg: otg-port {
+		status = "okay";
+	};
+
+	u2phy1_host: host-port {
+		phy-supply = <&vcc5v0_host>;
+		status = "okay";
+	};
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&usbdrd3_0 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_0 {
+	status = "okay";
+	dr_mode = "otg";
+};
+
+&usbdrd3_1 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+	status = "okay";
+	dr_mode = "host";
+};
+
+&vopb {
+	status = "okay";
+};
+
+&vopb_mmu {
+	status = "okay";
+};
+
+&vopl {
+	status = "okay";
+};
+
+&vopl_mmu {
+	status = "okay";
+};
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index 74a45adc72..b895182fec 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -25,6 +25,13 @@ F:	configs/orangepi-rk3399_defconfig
 F:	arch/arm/dts/rk3399-u-boot.dtsi
 F:	arch/arm/dts/rk3399-orangepi-u-boot.dtsi
 
+ROCK-PI-4
+M:	Akash Gajjar <akash-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org>
+M:	Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+S:	Maintained
+F:	configs/rock-pi-4-rk3399_defconfig
+F:	arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
+
 ROCKPRO64
 M:	Akash Gajjar <akash-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org>
 M:	Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig
new file mode 100644
index 0000000000..626cb7faea
--- /dev/null
+++ b/configs/rock-pi-4-rk3399_defconfig
@@ -0,0 +1,58 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock-pi-4.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-rock-pi-4"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_BAUDRATE=1500000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_ERRNO_STR=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 12/13] rockchip: rk3399: Add Rock PI 4 support
@ 2019-04-25 17:34     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

Add initial support for Rock PI 4 board.

Specification
- Rockchip RK3399
- LPDDR4
- eMMC
- SD card slot
- RTL8211E 1Gbps
- HDMI In/Out, DP, MIPI DSI/CSI
- PCIe M.2
- USB 2.0, USB-3.0
- USB C Type

Commit details of rk3399-rock-pi-4.dts sync from Linux 5.1-rc2:
"arm64: dts: rockchip: add ROCK Pi 4 DTS support"
(sha1: 1b5715c602fda7b812af0e190eddcce2812e5417)

Signed-off-by: Akash Gajjar <akash@openedev.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
 arch/arm/dts/Makefile                     |   1 +
 arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi |   6 +
 arch/arm/dts/rk3399-rock-pi-4.dts         | 606 ++++++++++++++++++++++
 board/rockchip/evb_rk3399/MAINTAINERS     |   7 +
 configs/rock-pi-4-rk3399_defconfig        |  58 +++
 5 files changed, 678 insertions(+)
 create mode 100644 arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3399-rock-pi-4.dts
 create mode 100644 configs/rock-pi-4-rk3399_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 65ff42bf28..c96b302ae1 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -93,6 +93,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 	rk3399-puma-ddr1333.dtb \
 	rk3399-puma-ddr1600.dtb \
 	rk3399-puma-ddr1866.dtb \
+	rk3399-rock-pi-4.dtb \
 	rk3399-rock960.dtb \
 	rk3399-rockpro64.dtb \
 	rv1108-elgin-r1.dtb \
diff --git a/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi b/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
new file mode 100644
index 0000000000..7bddc3acdb
--- /dev/null
+++ b/arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
+ */
+
+#include "rk3399-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-rock-pi-4.dts b/arch/arm/dts/rk3399-rock-pi-4.dts
new file mode 100644
index 0000000000..4a543f2117
--- /dev/null
+++ b/arch/arm/dts/rk3399-rock-pi-4.dts
@@ -0,0 +1,606 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Akash Gajjar <Akash_Gajjar@mentor.com>
+ * Copyright (c) 2019 Pragnesh Patel <Pragnesh_Patel@mentor.com>
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+	model = "Radxa ROCK Pi 4";
+	compatible = "radxa,rockpi4", "rockchip,rk3399";
+
+	chosen {
+		stdout-path = "serial2:1500000n8";
+	};
+
+	clkin_gmac: external-gmac-clock {
+		compatible = "fixed-clock";
+		clock-frequency = <125000000>;
+		clock-output-names = "clkin_gmac";
+		#clock-cells = <0>;
+	};
+
+	vcc12v_dcin: dc-12v {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc12v_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <12000000>;
+		regulator-max-microvolt = <12000000>;
+	};
+
+	vcc5v0_sys: vcc-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc12v_dcin>;
+	};
+
+	vcc3v3_pcie: vcc3v3-pcie-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pcie_pwr_en>;
+		regulator-name = "vcc3v3_pcie";
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc3v3_sys: vcc3v3-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc3v3_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_host: vcc5v0-host-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio4 RK_PD1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_host_en>;
+		regulator-name = "vcc5v0_host";
+		regulator-always-on;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_typec: vcc5v0-typec-regulator {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpio = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vcc5v0_typec_en>;
+		regulator-name = "vcc5v0_typec";
+		regulator-always-on;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_lan: vcc3v3-phy-regulator {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_lan";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_log: vdd-log {
+		compatible = "pwm-regulator";
+		pwms = <&pwm2 0 25000 1>;
+		regulator-name = "vdd_log";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <800000>;
+		regulator-max-microvolt = <1400000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&cpu_l0 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+	status = "okay";
+};
+
+&gmac {
+	assigned-clocks = <&cru SCLK_RMII_SRC>;
+	assigned-clock-parents = <&clkin_gmac>;
+	clock_in_out = "input";
+	phy-supply = <&vcc_lan>;
+	phy-mode = "rgmii";
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_pins>;
+	snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+	snps,reset-active-low;
+	snps,reset-delays-us = <0 10000 50000>;
+	tx_delay = <0x28>;
+	rx_delay = <0x11>;
+	status = "okay";
+};
+
+&hdmi {
+	pinctrl-names = "default";
+	pinctrl-0 = <&hdmi_cec>;
+	status = "okay";
+};
+
+&i2c0 {
+	clock-frequency = <400000>;
+	i2c-scl-rising-time-ns = <168>;
+	i2c-scl-falling-time-ns = <4>;
+	status = "okay";
+
+	rk808: pmic at 1b {
+		compatible = "rockchip,rk808";
+		reg = <0x1b>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+		#clock-cells = <1>;
+		clock-output-names = "xin32k", "rk808-clkout2";
+		pinctrl-names = "default";
+		pinctrl-0 = <&pmic_int_l>;
+		rockchip,system-power-controller;
+		wakeup-source;
+
+		vcc1-supply = <&vcc5v0_sys>;
+		vcc2-supply = <&vcc5v0_sys>;
+		vcc3-supply = <&vcc5v0_sys>;
+		vcc4-supply = <&vcc5v0_sys>;
+		vcc6-supply = <&vcc5v0_sys>;
+		vcc7-supply = <&vcc5v0_sys>;
+		vcc8-supply = <&vcc3v3_sys>;
+		vcc9-supply = <&vcc5v0_sys>;
+		vcc10-supply = <&vcc5v0_sys>;
+		vcc11-supply = <&vcc5v0_sys>;
+		vcc12-supply = <&vcc3v3_sys>;
+		vddio-supply = <&vcc_1v8>;
+
+		regulators {
+			vdd_center: DCDC_REG1 {
+				regulator-name = "vdd_center";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vdd_cpu_l: DCDC_REG2 {
+				regulator-name = "vdd_cpu_l";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <750000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-ramp-delay = <6001>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_ddr: DCDC_REG3 {
+				regulator-name = "vcc_ddr";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+				};
+			};
+
+			vcc_1v8: DCDC_REG4 {
+				regulator-name = "vcc_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc1v8_codec: LDO_REG1 {
+				regulator-name = "vcc1v8_codec";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc1v8_hdmi: LDO_REG2 {
+				regulator-name = "vcc1v8_hdmi";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcca_1v8: LDO_REG3 {
+				regulator-name = "vcca_1v8";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1800000>;
+				};
+			};
+
+			vcc_sdio: LDO_REG4 {
+				regulator-name = "vcc_sdio";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcca3v0_codec: LDO_REG5 {
+				regulator-name = "vcca3v0_codec";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_1v5: LDO_REG6 {
+				regulator-name = "vcc_1v5";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <1500000>;
+				regulator-max-microvolt = <1500000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <1500000>;
+				};
+			};
+
+			vcc0v9_hdmi: LDO_REG7 {
+				regulator-name = "vcc0v9_hdmi";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <900000>;
+				regulator-max-microvolt = <900000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_3v0: LDO_REG8 {
+				regulator-name = "vcc_3v0";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3000000>;
+				regulator-max-microvolt = <3000000>;
+				regulator-state-mem {
+					regulator-on-in-suspend;
+					regulator-suspend-microvolt = <3000000>;
+				};
+			};
+
+			vcc_cam: SWITCH_REG1 {
+				regulator-name = "vcc_cam";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+
+			vcc_mipi: SWITCH_REG2 {
+				regulator-name = "vcc_mipi";
+				regulator-always-on;
+				regulator-boot-on;
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-state-mem {
+					regulator-off-in-suspend;
+				};
+			};
+		};
+	};
+
+	vdd_cpu_b: regulator at 40 {
+		compatible = "silergy,syr827";
+		reg = <0x40>;
+		fcs,suspend-voltage-selector = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vsel1_gpio>;
+		regulator-name = "vdd_cpu_b";
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-ramp-delay = <1000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+
+	vdd_gpu: regulator at 41 {
+		compatible = "silergy,syr828";
+		reg = <0x41>;
+		fcs,suspend-voltage-selector = <1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&vsel2_gpio>;
+		regulator-name = "vdd_gpu";
+		regulator-min-microvolt = <712500>;
+		regulator-max-microvolt = <1500000>;
+		regulator-ramp-delay = <1000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vcc5v0_sys>;
+
+		regulator-state-mem {
+			regulator-off-in-suspend;
+		};
+	};
+};
+
+&i2c1 {
+	i2c-scl-rising-time-ns = <300>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+};
+
+&i2c3 {
+	i2c-scl-rising-time-ns = <450>;
+	i2c-scl-falling-time-ns = <15>;
+	status = "okay";
+};
+
+&i2c4 {
+	i2c-scl-rising-time-ns = <600>;
+	i2c-scl-falling-time-ns = <20>;
+	status = "okay";
+};
+
+&i2s0 {
+	rockchip,playback-channels = <8>;
+	rockchip,capture-channels = <8>;
+	status = "okay";
+};
+
+&i2s1 {
+	rockchip,playback-channels = <2>;
+	rockchip,capture-channels = <2>;
+	status = "okay";
+};
+
+&i2s2 {
+	status = "okay";
+};
+
+&io_domains {
+	status = "okay";
+
+	bt656-supply = <&vcc_3v0>;
+	audio-supply = <&vcc_3v0>;
+	sdmmc-supply = <&vcc_sdio>;
+	gpio1830-supply = <&vcc_3v0>;
+};
+
+&pmu_io_domains {
+	status = "okay";
+
+	pmu1830-supply = <&vcc_3v0>;
+};
+
+&pinctrl {
+	pcie {
+		pcie_pwr_en: pcie-pwr-en {
+			rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	pmic {
+		pmic_int_l: pmic-int-l {
+			rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		vsel1_gpio: vsel1-gpio {
+			rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		vsel2_gpio: vsel2-gpio {
+			rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
+	usb-typec {
+		vcc5v0_typec_en: vcc5v0-typec-en {
+			rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	usb2 {
+		vcc5v0_host_en: vcc5v0-host-en {
+			rockchip,pins = <4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&pwm2 {
+	status = "okay";
+};
+
+&saradc {
+	status = "okay";
+
+	vref-supply = <&vcc_1v8>;
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+	disable-wp;
+	max-frequency = <150000000>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc_clk &sdmmc_cd &sdmmc_cmd &sdmmc_bus4>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	mmc-hs400-1_8v;
+	mmc-hs400-enhanced-strobe;
+	non-removable;
+	status = "okay";
+};
+
+&tcphy0 {
+	status = "okay";
+};
+
+&tcphy1 {
+	status = "okay";
+};
+
+&tsadc {
+	status = "okay";
+
+	/* tshut mode 0:CRU 1:GPIO */
+	rockchip,hw-tshut-mode = <1>;
+	/* tshut polarity 0:LOW 1:HIGH */
+	rockchip,hw-tshut-polarity = <1>;
+};
+
+&u2phy0 {
+	status = "okay";
+
+	u2phy0_otg: otg-port {
+		status = "okay";
+	};
+
+	u2phy0_host: host-port {
+		phy-supply = <&vcc5v0_host>;
+		status = "okay";
+	};
+};
+
+&u2phy1 {
+	status = "okay";
+
+	u2phy1_otg: otg-port {
+		status = "okay";
+	};
+
+	u2phy1_host: host-port {
+		phy-supply = <&vcc5v0_host>;
+		status = "okay";
+	};
+};
+
+&uart2 {
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
+
+&usb_host1_ehci {
+	status = "okay";
+};
+
+&usb_host1_ohci {
+	status = "okay";
+};
+
+&usbdrd3_0 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_0 {
+	status = "okay";
+	dr_mode = "otg";
+};
+
+&usbdrd3_1 {
+	status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+	status = "okay";
+	dr_mode = "host";
+};
+
+&vopb {
+	status = "okay";
+};
+
+&vopb_mmu {
+	status = "okay";
+};
+
+&vopl {
+	status = "okay";
+};
+
+&vopl_mmu {
+	status = "okay";
+};
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index 74a45adc72..b895182fec 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -25,6 +25,13 @@ F:	configs/orangepi-rk3399_defconfig
 F:	arch/arm/dts/rk3399-u-boot.dtsi
 F:	arch/arm/dts/rk3399-orangepi-u-boot.dtsi
 
+ROCK-PI-4
+M:	Akash Gajjar <akash@openedev.com>
+M:	Jagan Teki <jagan@amarulasolutions.com>
+S:	Maintained
+F:	configs/rock-pi-4-rk3399_defconfig
+F:	arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi
+
 ROCKPRO64
 M:	Akash Gajjar <akash@openedev.com>
 M:	Jagan Teki <jagan@amarulasolutions.com>
diff --git a/configs/rock-pi-4-rk3399_defconfig b/configs/rock-pi-4-rk3399_defconfig
new file mode 100644
index 0000000000..626cb7faea
--- /dev/null
+++ b/configs/rock-pi-4-rk3399_defconfig
@@ -0,0 +1,58 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rock-pi-4.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-rock-pi-4"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_BAUDRATE=1500000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_USE_TINY_PRINTF=y
+CONFIG_ERRNO_STR=y
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [PATCH v3 13/13] doc: rockchip: Add global doc for rk3399 build/flash
  2019-04-25 17:34 ` [U-Boot] " Jagan Teki
@ 2019-04-25 17:34     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
	Jagan Teki, u-boot-0aAXYlwwYIKGBzrmiIFOJg

Since rockchip have an individual doc/README.rockchip, it would
be better to update the same instead of maintaining it separately
in board files.

So, add the documentation for rk3399
- procedure to build for Rockchip miniloader and
  U-Boot SPL options
- procedure to boot from SD for Rockchip miniloader and
  U-Boot SPL options
- Add boot logs of each option, so-that it would help for future
  boards porting

Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Reviewed-by: Philipp Tomsich <philipp.tomsich-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5@public.gmane.org>
---
 doc/README.rockchip | 209 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 208 insertions(+), 1 deletion(-)

diff --git a/doc/README.rockchip b/doc/README.rockchip
index ec10ebbc26..e8f6a2dfba 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -88,10 +88,68 @@ One RV3188 baord is supported:
 
 For example:
 
+1. To build RK3288 board:
+
    CROSS_COMPILE=arm-linux-gnueabi- make O=firefly firefly-rk3288_defconfig all
 
-(or you can use another cross compiler if you prefer)
+    (or you can use another cross compiler if you prefer)
+
+2. To build RK3399 board:
+
+   Option 1: Package the image with Rockchip miniloader:
+
+   - Compile U-Boot
+
+     => cd /path/to/u-boot
+     => make nanopi-neo4-rk3399_defconfig
+     => make
+     => make u-boot.itb
+
+   - Get the rkbin
+
+     => git clone https://github.com/rockchip-linux/rkbin.git
+
+   - Create trust.img
+
+     => cd /path/to/rkbin
+     => ./tools/trust_merger RKTRUST/RK3399TRUST.ini
+
+   - Create uboot.img
+
+     => cd /path/to/rkbin
+     => ./tools/loaderimage --pack --uboot /path/to/u-boot/u-boot-dtb.bin uboot.img
+
+   (Get trust.img and uboot.img)
 
+   Option 2: Package the image with SPL:
+
+   - We need the Python elftools.elf.elffile library for make_fit_atf.py to work
+
+     => sudo apt-get install python-pyelftools
+
+   - Export cross compiler path for aarch64
+
+   - Compile ATF
+
+     => git clone https://github.com/ARM-software/arm-trusted-firmware.git
+     => cd arm-trusted-firmware
+
+     (export cross compiler path for Cortex-M0 MCU likely arm-none-eabi-)
+     => make realclean
+     => make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399
+
+     (copy bl31.elf U-Boot root dir)
+     => cp build/rk3399/release/bl31/bl31.elf /path/to/u-boot
+
+   - Compile U-Boot
+
+     => cd /path/to/u-boot
+     => make orangepi-rk3399_defconfig
+     => make
+     => make u-boot.itb
+
+     (Get spl/u-boot-spl-dtb.bin, u-boot.itb images and some boards would get
+      spl/u-boot-spl.bin since it doesn't enable CONFIG_SPL_OF_CONTROL)
 
 Writing to the board with USB
 =============================
@@ -225,6 +283,153 @@ tools/mkimage -n rk3188 -T rksd -d spl/u-boot-spl.bin out
 truncate -s %2048 u-boot.bin
 cat u-boot.bin | split -b 512 --filter='openssl rc4 -K 7C4E0304550509072D2C7B38170D1711' >> out
 
+Booting from an SD card on RK3399
+=================================
+
+To write an image that boots from an SD card (assumed to be /dev/sdc):
+
+Option 1: Package the image with Rockchip miniloader:
+
+  - Create idbloader.img
+
+    => cd /path/to/u-boot
+    => ./tools/mkimage  -n rk3399 -T rksd -d /path/to/rkbin/bin/rk33/rk3399_ddr_800MHz_v1.20.bin idbloader.img
+    => cat /path/to/rkbin/bin/rk33/rk3399_miniloader_v1.19.bin >> idbloader.img
+
+  - Write idbloader.img at 64 sector
+
+    => sudo dd if=idbloader.img of=/dev/sdc seek=64
+
+  - Write trust.img at 24576
+
+    => sudo dd if=trust.img of=/dev/sdc seek=24576
+
+  - Write uboot.img at 16384 sector
+
+    => sudo dd if=uboot.img of=/dev/sdc seek=16384
+    => sync
+
+Put this SD (or micro-SD) card into your board and reset it. You should see
+something like:
+
+DDR Version 1.20 20190314
+In
+Channel 0: DDR3, 933MHz
+Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB
+no stride
+ch 0 ddrconfig = 0x101, ddrsize = 0x20
+pmugrf_os_reg[2] = 0x10006281, stride = 0x17
+OUT
+Boot1: 2019-03-14, version: 1.19
+CPUId = 0x0
+ChipType = 0x10, 239
+mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
+mmc: ERROR: Card did not respond to voltage select!
+emmc reinit
+mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
+mmc: ERROR: Card did not respond to voltage select!
+emmc reinit
+mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
+mmc: ERROR: Card did not respond to voltage select!
+SdmmcInit=2 1
+mmc0:cmd5,20
+SdmmcInit=0 0
+BootCapSize=0
+UserCapSize=60543MB
+FwPartOffset=2000 , 0
+StorageInit ok = 45266
+SecureMode = 0
+SecureInit read PBA: 0x4
+SecureInit read PBA: 0x404
+SecureInit read PBA: 0x804
+SecureInit read PBA: 0xc04
+SecureInit read PBA: 0x1004
+SecureInit read PBA: 0x1404
+SecureInit read PBA: 0x1804
+SecureInit read PBA: 0x1c04
+SecureInit ret = 0, SecureMode = 0
+atags_set_bootdev: ret:(0)
+GPT 0x3380ec0 signature is wrong
+recovery gpt...
+GPT 0x3380ec0 signature is wrong
+recovery gpt fail!
+LoadTrust Addr:0x4000
+No find bl30.bin
+Load uboot, ReadLba = 2000
+hdr 0000000003380880 + 0x0:0x88,0x41,0x3e,0x97,0xe6,0x61,0x54,0x23,0xe9,0x5a,0xd1,0x2b,0xdc,0x2f,0xf9,0x35,
+
+Load OK, addr=0x200000, size=0x9c9c0
+RunBL31 0x10000
+NOTICE:  BL31: v1.3(debug):370ab80
+NOTICE:  BL31: Built : 09:23:41, Mar  4 2019
+NOTICE:  BL31: Rockchip release version: v1.1
+INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
+INFO:    Using opteed sec cpu_context!
+INFO:    boot cpu mask: 0
+INFO:    plat_rockchip_pmu_init(1181): pd status 3e
+INFO:    BL31: Initializing runtime services
+INFO:    BL31: Initializing BL32
+INF [0x0] TEE-CORE:init_primary_helper:337: Initializing (1.1.0-195-g8f090d20 #6 Fri Dec  7 06:11:20 UTC 2018 aarch64)
+
+INF [0x0] TEE-CORE:init_primary_helper:338: Release version: 1.2
+
+INF [0x0] TEE-CORE:init_teecore:83: teecore inits done
+INFO:    BL31: Preparing for EL3 exit to normal world
+INFO:    Entry point address = 0x200000
+INFO:    SPSR = 0x3c9
+
+
+U-Boot 2019.04-rc4-00136-gfd121f9641-dirty (Apr 16 2019 - 14:02:47 +0530)
+
+Model: FriendlyARM NanoPi NEO4
+DRAM:  1022 MiB
+MMC:   dwmmc@fe310000: 2, dwmmc@fe320000: 1, sdhci@fe330000: 0
+Loading Environment from MMC... *** Warning - bad CRC, using default environment
+
+In:    serial@ff1a0000
+Out:   serial@ff1a0000
+Err:   serial@ff1a0000
+Model: FriendlyARM NanoPi NEO4
+Net:   eth0: ethernet@fe300000
+Hit any key to stop autoboot:  0
+=>
+
+Option 2: Package the image with SPL:
+
+  - Prefix rk3399 header to SPL image
+
+    => cd /path/to/u-boot
+    => ./tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl-dtb.bin out
+
+  - Write prefixed SPL at 64th sector
+
+    => sudo dd if=out of=/dev/sdc seek=64
+
+  - Write U-Boot proper at 16384 sector
+
+    => sudo dd if=u-boot.itb of=/dev/sdc seek=16384
+    => sync
+
+Put this SD (or micro-SD) card into your board and reset it. You should see
+something like:
+
+U-Boot SPL board init
+Trying to boot from MMC1
+
+
+U-Boot 2019.01-00004-g14db5ee998 (Mar 11 2019 - 13:18:41 +0530)
+
+Model: Orange Pi RK3399 Board
+DRAM:  2 GiB
+MMC:   dwmmc@fe310000: 2, dwmmc@fe320000: 1, sdhci@fe330000: 0
+Loading Environment from MMC... OK
+In:    serial@ff1a0000
+Out:   serial@ff1a0000
+Err:   serial@ff1a0000
+Model: Orange Pi RK3399 Board
+Net:   eth0: ethernet@fe300000
+Hit any key to stop autoboot:  0
+=>
 
 Using fastboot on rk3288
 ========================
@@ -385,5 +590,7 @@ There are some documents about partitions in the links below.
 http://rockchip.wikidot.com/partitions
 
 --
+Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
+11 Mar 2019
 Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
 24 June 2015
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 13/13] doc: rockchip: Add global doc for rk3399 build/flash
@ 2019-04-25 17:34     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-25 17:34 UTC (permalink / raw)
  To: u-boot

Since rockchip have an individual doc/README.rockchip, it would
be better to update the same instead of maintaining it separately
in board files.

So, add the documentation for rk3399
- procedure to build for Rockchip miniloader and
  U-Boot SPL options
- procedure to boot from SD for Rockchip miniloader and
  U-Boot SPL options
- Add boot logs of each option, so-that it would help for future
  boards porting

Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
---
 doc/README.rockchip | 209 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 208 insertions(+), 1 deletion(-)

diff --git a/doc/README.rockchip b/doc/README.rockchip
index ec10ebbc26..e8f6a2dfba 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -88,10 +88,68 @@ One RV3188 baord is supported:
 
 For example:
 
+1. To build RK3288 board:
+
    CROSS_COMPILE=arm-linux-gnueabi- make O=firefly firefly-rk3288_defconfig all
 
-(or you can use another cross compiler if you prefer)
+    (or you can use another cross compiler if you prefer)
+
+2. To build RK3399 board:
+
+   Option 1: Package the image with Rockchip miniloader:
+
+   - Compile U-Boot
+
+     => cd /path/to/u-boot
+     => make nanopi-neo4-rk3399_defconfig
+     => make
+     => make u-boot.itb
+
+   - Get the rkbin
+
+     => git clone https://github.com/rockchip-linux/rkbin.git
+
+   - Create trust.img
+
+     => cd /path/to/rkbin
+     => ./tools/trust_merger RKTRUST/RK3399TRUST.ini
+
+   - Create uboot.img
+
+     => cd /path/to/rkbin
+     => ./tools/loaderimage --pack --uboot /path/to/u-boot/u-boot-dtb.bin uboot.img
+
+   (Get trust.img and uboot.img)
 
+   Option 2: Package the image with SPL:
+
+   - We need the Python elftools.elf.elffile library for make_fit_atf.py to work
+
+     => sudo apt-get install python-pyelftools
+
+   - Export cross compiler path for aarch64
+
+   - Compile ATF
+
+     => git clone https://github.com/ARM-software/arm-trusted-firmware.git
+     => cd arm-trusted-firmware
+
+     (export cross compiler path for Cortex-M0 MCU likely arm-none-eabi-)
+     => make realclean
+     => make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399
+
+     (copy bl31.elf U-Boot root dir)
+     => cp build/rk3399/release/bl31/bl31.elf /path/to/u-boot
+
+   - Compile U-Boot
+
+     => cd /path/to/u-boot
+     => make orangepi-rk3399_defconfig
+     => make
+     => make u-boot.itb
+
+     (Get spl/u-boot-spl-dtb.bin, u-boot.itb images and some boards would get
+      spl/u-boot-spl.bin since it doesn't enable CONFIG_SPL_OF_CONTROL)
 
 Writing to the board with USB
 =============================
@@ -225,6 +283,153 @@ tools/mkimage -n rk3188 -T rksd -d spl/u-boot-spl.bin out
 truncate -s %2048 u-boot.bin
 cat u-boot.bin | split -b 512 --filter='openssl rc4 -K 7C4E0304550509072D2C7B38170D1711' >> out
 
+Booting from an SD card on RK3399
+=================================
+
+To write an image that boots from an SD card (assumed to be /dev/sdc):
+
+Option 1: Package the image with Rockchip miniloader:
+
+  - Create idbloader.img
+
+    => cd /path/to/u-boot
+    => ./tools/mkimage  -n rk3399 -T rksd -d /path/to/rkbin/bin/rk33/rk3399_ddr_800MHz_v1.20.bin idbloader.img
+    => cat /path/to/rkbin/bin/rk33/rk3399_miniloader_v1.19.bin >> idbloader.img
+
+  - Write idbloader.img at 64 sector
+
+    => sudo dd if=idbloader.img of=/dev/sdc seek=64
+
+  - Write trust.img at 24576
+
+    => sudo dd if=trust.img of=/dev/sdc seek=24576
+
+  - Write uboot.img at 16384 sector
+
+    => sudo dd if=uboot.img of=/dev/sdc seek=16384
+    => sync
+
+Put this SD (or micro-SD) card into your board and reset it. You should see
+something like:
+
+DDR Version 1.20 20190314
+In
+Channel 0: DDR3, 933MHz
+Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB
+no stride
+ch 0 ddrconfig = 0x101, ddrsize = 0x20
+pmugrf_os_reg[2] = 0x10006281, stride = 0x17
+OUT
+Boot1: 2019-03-14, version: 1.19
+CPUId = 0x0
+ChipType = 0x10, 239
+mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
+mmc: ERROR: Card did not respond to voltage select!
+emmc reinit
+mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
+mmc: ERROR: Card did not respond to voltage select!
+emmc reinit
+mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
+mmc: ERROR: Card did not respond to voltage select!
+SdmmcInit=2 1
+mmc0:cmd5,20
+SdmmcInit=0 0
+BootCapSize=0
+UserCapSize=60543MB
+FwPartOffset=2000 , 0
+StorageInit ok = 45266
+SecureMode = 0
+SecureInit read PBA: 0x4
+SecureInit read PBA: 0x404
+SecureInit read PBA: 0x804
+SecureInit read PBA: 0xc04
+SecureInit read PBA: 0x1004
+SecureInit read PBA: 0x1404
+SecureInit read PBA: 0x1804
+SecureInit read PBA: 0x1c04
+SecureInit ret = 0, SecureMode = 0
+atags_set_bootdev: ret:(0)
+GPT 0x3380ec0 signature is wrong
+recovery gpt...
+GPT 0x3380ec0 signature is wrong
+recovery gpt fail!
+LoadTrust Addr:0x4000
+No find bl30.bin
+Load uboot, ReadLba = 2000
+hdr 0000000003380880 + 0x0:0x88,0x41,0x3e,0x97,0xe6,0x61,0x54,0x23,0xe9,0x5a,0xd1,0x2b,0xdc,0x2f,0xf9,0x35,
+
+Load OK, addr=0x200000, size=0x9c9c0
+RunBL31 0x10000
+NOTICE:  BL31: v1.3(debug):370ab80
+NOTICE:  BL31: Built : 09:23:41, Mar  4 2019
+NOTICE:  BL31: Rockchip release version: v1.1
+INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
+INFO:    Using opteed sec cpu_context!
+INFO:    boot cpu mask: 0
+INFO:    plat_rockchip_pmu_init(1181): pd status 3e
+INFO:    BL31: Initializing runtime services
+INFO:    BL31: Initializing BL32
+INF [0x0] TEE-CORE:init_primary_helper:337: Initializing (1.1.0-195-g8f090d20 #6 Fri Dec  7 06:11:20 UTC 2018 aarch64)
+
+INF [0x0] TEE-CORE:init_primary_helper:338: Release version: 1.2
+
+INF [0x0] TEE-CORE:init_teecore:83: teecore inits done
+INFO:    BL31: Preparing for EL3 exit to normal world
+INFO:    Entry point address = 0x200000
+INFO:    SPSR = 0x3c9
+
+
+U-Boot 2019.04-rc4-00136-gfd121f9641-dirty (Apr 16 2019 - 14:02:47 +0530)
+
+Model: FriendlyARM NanoPi NEO4
+DRAM:  1022 MiB
+MMC:   dwmmc at fe310000: 2, dwmmc at fe320000: 1, sdhci at fe330000: 0
+Loading Environment from MMC... *** Warning - bad CRC, using default environment
+
+In:    serial at ff1a0000
+Out:   serial at ff1a0000
+Err:   serial at ff1a0000
+Model: FriendlyARM NanoPi NEO4
+Net:   eth0: ethernet at fe300000
+Hit any key to stop autoboot:  0
+=>
+
+Option 2: Package the image with SPL:
+
+  - Prefix rk3399 header to SPL image
+
+    => cd /path/to/u-boot
+    => ./tools/mkimage -n rk3399 -T rksd -d spl/u-boot-spl-dtb.bin out
+
+  - Write prefixed SPL at 64th sector
+
+    => sudo dd if=out of=/dev/sdc seek=64
+
+  - Write U-Boot proper at 16384 sector
+
+    => sudo dd if=u-boot.itb of=/dev/sdc seek=16384
+    => sync
+
+Put this SD (or micro-SD) card into your board and reset it. You should see
+something like:
+
+U-Boot SPL board init
+Trying to boot from MMC1
+
+
+U-Boot 2019.01-00004-g14db5ee998 (Mar 11 2019 - 13:18:41 +0530)
+
+Model: Orange Pi RK3399 Board
+DRAM:  2 GiB
+MMC:   dwmmc at fe310000: 2, dwmmc at fe320000: 1, sdhci at fe330000: 0
+Loading Environment from MMC... OK
+In:    serial at ff1a0000
+Out:   serial at ff1a0000
+Err:   serial at ff1a0000
+Model: Orange Pi RK3399 Board
+Net:   eth0: ethernet at fe300000
+Hit any key to stop autoboot:  0
+=>
 
 Using fastboot on rk3288
 ========================
@@ -385,5 +590,7 @@ There are some documents about partitions in the links below.
 http://rockchip.wikidot.com/partitions
 
 --
+Jagan Teki <jagan@amarulasolutions.com>
+11 Mar 2019
 Simon Glass <sjg@chromium.org>
 24 June 2015
-- 
2.18.0.321.gffc6fa0e3

^ permalink raw reply related	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 03/13] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi
  2019-04-25 17:34     ` [U-Boot] " Jagan Teki
@ 2019-04-26 13:21         ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 13:21 UTC (permalink / raw)
  To: Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: Paul Kocialkowski,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-amarula,
	U-Boot-Denx

On Thu, Apr 25, 2019 at 11:04 PM Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>
> u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
> which is U-Boot specific devicetrees binding.
>
> Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
> bindings will move it future based on the requirement.
>
> This would help to sync the devicetrees from Linux whenever required
> instead of adding specific nodes.
>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> Reviewed-by: Paul Kocialkowski <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
> ---
>  arch/arm/dts/rk3399-evb.dts     | 1 -
>  arch/arm/dts/rk3399-firefly.dts | 1 -
>  arch/arm/dts/rk3399-puma.dtsi   | 1 -
>  arch/arm/dts/rk3399-u-boot.dtsi | 8 ++++++++
>  4 files changed, 8 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi
>
> diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
> index ce004d0d18..9162f3dd50 100644
> --- a/arch/arm/dts/rk3399-evb.dts
> +++ b/arch/arm/dts/rk3399-evb.dts
> @@ -155,7 +155,6 @@
>  };
>
>  &sdmmc {
> -       u-boot,dm-pre-reloc;
>         bus-width = <4>;
>         status = "okay";
>  };
> diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts
> index f90e7e88db..46f2ffaf8d 100644
> --- a/arch/arm/dts/rk3399-firefly.dts
> +++ b/arch/arm/dts/rk3399-firefly.dts
> @@ -592,7 +592,6 @@
>  };
>
>  &sdmmc {
> -       u-boot,dm-pre-reloc;
>         bus-width = <4>;
>         status = "okay";
>  };
> diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
> index 8304f67192..9049694243 100644
> --- a/arch/arm/dts/rk3399-puma.dtsi
> +++ b/arch/arm/dts/rk3399-puma.dtsi
> @@ -492,7 +492,6 @@
>  };
>
>  &sdmmc {
> -       u-boot,dm-pre-reloc;

We need to explicitly include rk3399-u-boot.dtsi to these files since
the SoC name is rockchip, I'm sending other series for these changes.
and I have send v3.1 patches for only this change [1] and rest
unchanged.

Sorry for not noticing before.

[1] https://patchwork.ozlabs.org/patch/1091534/

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 03/13] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi
@ 2019-04-26 13:21         ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 13:21 UTC (permalink / raw)
  To: u-boot

On Thu, Apr 25, 2019 at 11:04 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
> which is U-Boot specific devicetrees binding.
>
> Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
> bindings will move it future based on the requirement.
>
> This would help to sync the devicetrees from Linux whenever required
> instead of adding specific nodes.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
>  arch/arm/dts/rk3399-evb.dts     | 1 -
>  arch/arm/dts/rk3399-firefly.dts | 1 -
>  arch/arm/dts/rk3399-puma.dtsi   | 1 -
>  arch/arm/dts/rk3399-u-boot.dtsi | 8 ++++++++
>  4 files changed, 8 insertions(+), 3 deletions(-)
>  create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi
>
> diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
> index ce004d0d18..9162f3dd50 100644
> --- a/arch/arm/dts/rk3399-evb.dts
> +++ b/arch/arm/dts/rk3399-evb.dts
> @@ -155,7 +155,6 @@
>  };
>
>  &sdmmc {
> -       u-boot,dm-pre-reloc;
>         bus-width = <4>;
>         status = "okay";
>  };
> diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts
> index f90e7e88db..46f2ffaf8d 100644
> --- a/arch/arm/dts/rk3399-firefly.dts
> +++ b/arch/arm/dts/rk3399-firefly.dts
> @@ -592,7 +592,6 @@
>  };
>
>  &sdmmc {
> -       u-boot,dm-pre-reloc;
>         bus-width = <4>;
>         status = "okay";
>  };
> diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
> index 8304f67192..9049694243 100644
> --- a/arch/arm/dts/rk3399-puma.dtsi
> +++ b/arch/arm/dts/rk3399-puma.dtsi
> @@ -492,7 +492,6 @@
>  };
>
>  &sdmmc {
> -       u-boot,dm-pre-reloc;

We need to explicitly include rk3399-u-boot.dtsi to these files since
the SoC name is rockchip, I'm sending other series for these changes.
and I have send v3.1 patches for only this change [1] and rest
unchanged.

Sorry for not noticing before.

[1] https://patchwork.ozlabs.org/patch/1091534/

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 03/13] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi
  2019-04-26 13:21         ` [U-Boot] " Jagan Teki
@ 2019-04-26 13:33           ` Paul Kocialkowski
  -1 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 13:33 UTC (permalink / raw)
  To: Jagan Teki, Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: linux-rockchip, linux-amarula, U-Boot-Denx

Hi,

On Fri, 2019-04-26 at 18:51 +0530, Jagan Teki wrote:
> On Thu, Apr 25, 2019 at 11:04 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
> > which is U-Boot specific devicetrees binding.
> > 
> > Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
> > bindings will move it future based on the requirement.
> > 
> > This would help to sync the devicetrees from Linux whenever required
> > instead of adding specific nodes.
> > 
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > ---
> >  arch/arm/dts/rk3399-evb.dts     | 1 -
> >  arch/arm/dts/rk3399-firefly.dts | 1 -
> >  arch/arm/dts/rk3399-puma.dtsi   | 1 -
> >  arch/arm/dts/rk3399-u-boot.dtsi | 8 ++++++++
> >  4 files changed, 8 insertions(+), 3 deletions(-)
> >  create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi
> > 
> > diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
> > index ce004d0d18..9162f3dd50 100644
> > --- a/arch/arm/dts/rk3399-evb.dts
> > +++ b/arch/arm/dts/rk3399-evb.dts
> > @@ -155,7 +155,6 @@
> >  };
> > 
> >  &sdmmc {
> > -       u-boot,dm-pre-reloc;
> >         bus-width = <4>;
> >         status = "okay";
> >  };
> > diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts
> > index f90e7e88db..46f2ffaf8d 100644
> > --- a/arch/arm/dts/rk3399-firefly.dts
> > +++ b/arch/arm/dts/rk3399-firefly.dts
> > @@ -592,7 +592,6 @@
> >  };
> > 
> >  &sdmmc {
> > -       u-boot,dm-pre-reloc;
> >         bus-width = <4>;
> >         status = "okay";
> >  };
> > diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
> > index 8304f67192..9049694243 100644
> > --- a/arch/arm/dts/rk3399-puma.dtsi
> > +++ b/arch/arm/dts/rk3399-puma.dtsi
> > @@ -492,7 +492,6 @@
> >  };
> > 
> >  &sdmmc {
> > -       u-boot,dm-pre-reloc;
> 
> We need to explicitly include rk3399-u-boot.dtsi to these files since
> the SoC name is rockchip, I'm sending other series for these changes.
> and I have send v3.1 patches for only this change [1] and rest
> unchanged.

Does this mean that the rk3399-u-boot.dtsi file won't be auto-included
from the boards dtsi? If so, we should probably create -u-boot.dtsi
files for each device, to include rk3399-u-boot.dtsi.

Cheers,

Paul

> Sorry for not noticing before.
> 
> [1] https://patchwork.ozlabs.org/patch/1091534/
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 03/13] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi
@ 2019-04-26 13:33           ` Paul Kocialkowski
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 13:33 UTC (permalink / raw)
  To: u-boot

Hi,

On Fri, 2019-04-26 at 18:51 +0530, Jagan Teki wrote:
> On Thu, Apr 25, 2019 at 11:04 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> > u-boot,dm-pre-reloc is required for SDMMC booted rk3399 boards and
> > which is U-Boot specific devicetrees binding.
> > 
> > Move it on global rk3399-u-boot.dtsi file and rest of the U-Boot
> > bindings will move it future based on the requirement.
> > 
> > This would help to sync the devicetrees from Linux whenever required
> > instead of adding specific nodes.
> > 
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > ---
> >  arch/arm/dts/rk3399-evb.dts     | 1 -
> >  arch/arm/dts/rk3399-firefly.dts | 1 -
> >  arch/arm/dts/rk3399-puma.dtsi   | 1 -
> >  arch/arm/dts/rk3399-u-boot.dtsi | 8 ++++++++
> >  4 files changed, 8 insertions(+), 3 deletions(-)
> >  create mode 100644 arch/arm/dts/rk3399-u-boot.dtsi
> > 
> > diff --git a/arch/arm/dts/rk3399-evb.dts b/arch/arm/dts/rk3399-evb.dts
> > index ce004d0d18..9162f3dd50 100644
> > --- a/arch/arm/dts/rk3399-evb.dts
> > +++ b/arch/arm/dts/rk3399-evb.dts
> > @@ -155,7 +155,6 @@
> >  };
> > 
> >  &sdmmc {
> > -       u-boot,dm-pre-reloc;
> >         bus-width = <4>;
> >         status = "okay";
> >  };
> > diff --git a/arch/arm/dts/rk3399-firefly.dts b/arch/arm/dts/rk3399-firefly.dts
> > index f90e7e88db..46f2ffaf8d 100644
> > --- a/arch/arm/dts/rk3399-firefly.dts
> > +++ b/arch/arm/dts/rk3399-firefly.dts
> > @@ -592,7 +592,6 @@
> >  };
> > 
> >  &sdmmc {
> > -       u-boot,dm-pre-reloc;
> >         bus-width = <4>;
> >         status = "okay";
> >  };
> > diff --git a/arch/arm/dts/rk3399-puma.dtsi b/arch/arm/dts/rk3399-puma.dtsi
> > index 8304f67192..9049694243 100644
> > --- a/arch/arm/dts/rk3399-puma.dtsi
> > +++ b/arch/arm/dts/rk3399-puma.dtsi
> > @@ -492,7 +492,6 @@
> >  };
> > 
> >  &sdmmc {
> > -       u-boot,dm-pre-reloc;
> 
> We need to explicitly include rk3399-u-boot.dtsi to these files since
> the SoC name is rockchip, I'm sending other series for these changes.
> and I have send v3.1 patches for only this change [1] and rest
> unchanged.

Does this mean that the rk3399-u-boot.dtsi file won't be auto-included
from the boards dtsi? If so, we should probably create -u-boot.dtsi
files for each device, to include rk3399-u-boot.dtsi.

Cheers,

Paul

> Sorry for not noticing before.
> 
> [1] https://patchwork.ozlabs.org/patch/1091534/
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-25 17:34     ` [U-Boot] " Jagan Teki
@ 2019-04-26 14:17       ` Paul Kocialkowski
  -1 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 14:17 UTC (permalink / raw)
  To: Jagan Teki, Simon Glass, Philipp Tomsich, Kever Yang, Akash Gajjar
  Cc: linux-rockchip, linux-amarula, u-boot

Hi,

On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> Add initial support for Orangepi RK3399 board.
> 
> Specification
> - Rockchip RK3399
> - 2GB/4GB DDR3
> - 16GB eMMC
> - SD card slot

Looks like you're missing u-boot,dm-pre-reloc to have it working, which
will need to be introduced when moving to rk3399-u-boot.dtsi.

Cheers,

Paul

> - RTL8211E 1Gbps
> - AP6356S WiFI/BT
> - HDMI In/Out, DP, MIPI DSI/CSI
> - Mini PCIe
> - Sensors, Keys etc
> - DC12V-2A and DC5V-2A
> 
> Commit details about Linux DTS sync:
> "arm64: dts: rockchip: Add support for the Orange Pi RK3399"
> (sha1: d3e71487a790979057c0fdbf32f85033639c16e6)
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
>  arch/arm/dts/Makefile                    |   1 +
>  arch/arm/dts/rk3399-orangepi-u-boot.dtsi |   7 +
>  arch/arm/dts/rk3399-orangepi.dts         | 771 +++++++++++++++++++++++
>  board/rockchip/evb_rk3399/MAINTAINERS    |   7 +
>  configs/orangepi-rk3399_defconfig        |  58 ++
>  5 files changed, 844 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-orangepi-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-orangepi.dts
>  create mode 100644 configs/orangepi-rk3399_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 0e2ffdb87f..6d55b0caf8 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -87,6 +87,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>  	rk3399-evb.dtb \
>  	rk3399-firefly.dtb \
>  	rk3399-gru-bob.dtb \
> +	rk3399-orangepi.dtb \
>  	rk3399-puma-ddr1333.dtb \
>  	rk3399-puma-ddr1600.dtb \
>  	rk3399-puma-ddr1866.dtb \
> diff --git a/arch/arm/dts/rk3399-orangepi-u-boot.dtsi b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
> new file mode 100644
> index 0000000000..236b61d78d
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-ddr3-1333.dtsi"
> diff --git a/arch/arm/dts/rk3399-orangepi.dts b/arch/arm/dts/rk3399-orangepi.dts
> new file mode 100644
> index 0000000000..cf37b96a6b
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-orangepi.dts
> @@ -0,0 +1,771 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "dt-bindings/pwm/pwm.h"
> +#include "dt-bindings/input/input.h"
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> +	model = "Orange Pi RK3399 Board";
> +	compatible = "rockchip,rk3399-orangepi", "rockchip,rk3399";
> +
> +	chosen {
> +		stdout-path = "serial2:1500000n8";
> +	};
> +
> +	clkin_gmac: external-gmac-clock {
> +		compatible = "fixed-clock";
> +		clock-frequency = <125000000>;
> +		clock-output-names = "clkin_gmac";
> +		#clock-cells = <0>;
> +	};
> +
> +	adc-keys {
> +		compatible = "adc-keys";
> +		io-channels = <&saradc 1>;
> +		io-channel-names = "buttons";
> +		keyup-threshold-microvolt = <1800000>;
> +		poll-interval = <100>;
> +
> +		button-up {
> +			label = "Volume Up";
> +			linux,code = <KEY_VOLUMEUP>;
> +			press-threshold-microvolt = <100000>;
> +		};
> +
> +		button-down {
> +			label = "Volume Down";
> +			linux,code = <KEY_VOLUMEDOWN>;
> +			press-threshold-microvolt = <300000>;
> +		};
> +
> +		back {
> +			label = "Back";
> +			linux,code = <KEY_BACK>;
> +			press-threshold-microvolt = <985000>;
> +		};
> +
> +		menu {
> +			label = "Menu";
> +			linux,code = <KEY_MENU>;
> +			press-threshold-microvolt = <1314000>;
> +		};
> +	};
> +
> +	dc_12v: dc-12v {
> +		compatible = "regulator-fixed";
> +		regulator-name = "dc_12v";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <12000000>;
> +		regulator-max-microvolt = <12000000>;
> +	};
> +
> +	keys: gpio-keys {
> +		compatible = "gpio-keys";
> +		autorepeat;
> +
> +		power {
> +			debounce-interval = <100>;
> +			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
> +			label = "GPIO Power";
> +			linux,code = <KEY_POWER>;
> +			linux,input-type = <1>;
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pwr_btn>;
> +			wakeup-source;
> +		};
> +	};
> +
> +	sdio_pwrseq: sdio-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		clocks = <&rk808 1>;
> +		clock-names = "ext_clock";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_reg_on_h>;
> +		reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
> +	};
> +
> +	/* switched by pmic_sleep */
> +	vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc1v8_s3";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		vin-supply = <&vcc_1v8>;
> +	};
> +
> +	vcc3v0_sd: vcc3v0-sd {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&sdmmc0_pwr_h>;
> +		regulator-boot-on;
> +		regulator-max-microvolt = <3000000>;
> +		regulator-min-microvolt = <3000000>;
> +		regulator-name = "vcc3v0_sd";
> +		vin-supply = <&vcc3v3_sys>;
> +	};
> +
> +	vcc3v3_sys: vcc3v3-sys {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc3v3_sys";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vcc_sys>;
> +	};
> +
> +	vcc5v0_host: vcc5v0-host-regulator {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio4 RK_PD1 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vcc5v0_host_en>;
> +		regulator-name = "vcc5v0_host";
> +		regulator-always-on;
> +		vin-supply = <&vcc_sys>;
> +	};
> +
> +	vcc5v0_typec0: vcc5v0-typec0-regulator {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vcc5v0_typec0_en>;
> +		regulator-name = "vcc5v0_typec0";
> +		vin-supply = <&vcc_sys>;
> +	};
> +
> +	vcc_sys: vcc-sys {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_sys";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&dc_12v>;
> +	};
> +
> +	vdd_log: vdd-log {
> +		compatible = "pwm-regulator";
> +		pwms = <&pwm2 0 25000 1>;
> +		regulator-name = "vdd_log";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <800000>;
> +		regulator-max-microvolt = <1400000>;
> +		vin-supply = <&vcc_sys>;
> +	};
> +};
> +
> +&cpu_l0 {
> +	cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l1 {
> +	cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l2 {
> +	cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l3 {
> +	cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_b0 {
> +	cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&cpu_b1 {
> +	cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&emmc_phy {
> +	status = "okay";
> +};
> +
> +&gmac {
> +	assigned-clocks = <&cru SCLK_RMII_SRC>;
> +	assigned-clock-parents = <&clkin_gmac>;
> +	clock_in_out = "input";
> +	phy-supply = <&vcc3v3_s3>;
> +	phy-mode = "rgmii";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&rgmii_pins>;
> +	snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
> +	snps,reset-active-low;
> +	snps,reset-delays-us = <0 10000 50000>;
> +	tx_delay = <0x28>;
> +	rx_delay = <0x11>;
> +	status = "okay";
> +};
> +
> +&gpu {
> +	mali-supply = <&vdd_gpu>;
> +	status = "okay";
> +};
> +
> +&hdmi {
> +	ddc-i2c-bus = <&i2c3>;
> +	status = "okay";
> +};
> +
> +&hdmi_sound {
> +	status = "okay";
> +};
> +
> +&i2c0 {
> +	clock-frequency = <400000>;
> +	i2c-scl-rising-time-ns = <168>;
> +	i2c-scl-falling-time-ns = <4>;
> +	status = "okay";
> +
> +	rk808: pmic@1b {
> +		compatible = "rockchip,rk808";
> +		reg = <0x1b>;
> +		interrupt-parent = <&gpio1>;
> +		interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
> +		#clock-cells = <1>;
> +		clock-output-names = "rtc_clko_soc", "rtc_clko_wifi";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pmic_int_l>;
> +		rockchip,system-power-controller;
> +		wakeup-source;
> +
> +		vcc1-supply = <&vcc3v3_sys>;
> +		vcc2-supply = <&vcc3v3_sys>;
> +		vcc3-supply = <&vcc3v3_sys>;
> +		vcc4-supply = <&vcc3v3_sys>;
> +		vcc6-supply = <&vcc3v3_sys>;
> +		vcc7-supply = <&vcc3v3_sys>;
> +		vcc8-supply = <&vcc3v3_sys>;
> +		vcc9-supply = <&vcc3v3_sys>;
> +		vcc10-supply = <&vcc3v3_sys>;
> +		vcc11-supply = <&vcc3v3_sys>;
> +		vcc12-supply = <&vcc3v3_sys>;
> +		vddio-supply = <&vcc_3v0>;
> +
> +		regulators {
> +			vdd_center: DCDC_REG1 {
> +				regulator-name = "vdd_center";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <700000>;
> +				regulator-max-microvolt = <1500000>;
> +				regulator-ramp-delay = <6001>;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_cpu_l: DCDC_REG2 {
> +				regulator-name = "vdd_cpu_l";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <700000>;
> +				regulator-max-microvolt = <1500000>;
> +				regulator-ramp-delay = <6001>;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_ddr: DCDC_REG3 {
> +				regulator-name = "vcc_ddr";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v8: DCDC_REG4 {
> +				regulator-name = "vcc_1v8";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			vcc1v8_dvp: LDO_REG1 {
> +				regulator-name = "vcc1v8_dvp";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3400000>;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc3v0_tp: LDO_REG2 {
> +				regulator-name = "vcc3v0_tp";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3400000>;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc1v8_pmupll: LDO_REG3 {
> +				regulator-name = "vcc1v8_pmupll";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <2500000>;
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			vcc_sdio: LDO_REG4 {
> +				regulator-name = "vcc_sdio";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3400000>;
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <3000000>;
> +				};
> +			};
> +
> +			vcca3v0_codec: LDO_REG5 {
> +				regulator-name = "vcca3v0_codec";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3400000>;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v5: LDO_REG6 {
> +				regulator-name = "vcc_1v5";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <2500000>;
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <1500000>;
> +				};
> +			};
> +
> +			vcca1v8_codec: LDO_REG7 {
> +				regulator-name = "vcca1v8_codec";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <2500000>;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_3v0: LDO_REG8 {
> +				regulator-name = "vcc_3v0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3400000>;
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <3000000>;
> +				};
> +			};
> +
> +			vcc3v3_s3: SWITCH_REG1 {
> +				regulator-name = "vcc3v3_s3";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc3v3_s0: SWITCH_REG2 {
> +				regulator-name = "vcc3v3_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +		};
> +	};
> +
> +	vdd_cpu_b: regulator@40 {
> +		compatible = "silergy,syr827";
> +		reg = <0x40>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_cpu_b";
> +		regulator-min-microvolt = <712500>;
> +		regulator-max-microvolt = <1500000>;
> +		regulator-ramp-delay = <1000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +		vin-supply = <&vcc3v3_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vdd_gpu: regulator@41 {
> +		compatible = "silergy,syr828";
> +		reg = <0x41>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_gpu";
> +		regulator-min-microvolt = <712500>;
> +		regulator-max-microvolt = <1500000>;
> +		regulator-ramp-delay = <1000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +		vin-supply = <&vcc3v3_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +};
> +
> +&i2c1 {
> +	i2c-scl-rising-time-ns = <450>;
> +	i2c-scl-falling-time-ns = <15>;
> +	status = "okay";
> +};
> +
> +&i2c3 {
> +	i2c-scl-rising-time-ns = <450>;
> +	i2c-scl-falling-time-ns = <15>;
> +	status = "okay";
> +};
> +
> +&i2c4 {
> +	clock-frequency = <400000>;
> +	i2c-scl-rising-time-ns = <450>;
> +	i2c-scl-falling-time-ns = <15>;
> +	status = "okay";
> +
> +	ak09911@c {
> +		compatible = "asahi-kasei,ak09911";
> +		reg = <0x0c>;
> +		vdd-supply = <&vcc3v3_s3>;
> +	};
> +
> +	mpu6500@68 {
> +		compatible = "invensense,mpu6500";
> +		reg = <0x68>;
> +		interrupt-parent = <&gpio1>;
> +		interrupts = <RK_PC6 IRQ_TYPE_EDGE_RISING>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&gsensor_int_l>;
> +		vddio-supply = <&vcc3v3_s3>;
> +	};
> +
> +	lsm6ds3@6a {
> +		compatible = "st,lsm6ds3";
> +		reg = <0x6a>;
> +		interrupt-parent = <&gpio1>;
> +		interrupts = <RK_PD0 IRQ_TYPE_EDGE_RISING>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&gyr_int_l>;
> +		vdd-supply = <&vcc3v3_s3>;
> +		vddio-supply = <&vcc3v3_s3>;
> +	};
> +
> +	cm32181@10 {
> +		compatible = "capella,cm32181";
> +		reg = <0x10>;
> +		interrupt-parent = <&gpio4>;
> +		interrupts = <RK_PD0 IRQ_TYPE_EDGE_RISING>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&light_int_l>;
> +		vdd-supply = <&vcc3v3_s3>;
> +	};
> +};
> +
> +&io_domains {
> +	status = "okay";
> +	bt656-supply = <&vcc_3v0>;
> +	audio-supply = <&vcca1v8_codec>;
> +	sdmmc-supply = <&vcc_sdio>;
> +	gpio1830-supply = <&vcc_3v0>;
> +};
> +
> +&pmu_io_domains {
> +	status = "okay";
> +	pmu1830-supply = <&vcc_3v0>;
> +};
> +
> +&pinctrl {
> +	buttons {
> +		pwr_btn: pwr-btn {
> +			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	pmic {
> +		pmic_int_l: pmic-int-l {
> +			rockchip,pins =
> +				<1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	sd {
> +		sdmmc0_pwr_h: sdmmc0-pwr-h {
> +			rockchip,pins =
> +				<RK_GPIO0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	usb2 {
> +		vcc5v0_host_en: vcc5v0-host-en {
> +			rockchip,pins =
> +				<4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		vcc5v0_typec0_en: vcc5v0-typec0-en {
> +			rockchip,pins =
> +				<1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	sdio-pwrseq {
> +		wifi_reg_on_h: wifi-reg-on-h {
> +			rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	wifi {
> +		wifi_host_wake_l: wifi-host-wake-l {
> +			rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	bluetooth {
> +		bt_reg_on_h: bt-enable-h {
> +			rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		bt_host_wake_l: bt-host-wake-l {
> +			rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		bt_wake_l: bt-wake-l {
> +			rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	mpu6500 {
> +		gsensor_int_l: gsensor-int-l {
> +			rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	lsm6ds3 {
> +		gyr_int_l: gyr-int-l {
> +			rockchip,pins = <1 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	cm32181 {
> +		light_int_l: light-int-l {
> +			rockchip,pins = <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +};
> +
> +&pwm0 {
> +	status = "okay";
> +};
> +
> +&pwm2 {
> +	status = "okay";
> +};
> +
> +&saradc {
> +	vref-supply = <&vcca1v8_s3>;
> +	status = "okay";
> +};
> +
> +&sdhci {
> +	bus-width = <8>;
> +	mmc-hs400-1_8v;
> +	mmc-hs400-enhanced-strobe;
> +	non-removable;
> +	status = "okay";
> +};
> +
> +&sdio0 {
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	cap-sdio-irq;
> +	clock-frequency = <50000000>;
> +	disable-wp;
> +	keep-power-in-suspend;
> +	max-frequency = <50000000>;
> +	mmc-pwrseq = <&sdio_pwrseq>;
> +	non-removable;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
> +	sd-uhs-sdr104;
> +	status = "okay";
> +
> +	brcmf: wifi@1 {
> +		compatible = "brcm,bcm4329-fmac";
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;
> +		interrupt-names = "host-wake";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_host_wake_l>;
> +	};
> +};
> +
> +&sdmmc {
> +	bus-width = <4>;
> +	cap-mmc-highspeed;
> +	cap-sd-highspeed;
> +	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
> +	clock-frequency = <150000000>;
> +	disable-wp;
> +	max-frequency = <150000000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
> +	vmmc-supply = <&vcc3v0_sd>;
> +	vqmmc-supply = <&vcc_sdio>;
> +	status = "okay";
> +};
> +
> +&tcphy0 {
> +	status = "okay";
> +};
> +
> +&tcphy1 {
> +	status = "okay";
> +};
> +
> +&tsadc {
> +	rockchip,hw-tshut-mode = <1>;
> +	rockchip,hw-tshut-polarity = <1>;
> +	status = "okay";
> +};
> +
> +&u2phy0 {
> +	status = "okay";
> +
> +	u2phy0_otg: otg-port {
> +		phy-supply = <&vcc5v0_typec0>;
> +		status = "okay";
> +	};
> +
> +	u2phy0_host: host-port {
> +		phy-supply = <&vcc5v0_host>;
> +		status = "okay";
> +	};
> +};
> +
> +&u2phy1 {
> +	status = "okay";
> +
> +	u2phy1_otg: otg-port {
> +		status = "okay";
> +	};
> +
> +	u2phy1_host: host-port {
> +		phy-supply = <&vcc5v0_host>;
> +		status = "okay";
> +	};
> +};
> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_xfer &uart0_cts &uart0_rts>;
> +	status = "okay";
> +
> +	bluetooth {
> +		compatible = "brcm,bcm43438-bt";
> +		clocks = <&rk808 1>;
> +		clock-names = "ext_clock";
> +		device-wakeup-gpios = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>;
> +		host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>;
> +		shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&bt_host_wake_l &bt_wake_l &bt_reg_on_h>;
> +	};
> +};
> +
> +&uart2 {
> +	status = "okay";
> +};
> +
> +&usb_host0_ehci {
> +	status = "okay";
> +};
> +
> +&usb_host0_ohci {
> +	status = "okay";
> +};
> +
> +&usb_host1_ehci {
> +	status = "okay";
> +};
> +
> +&usb_host1_ohci {
> +	status = "okay";
> +};
> +
> +&usbdrd3_0 {
> +	status = "okay";
> +};
> +
> +&usbdrd_dwc3_0 {
> +	status = "okay";
> +	dr_mode = "otg";
> +};
> +
> +&usbdrd3_1 {
> +	status = "okay";
> +};
> +
> +&usbdrd_dwc3_1 {
> +	status = "okay";
> +	dr_mode = "host";
> +};
> +
> +&vopb {
> +	status = "okay";
> +};
> +
> +&vopb_mmu {
> +	status = "okay";
> +};
> +
> +&vopl {
> +	status = "okay";
> +};
> +
> +&vopl_mmu {
> +	status = "okay";
> +};
> diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
> index caad30641e..07ee8ce92c 100644
> --- a/board/rockchip/evb_rk3399/MAINTAINERS
> +++ b/board/rockchip/evb_rk3399/MAINTAINERS
> @@ -5,3 +5,10 @@ F:      board/rockchip/evb_rk3399
>  F:      include/configs/evb_rk3399.h
>  F:      configs/evb-rk3399_defconfig
>  F:      configs/firefly-rk3399_defconfig
> +
> +ORANGEPI-RK3399
> +M:	Jagan Teki <jagan@amarulasolutions.com>
> +S:	Maintained
> +F:	configs/orangepi-rk3399_defconfig
> +F:	arch/arm/dts/rk3399-u-boot.dtsi
> +F:	arch/arm/dts/rk3399-orangepi-u-boot.dtsi
> diff --git a/configs/orangepi-rk3399_defconfig b/configs/orangepi-rk3399_defconfig
> new file mode 100644
> index 0000000000..deb7bc1388
> --- /dev/null
> +++ b/configs/orangepi-rk3399_defconfig
> @@ -0,0 +1,58 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SYS_TEXT_BASE=0x00200000
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_SYS_MALLOC_F_LEN=0x4000
> +CONFIG_ROCKCHIP_RK3399=y
> +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_SPL_STACK_R_ADDR=0x80000
> +CONFIG_DEBUG_UART=y
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-orangepi.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-orangepi"
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_DM_ETH=y
> +CONFIG_ETH_DESIGNWARE=y
> +CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PMIC_RK8XX=y
> +CONFIG_REGULATOR_PWM=y
> +CONFIG_REGULATOR_RK8XX=y
> +CONFIG_PWM_ROCKCHIP=y
> +CONFIG_BAUDRATE=1500000
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_SYSRESET=y
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_HOST_ETHER=y
> +CONFIG_USB_ETHER_ASIX=y
> +CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_USB_ETHER_MCS7830=y
> +CONFIG_USB_ETHER_RTL8152=y
> +CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_USE_TINY_PRINTF=y
> +CONFIG_ERRNO_STR=y
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 14:17       ` Paul Kocialkowski
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 14:17 UTC (permalink / raw)
  To: u-boot

Hi,

On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> Add initial support for Orangepi RK3399 board.
> 
> Specification
> - Rockchip RK3399
> - 2GB/4GB DDR3
> - 16GB eMMC
> - SD card slot

Looks like you're missing u-boot,dm-pre-reloc to have it working, which
will need to be introduced when moving to rk3399-u-boot.dtsi.

Cheers,

Paul

> - RTL8211E 1Gbps
> - AP6356S WiFI/BT
> - HDMI In/Out, DP, MIPI DSI/CSI
> - Mini PCIe
> - Sensors, Keys etc
> - DC12V-2A and DC5V-2A
> 
> Commit details about Linux DTS sync:
> "arm64: dts: rockchip: Add support for the Orange Pi RK3399"
> (sha1: d3e71487a790979057c0fdbf32f85033639c16e6)
> 
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
>  arch/arm/dts/Makefile                    |   1 +
>  arch/arm/dts/rk3399-orangepi-u-boot.dtsi |   7 +
>  arch/arm/dts/rk3399-orangepi.dts         | 771 +++++++++++++++++++++++
>  board/rockchip/evb_rk3399/MAINTAINERS    |   7 +
>  configs/orangepi-rk3399_defconfig        |  58 ++
>  5 files changed, 844 insertions(+)
>  create mode 100644 arch/arm/dts/rk3399-orangepi-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3399-orangepi.dts
>  create mode 100644 configs/orangepi-rk3399_defconfig
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 0e2ffdb87f..6d55b0caf8 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -87,6 +87,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
>  	rk3399-evb.dtb \
>  	rk3399-firefly.dtb \
>  	rk3399-gru-bob.dtb \
> +	rk3399-orangepi.dtb \
>  	rk3399-puma-ddr1333.dtb \
>  	rk3399-puma-ddr1600.dtb \
>  	rk3399-puma-ddr1866.dtb \
> diff --git a/arch/arm/dts/rk3399-orangepi-u-boot.dtsi b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
> new file mode 100644
> index 0000000000..236b61d78d
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-orangepi-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Jagan Teki <jagan@amarulasolutions.com>
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +#include "rk3399-sdram-ddr3-1333.dtsi"
> diff --git a/arch/arm/dts/rk3399-orangepi.dts b/arch/arm/dts/rk3399-orangepi.dts
> new file mode 100644
> index 0000000000..cf37b96a6b
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-orangepi.dts
> @@ -0,0 +1,771 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "dt-bindings/pwm/pwm.h"
> +#include "dt-bindings/input/input.h"
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> +	model = "Orange Pi RK3399 Board";
> +	compatible = "rockchip,rk3399-orangepi", "rockchip,rk3399";
> +
> +	chosen {
> +		stdout-path = "serial2:1500000n8";
> +	};
> +
> +	clkin_gmac: external-gmac-clock {
> +		compatible = "fixed-clock";
> +		clock-frequency = <125000000>;
> +		clock-output-names = "clkin_gmac";
> +		#clock-cells = <0>;
> +	};
> +
> +	adc-keys {
> +		compatible = "adc-keys";
> +		io-channels = <&saradc 1>;
> +		io-channel-names = "buttons";
> +		keyup-threshold-microvolt = <1800000>;
> +		poll-interval = <100>;
> +
> +		button-up {
> +			label = "Volume Up";
> +			linux,code = <KEY_VOLUMEUP>;
> +			press-threshold-microvolt = <100000>;
> +		};
> +
> +		button-down {
> +			label = "Volume Down";
> +			linux,code = <KEY_VOLUMEDOWN>;
> +			press-threshold-microvolt = <300000>;
> +		};
> +
> +		back {
> +			label = "Back";
> +			linux,code = <KEY_BACK>;
> +			press-threshold-microvolt = <985000>;
> +		};
> +
> +		menu {
> +			label = "Menu";
> +			linux,code = <KEY_MENU>;
> +			press-threshold-microvolt = <1314000>;
> +		};
> +	};
> +
> +	dc_12v: dc-12v {
> +		compatible = "regulator-fixed";
> +		regulator-name = "dc_12v";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <12000000>;
> +		regulator-max-microvolt = <12000000>;
> +	};
> +
> +	keys: gpio-keys {
> +		compatible = "gpio-keys";
> +		autorepeat;
> +
> +		power {
> +			debounce-interval = <100>;
> +			gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
> +			label = "GPIO Power";
> +			linux,code = <KEY_POWER>;
> +			linux,input-type = <1>;
> +			pinctrl-names = "default";
> +			pinctrl-0 = <&pwr_btn>;
> +			wakeup-source;
> +		};
> +	};
> +
> +	sdio_pwrseq: sdio-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		clocks = <&rk808 1>;
> +		clock-names = "ext_clock";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_reg_on_h>;
> +		reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
> +	};
> +
> +	/* switched by pmic_sleep */
> +	vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc1v8_s3";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		vin-supply = <&vcc_1v8>;
> +	};
> +
> +	vcc3v0_sd: vcc3v0-sd {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&sdmmc0_pwr_h>;
> +		regulator-boot-on;
> +		regulator-max-microvolt = <3000000>;
> +		regulator-min-microvolt = <3000000>;
> +		regulator-name = "vcc3v0_sd";
> +		vin-supply = <&vcc3v3_sys>;
> +	};
> +
> +	vcc3v3_sys: vcc3v3-sys {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc3v3_sys";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <3300000>;
> +		regulator-max-microvolt = <3300000>;
> +		vin-supply = <&vcc_sys>;
> +	};
> +
> +	vcc5v0_host: vcc5v0-host-regulator {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio4 RK_PD1 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vcc5v0_host_en>;
> +		regulator-name = "vcc5v0_host";
> +		regulator-always-on;
> +		vin-supply = <&vcc_sys>;
> +	};
> +
> +	vcc5v0_typec0: vcc5v0-typec0-regulator {
> +		compatible = "regulator-fixed";
> +		enable-active-high;
> +		gpio = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&vcc5v0_typec0_en>;
> +		regulator-name = "vcc5v0_typec0";
> +		vin-supply = <&vcc_sys>;
> +	};
> +
> +	vcc_sys: vcc-sys {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_sys";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		vin-supply = <&dc_12v>;
> +	};
> +
> +	vdd_log: vdd-log {
> +		compatible = "pwm-regulator";
> +		pwms = <&pwm2 0 25000 1>;
> +		regulator-name = "vdd_log";
> +		regulator-always-on;
> +		regulator-boot-on;
> +		regulator-min-microvolt = <800000>;
> +		regulator-max-microvolt = <1400000>;
> +		vin-supply = <&vcc_sys>;
> +	};
> +};
> +
> +&cpu_l0 {
> +	cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l1 {
> +	cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l2 {
> +	cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l3 {
> +	cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_b0 {
> +	cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&cpu_b1 {
> +	cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&emmc_phy {
> +	status = "okay";
> +};
> +
> +&gmac {
> +	assigned-clocks = <&cru SCLK_RMII_SRC>;
> +	assigned-clock-parents = <&clkin_gmac>;
> +	clock_in_out = "input";
> +	phy-supply = <&vcc3v3_s3>;
> +	phy-mode = "rgmii";
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&rgmii_pins>;
> +	snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
> +	snps,reset-active-low;
> +	snps,reset-delays-us = <0 10000 50000>;
> +	tx_delay = <0x28>;
> +	rx_delay = <0x11>;
> +	status = "okay";
> +};
> +
> +&gpu {
> +	mali-supply = <&vdd_gpu>;
> +	status = "okay";
> +};
> +
> +&hdmi {
> +	ddc-i2c-bus = <&i2c3>;
> +	status = "okay";
> +};
> +
> +&hdmi_sound {
> +	status = "okay";
> +};
> +
> +&i2c0 {
> +	clock-frequency = <400000>;
> +	i2c-scl-rising-time-ns = <168>;
> +	i2c-scl-falling-time-ns = <4>;
> +	status = "okay";
> +
> +	rk808: pmic at 1b {
> +		compatible = "rockchip,rk808";
> +		reg = <0x1b>;
> +		interrupt-parent = <&gpio1>;
> +		interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
> +		#clock-cells = <1>;
> +		clock-output-names = "rtc_clko_soc", "rtc_clko_wifi";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pmic_int_l>;
> +		rockchip,system-power-controller;
> +		wakeup-source;
> +
> +		vcc1-supply = <&vcc3v3_sys>;
> +		vcc2-supply = <&vcc3v3_sys>;
> +		vcc3-supply = <&vcc3v3_sys>;
> +		vcc4-supply = <&vcc3v3_sys>;
> +		vcc6-supply = <&vcc3v3_sys>;
> +		vcc7-supply = <&vcc3v3_sys>;
> +		vcc8-supply = <&vcc3v3_sys>;
> +		vcc9-supply = <&vcc3v3_sys>;
> +		vcc10-supply = <&vcc3v3_sys>;
> +		vcc11-supply = <&vcc3v3_sys>;
> +		vcc12-supply = <&vcc3v3_sys>;
> +		vddio-supply = <&vcc_3v0>;
> +
> +		regulators {
> +			vdd_center: DCDC_REG1 {
> +				regulator-name = "vdd_center";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <700000>;
> +				regulator-max-microvolt = <1500000>;
> +				regulator-ramp-delay = <6001>;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vdd_cpu_l: DCDC_REG2 {
> +				regulator-name = "vdd_cpu_l";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <700000>;
> +				regulator-max-microvolt = <1500000>;
> +				regulator-ramp-delay = <6001>;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_ddr: DCDC_REG3 {
> +				regulator-name = "vcc_ddr";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v8: DCDC_REG4 {
> +				regulator-name = "vcc_1v8";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3300000>;
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			vcc1v8_dvp: LDO_REG1 {
> +				regulator-name = "vcc1v8_dvp";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3400000>;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc3v0_tp: LDO_REG2 {
> +				regulator-name = "vcc3v0_tp";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3400000>;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc1v8_pmupll: LDO_REG3 {
> +				regulator-name = "vcc1v8_pmupll";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <2500000>;
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <1800000>;
> +				};
> +			};
> +
> +			vcc_sdio: LDO_REG4 {
> +				regulator-name = "vcc_sdio";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3400000>;
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <3000000>;
> +				};
> +			};
> +
> +			vcca3v0_codec: LDO_REG5 {
> +				regulator-name = "vcca3v0_codec";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3400000>;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_1v5: LDO_REG6 {
> +				regulator-name = "vcc_1v5";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <2500000>;
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <1500000>;
> +				};
> +			};
> +
> +			vcca1v8_codec: LDO_REG7 {
> +				regulator-name = "vcca1v8_codec";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <800000>;
> +				regulator-max-microvolt = <2500000>;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc_3v0: LDO_REG8 {
> +				regulator-name = "vcc_3v0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-min-microvolt = <1800000>;
> +				regulator-max-microvolt = <3400000>;
> +				regulator-state-mem {
> +					regulator-on-in-suspend;
> +					regulator-suspend-microvolt = <3000000>;
> +				};
> +			};
> +
> +			vcc3v3_s3: SWITCH_REG1 {
> +				regulator-name = "vcc3v3_s3";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +
> +			vcc3v3_s0: SWITCH_REG2 {
> +				regulator-name = "vcc3v3_s0";
> +				regulator-always-on;
> +				regulator-boot-on;
> +				regulator-state-mem {
> +					regulator-off-in-suspend;
> +				};
> +			};
> +		};
> +	};
> +
> +	vdd_cpu_b: regulator at 40 {
> +		compatible = "silergy,syr827";
> +		reg = <0x40>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_cpu_b";
> +		regulator-min-microvolt = <712500>;
> +		regulator-max-microvolt = <1500000>;
> +		regulator-ramp-delay = <1000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +		vin-supply = <&vcc3v3_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +
> +	vdd_gpu: regulator at 41 {
> +		compatible = "silergy,syr828";
> +		reg = <0x41>;
> +		fcs,suspend-voltage-selector = <1>;
> +		regulator-name = "vdd_gpu";
> +		regulator-min-microvolt = <712500>;
> +		regulator-max-microvolt = <1500000>;
> +		regulator-ramp-delay = <1000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +		vin-supply = <&vcc3v3_sys>;
> +
> +		regulator-state-mem {
> +			regulator-off-in-suspend;
> +		};
> +	};
> +};
> +
> +&i2c1 {
> +	i2c-scl-rising-time-ns = <450>;
> +	i2c-scl-falling-time-ns = <15>;
> +	status = "okay";
> +};
> +
> +&i2c3 {
> +	i2c-scl-rising-time-ns = <450>;
> +	i2c-scl-falling-time-ns = <15>;
> +	status = "okay";
> +};
> +
> +&i2c4 {
> +	clock-frequency = <400000>;
> +	i2c-scl-rising-time-ns = <450>;
> +	i2c-scl-falling-time-ns = <15>;
> +	status = "okay";
> +
> +	ak09911 at c {
> +		compatible = "asahi-kasei,ak09911";
> +		reg = <0x0c>;
> +		vdd-supply = <&vcc3v3_s3>;
> +	};
> +
> +	mpu6500 at 68 {
> +		compatible = "invensense,mpu6500";
> +		reg = <0x68>;
> +		interrupt-parent = <&gpio1>;
> +		interrupts = <RK_PC6 IRQ_TYPE_EDGE_RISING>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&gsensor_int_l>;
> +		vddio-supply = <&vcc3v3_s3>;
> +	};
> +
> +	lsm6ds3 at 6a {
> +		compatible = "st,lsm6ds3";
> +		reg = <0x6a>;
> +		interrupt-parent = <&gpio1>;
> +		interrupts = <RK_PD0 IRQ_TYPE_EDGE_RISING>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&gyr_int_l>;
> +		vdd-supply = <&vcc3v3_s3>;
> +		vddio-supply = <&vcc3v3_s3>;
> +	};
> +
> +	cm32181 at 10 {
> +		compatible = "capella,cm32181";
> +		reg = <0x10>;
> +		interrupt-parent = <&gpio4>;
> +		interrupts = <RK_PD0 IRQ_TYPE_EDGE_RISING>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&light_int_l>;
> +		vdd-supply = <&vcc3v3_s3>;
> +	};
> +};
> +
> +&io_domains {
> +	status = "okay";
> +	bt656-supply = <&vcc_3v0>;
> +	audio-supply = <&vcca1v8_codec>;
> +	sdmmc-supply = <&vcc_sdio>;
> +	gpio1830-supply = <&vcc_3v0>;
> +};
> +
> +&pmu_io_domains {
> +	status = "okay";
> +	pmu1830-supply = <&vcc_3v0>;
> +};
> +
> +&pinctrl {
> +	buttons {
> +		pwr_btn: pwr-btn {
> +			rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	pmic {
> +		pmic_int_l: pmic-int-l {
> +			rockchip,pins =
> +				<1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
> +		};
> +	};
> +
> +	sd {
> +		sdmmc0_pwr_h: sdmmc0-pwr-h {
> +			rockchip,pins =
> +				<RK_GPIO0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	usb2 {
> +		vcc5v0_host_en: vcc5v0-host-en {
> +			rockchip,pins =
> +				<4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		vcc5v0_typec0_en: vcc5v0-typec0-en {
> +			rockchip,pins =
> +				<1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	sdio-pwrseq {
> +		wifi_reg_on_h: wifi-reg-on-h {
> +			rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	wifi {
> +		wifi_host_wake_l: wifi-host-wake-l {
> +			rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	bluetooth {
> +		bt_reg_on_h: bt-enable-h {
> +			rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		bt_host_wake_l: bt-host-wake-l {
> +			rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		bt_wake_l: bt-wake-l {
> +			rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	mpu6500 {
> +		gsensor_int_l: gsensor-int-l {
> +			rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	lsm6ds3 {
> +		gyr_int_l: gyr-int-l {
> +			rockchip,pins = <1 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	cm32181 {
> +		light_int_l: light-int-l {
> +			rockchip,pins = <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +};
> +
> +&pwm0 {
> +	status = "okay";
> +};
> +
> +&pwm2 {
> +	status = "okay";
> +};
> +
> +&saradc {
> +	vref-supply = <&vcca1v8_s3>;
> +	status = "okay";
> +};
> +
> +&sdhci {
> +	bus-width = <8>;
> +	mmc-hs400-1_8v;
> +	mmc-hs400-enhanced-strobe;
> +	non-removable;
> +	status = "okay";
> +};
> +
> +&sdio0 {
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	cap-sdio-irq;
> +	clock-frequency = <50000000>;
> +	disable-wp;
> +	keep-power-in-suspend;
> +	max-frequency = <50000000>;
> +	mmc-pwrseq = <&sdio_pwrseq>;
> +	non-removable;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
> +	sd-uhs-sdr104;
> +	status = "okay";
> +
> +	brcmf: wifi at 1 {
> +		compatible = "brcm,bcm4329-fmac";
> +		interrupt-parent = <&gpio0>;
> +		interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;
> +		interrupt-names = "host-wake";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_host_wake_l>;
> +	};
> +};
> +
> +&sdmmc {
> +	bus-width = <4>;
> +	cap-mmc-highspeed;
> +	cap-sd-highspeed;
> +	cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
> +	clock-frequency = <150000000>;
> +	disable-wp;
> +	max-frequency = <150000000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
> +	vmmc-supply = <&vcc3v0_sd>;
> +	vqmmc-supply = <&vcc_sdio>;
> +	status = "okay";
> +};
> +
> +&tcphy0 {
> +	status = "okay";
> +};
> +
> +&tcphy1 {
> +	status = "okay";
> +};
> +
> +&tsadc {
> +	rockchip,hw-tshut-mode = <1>;
> +	rockchip,hw-tshut-polarity = <1>;
> +	status = "okay";
> +};
> +
> +&u2phy0 {
> +	status = "okay";
> +
> +	u2phy0_otg: otg-port {
> +		phy-supply = <&vcc5v0_typec0>;
> +		status = "okay";
> +	};
> +
> +	u2phy0_host: host-port {
> +		phy-supply = <&vcc5v0_host>;
> +		status = "okay";
> +	};
> +};
> +
> +&u2phy1 {
> +	status = "okay";
> +
> +	u2phy1_otg: otg-port {
> +		status = "okay";
> +	};
> +
> +	u2phy1_host: host-port {
> +		phy-supply = <&vcc5v0_host>;
> +		status = "okay";
> +	};
> +};
> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0_xfer &uart0_cts &uart0_rts>;
> +	status = "okay";
> +
> +	bluetooth {
> +		compatible = "brcm,bcm43438-bt";
> +		clocks = <&rk808 1>;
> +		clock-names = "ext_clock";
> +		device-wakeup-gpios = <&gpio2 RK_PD2 GPIO_ACTIVE_HIGH>;
> +		host-wakeup-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_HIGH>;
> +		shutdown-gpios = <&gpio0 RK_PB1 GPIO_ACTIVE_HIGH>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&bt_host_wake_l &bt_wake_l &bt_reg_on_h>;
> +	};
> +};
> +
> +&uart2 {
> +	status = "okay";
> +};
> +
> +&usb_host0_ehci {
> +	status = "okay";
> +};
> +
> +&usb_host0_ohci {
> +	status = "okay";
> +};
> +
> +&usb_host1_ehci {
> +	status = "okay";
> +};
> +
> +&usb_host1_ohci {
> +	status = "okay";
> +};
> +
> +&usbdrd3_0 {
> +	status = "okay";
> +};
> +
> +&usbdrd_dwc3_0 {
> +	status = "okay";
> +	dr_mode = "otg";
> +};
> +
> +&usbdrd3_1 {
> +	status = "okay";
> +};
> +
> +&usbdrd_dwc3_1 {
> +	status = "okay";
> +	dr_mode = "host";
> +};
> +
> +&vopb {
> +	status = "okay";
> +};
> +
> +&vopb_mmu {
> +	status = "okay";
> +};
> +
> +&vopl {
> +	status = "okay";
> +};
> +
> +&vopl_mmu {
> +	status = "okay";
> +};
> diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
> index caad30641e..07ee8ce92c 100644
> --- a/board/rockchip/evb_rk3399/MAINTAINERS
> +++ b/board/rockchip/evb_rk3399/MAINTAINERS
> @@ -5,3 +5,10 @@ F:      board/rockchip/evb_rk3399
>  F:      include/configs/evb_rk3399.h
>  F:      configs/evb-rk3399_defconfig
>  F:      configs/firefly-rk3399_defconfig
> +
> +ORANGEPI-RK3399
> +M:	Jagan Teki <jagan@amarulasolutions.com>
> +S:	Maintained
> +F:	configs/orangepi-rk3399_defconfig
> +F:	arch/arm/dts/rk3399-u-boot.dtsi
> +F:	arch/arm/dts/rk3399-orangepi-u-boot.dtsi
> diff --git a/configs/orangepi-rk3399_defconfig b/configs/orangepi-rk3399_defconfig
> new file mode 100644
> index 0000000000..deb7bc1388
> --- /dev/null
> +++ b/configs/orangepi-rk3399_defconfig
> @@ -0,0 +1,58 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SYS_TEXT_BASE=0x00200000
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_SYS_MALLOC_F_LEN=0x4000
> +CONFIG_ROCKCHIP_RK3399=y
> +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_SPL_STACK_R_ADDR=0x80000
> +CONFIG_DEBUG_UART=y
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-orangepi.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-orangepi"
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_DM_ETH=y
> +CONFIG_ETH_DESIGNWARE=y
> +CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PMIC_RK8XX=y
> +CONFIG_REGULATOR_PWM=y
> +CONFIG_REGULATOR_RK8XX=y
> +CONFIG_PWM_ROCKCHIP=y
> +CONFIG_BAUDRATE=1500000
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_SYSRESET=y
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_HOST_ETHER=y
> +CONFIG_USB_ETHER_ASIX=y
> +CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_USB_ETHER_MCS7830=y
> +CONFIG_USB_ETHER_RTL8152=y
> +CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_USE_TINY_PRINTF=y
> +CONFIG_ERRNO_STR=y
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 14:17       ` [U-Boot] " Paul Kocialkowski
@ 2019-04-26 14:27           ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 14:27 UTC (permalink / raw)
  To: Paul Kocialkowski
  Cc: U-Boot-Denx, Simon Glass, Kever Yang,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Akash Gajjar,
	Philipp Tomsich, linux-amarula

On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
<paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>
> Hi,
>
> On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > Add initial support for Orangepi RK3399 board.
> >
> > Specification
> > - Rockchip RK3399
> > - 2GB/4GB DDR3
> > - 16GB eMMC
> > - SD card slot
>
> Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> will need to be introduced when moving to rk3399-u-boot.dtsi.

Look like you are confused or doesn't check the patch. This patch have
rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
u-boot,dm-pre-reloc for sdmmc.

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 14:27           ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 14:27 UTC (permalink / raw)
  To: u-boot

On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > Add initial support for Orangepi RK3399 board.
> >
> > Specification
> > - Rockchip RK3399
> > - 2GB/4GB DDR3
> > - 16GB eMMC
> > - SD card slot
>
> Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> will need to be introduced when moving to rk3399-u-boot.dtsi.

Look like you are confused or doesn't check the patch. This patch have
rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
u-boot,dm-pre-reloc for sdmmc.

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 14:27           ` [U-Boot] " Jagan Teki
@ 2019-04-26 14:34             ` Paul Kocialkowski
  -1 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 14:34 UTC (permalink / raw)
  To: Jagan Teki; +Cc: U-Boot-Denx, linux-rockchip, Akash Gajjar, linux-amarula

Hi,

On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > Add initial support for Orangepi RK3399 board.
> > > 
> > > Specification
> > > - Rockchip RK3399
> > > - 2GB/4GB DDR3
> > > - 16GB eMMC
> > > - SD card slot
> > 
> > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > will need to be introduced when moving to rk3399-u-boot.dtsi.
> 
> Look like you are confused or doesn't check the patch. This patch have
> rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> u-boot,dm-pre-reloc for sdmmc.

Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
it in your second series when you add it back to rk3399-u-boot.dtsi.

It's not okay to submit the board with broken MMC support and fix it in
a subsequent series.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 14:34             ` Paul Kocialkowski
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 14:34 UTC (permalink / raw)
  To: u-boot

Hi,

On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > Add initial support for Orangepi RK3399 board.
> > > 
> > > Specification
> > > - Rockchip RK3399
> > > - 2GB/4GB DDR3
> > > - 16GB eMMC
> > > - SD card slot
> > 
> > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > will need to be introduced when moving to rk3399-u-boot.dtsi.
> 
> Look like you are confused or doesn't check the patch. This patch have
> rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> u-boot,dm-pre-reloc for sdmmc.

Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
it in your second series when you add it back to rk3399-u-boot.dtsi.

It's not okay to submit the board with broken MMC support and fix it in
a subsequent series.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 14:34             ` [U-Boot] " Paul Kocialkowski
@ 2019-04-26 14:45                 ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 14:45 UTC (permalink / raw)
  To: Paul Kocialkowski
  Cc: U-Boot-Denx, Simon Glass, Kever Yang,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Akash Gajjar,
	Philipp Tomsich, linux-amarula

On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
<paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>
> Hi,
>
> On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > > Hi,
> > >
> > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > Add initial support for Orangepi RK3399 board.
> > > >
> > > > Specification
> > > > - Rockchip RK3399
> > > > - 2GB/4GB DDR3
> > > > - 16GB eMMC
> > > > - SD card slot
> > >
> > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> >
> > Look like you are confused or doesn't check the patch. This patch have
> > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > u-boot,dm-pre-reloc for sdmmc.
>
> Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> it in your second series when you add it back to rk3399-u-boot.dtsi.

Which u-boot,dm-pre-reloc are you taking about?

v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
which were used by subsequent boards on the same series.

The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
existing board dts files thought that it will include
rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1

>
> It's not okay to submit the board with broken MMC support and fix it in
> a subsequent series.

Again, nothing broken. existing boards or dts(i) files are untouched.
Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
node to make use of new boards.  and the same reused by next series
so-that I can add binman global to all rk3399 boards.

[1] https://patchwork.ozlabs.org/patch/1091534/

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 14:45                 ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 14:45 UTC (permalink / raw)
  To: u-boot

On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > Add initial support for Orangepi RK3399 board.
> > > >
> > > > Specification
> > > > - Rockchip RK3399
> > > > - 2GB/4GB DDR3
> > > > - 16GB eMMC
> > > > - SD card slot
> > >
> > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> >
> > Look like you are confused or doesn't check the patch. This patch have
> > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > u-boot,dm-pre-reloc for sdmmc.
>
> Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> it in your second series when you add it back to rk3399-u-boot.dtsi.

Which u-boot,dm-pre-reloc are you taking about?

v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
which were used by subsequent boards on the same series.

The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
existing board dts files thought that it will include
rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1

>
> It's not okay to submit the board with broken MMC support and fix it in
> a subsequent series.

Again, nothing broken. existing boards or dts(i) files are untouched.
Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
node to make use of new boards.  and the same reused by next series
so-that I can add binman global to all rk3399 boards.

[1] https://patchwork.ozlabs.org/patch/1091534/

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 14:45                 ` [U-Boot] " Jagan Teki
@ 2019-04-26 14:54                   ` Paul Kocialkowski
  -1 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 14:54 UTC (permalink / raw)
  To: Jagan Teki; +Cc: U-Boot-Denx, linux-rockchip, Akash Gajjar, linux-amarula

Hi,

On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > Add initial support for Orangepi RK3399 board.
> > > > > 
> > > > > Specification
> > > > > - Rockchip RK3399
> > > > > - 2GB/4GB DDR3
> > > > > - 16GB eMMC
> > > > > - SD card slot
> > > > 
> > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > 
> > > Look like you are confused or doesn't check the patch. This patch have
> > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > u-boot,dm-pre-reloc for sdmmc.
> > 
> > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > it in your second series when you add it back to rk3399-u-boot.dtsi.
> 
> Which u-boot,dm-pre-reloc are you taking about?
> 
> v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> which were used by subsequent boards on the same series.
> 
> The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> existing board dts files thought that it will include
> rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> 
> > It's not okay to submit the board with broken MMC support and fix it in
> > a subsequent series.
> 
> Again, nothing broken. existing boards or dts(i) files are untouched.
> Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> node to make use of new boards.  and the same reused by next series
> so-that I can add binman global to all rk3399 boards.

Okay I think I'm getting there. So the Orangepi uses the new scheme
(including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
other boards are still using the previous scheme after the series.

This is very confusing and I really think you should keep u-boot,dm-
pre-reloc in the orange pi dts file and then make the transition with
all the other boards. You're mixing multiple logical steps which makes
it really hard to understand what's going on.

More to that, introducing the rk3399-u-boot.dtsi is a logical step that
should be grouped with your second series, not the first one. In your
first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.

Could you respin the two series to group changes by logic changes
instead of the current state of interleaved changes?

Mixing logical changes (not to mention spreading them accross series)
is really a no-go and makes reviewing the patches very difficult, as
this thread perfectly illustrates.

It's really not against you personally, but there are such rules that
need to be followed in upstream contributions. They are at least as
essential as the underlying technical work.

Cheers,

Paul

> [1] https://patchwork.ozlabs.org/patch/1091534/
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 14:54                   ` Paul Kocialkowski
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 14:54 UTC (permalink / raw)
  To: u-boot

Hi,

On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > Add initial support for Orangepi RK3399 board.
> > > > > 
> > > > > Specification
> > > > > - Rockchip RK3399
> > > > > - 2GB/4GB DDR3
> > > > > - 16GB eMMC
> > > > > - SD card slot
> > > > 
> > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > 
> > > Look like you are confused or doesn't check the patch. This patch have
> > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > u-boot,dm-pre-reloc for sdmmc.
> > 
> > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > it in your second series when you add it back to rk3399-u-boot.dtsi.
> 
> Which u-boot,dm-pre-reloc are you taking about?
> 
> v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> which were used by subsequent boards on the same series.
> 
> The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> existing board dts files thought that it will include
> rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> 
> > It's not okay to submit the board with broken MMC support and fix it in
> > a subsequent series.
> 
> Again, nothing broken. existing boards or dts(i) files are untouched.
> Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> node to make use of new boards.  and the same reused by next series
> so-that I can add binman global to all rk3399 boards.

Okay I think I'm getting there. So the Orangepi uses the new scheme
(including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
other boards are still using the previous scheme after the series.

This is very confusing and I really think you should keep u-boot,dm-
pre-reloc in the orange pi dts file and then make the transition with
all the other boards. You're mixing multiple logical steps which makes
it really hard to understand what's going on.

More to that, introducing the rk3399-u-boot.dtsi is a logical step that
should be grouped with your second series, not the first one. In your
first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.

Could you respin the two series to group changes by logic changes
instead of the current state of interleaved changes?

Mixing logical changes (not to mention spreading them accross series)
is really a no-go and makes reviewing the patches very difficult, as
this thread perfectly illustrates.

It's really not against you personally, but there are such rules that
need to be followed in upstream contributions. They are at least as
essential as the underlying technical work.

Cheers,

Paul

> [1] https://patchwork.ozlabs.org/patch/1091534/
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 14:54                   ` [U-Boot] " Paul Kocialkowski
@ 2019-04-26 15:01                       ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 15:01 UTC (permalink / raw)
  To: Paul Kocialkowski
  Cc: U-Boot-Denx, Simon Glass, Kever Yang,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Akash Gajjar,
	Philipp Tomsich, linux-amarula

On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
<paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>
> Hi,
>
> On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > > Hi,
> > >
> > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> > > > > Hi,
> > > > >
> > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > Add initial support for Orangepi RK3399 board.
> > > > > >
> > > > > > Specification
> > > > > > - Rockchip RK3399
> > > > > > - 2GB/4GB DDR3
> > > > > > - 16GB eMMC
> > > > > > - SD card slot
> > > > >
> > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > >
> > > > Look like you are confused or doesn't check the patch. This patch have
> > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > u-boot,dm-pre-reloc for sdmmc.
> > >
> > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> >
> > Which u-boot,dm-pre-reloc are you taking about?
> >
> > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > which were used by subsequent boards on the same series.
> >
> > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > existing board dts files thought that it will include
> > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> >
> > > It's not okay to submit the board with broken MMC support and fix it in
> > > a subsequent series.
> >
> > Again, nothing broken. existing boards or dts(i) files are untouched.
> > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > node to make use of new boards.  and the same reused by next series
> > so-that I can add binman global to all rk3399 boards.
>
> Okay I think I'm getting there. So the Orangepi uses the new scheme
> (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> other boards are still using the previous scheme after the series.
>
> This is very confusing and I really think you should keep u-boot,dm-
> pre-reloc in the orange pi dts file and then make the transition with
> all the other boards. You're mixing multiple logical steps which makes
> it really hard to understand what's going on.
>
> More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> should be grouped with your second series, not the first one. In your
> first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
>
> Could you respin the two series to group changes by logic changes
> instead of the current state of interleaved changes?

Okay, to make it clear I can send v4 with v3.1 included and updated
commit log. but I the new series about binman remains same since the
changes on first patch on the series are relevant.

Jagan.

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 15:01                       ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 15:01 UTC (permalink / raw)
  To: u-boot

On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > Add initial support for Orangepi RK3399 board.
> > > > > >
> > > > > > Specification
> > > > > > - Rockchip RK3399
> > > > > > - 2GB/4GB DDR3
> > > > > > - 16GB eMMC
> > > > > > - SD card slot
> > > > >
> > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > >
> > > > Look like you are confused or doesn't check the patch. This patch have
> > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > u-boot,dm-pre-reloc for sdmmc.
> > >
> > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> >
> > Which u-boot,dm-pre-reloc are you taking about?
> >
> > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > which were used by subsequent boards on the same series.
> >
> > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > existing board dts files thought that it will include
> > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> >
> > > It's not okay to submit the board with broken MMC support and fix it in
> > > a subsequent series.
> >
> > Again, nothing broken. existing boards or dts(i) files are untouched.
> > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > node to make use of new boards.  and the same reused by next series
> > so-that I can add binman global to all rk3399 boards.
>
> Okay I think I'm getting there. So the Orangepi uses the new scheme
> (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> other boards are still using the previous scheme after the series.
>
> This is very confusing and I really think you should keep u-boot,dm-
> pre-reloc in the orange pi dts file and then make the transition with
> all the other boards. You're mixing multiple logical steps which makes
> it really hard to understand what's going on.
>
> More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> should be grouped with your second series, not the first one. In your
> first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
>
> Could you respin the two series to group changes by logic changes
> instead of the current state of interleaved changes?

Okay, to make it clear I can send v4 with v3.1 included and updated
commit log. but I the new series about binman remains same since the
changes on first patch on the series are relevant.

Jagan.

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 15:01                       ` [U-Boot] " Jagan Teki
@ 2019-04-26 15:12                         ` Paul Kocialkowski
  -1 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 15:12 UTC (permalink / raw)
  To: Jagan Teki; +Cc: U-Boot-Denx, linux-rockchip, Akash Gajjar, linux-amarula

Hi,

On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > 
> > > > > > > Specification
> > > > > > > - Rockchip RK3399
> > > > > > > - 2GB/4GB DDR3
> > > > > > > - 16GB eMMC
> > > > > > > - SD card slot
> > > > > > 
> > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > 
> > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > 
> > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > 
> > > Which u-boot,dm-pre-reloc are you taking about?
> > > 
> > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > which were used by subsequent boards on the same series.
> > > 
> > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > existing board dts files thought that it will include
> > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > 
> > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > a subsequent series.
> > > 
> > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > node to make use of new boards.  and the same reused by next series
> > > so-that I can add binman global to all rk3399 boards.
> > 
> > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > other boards are still using the previous scheme after the series.
> > 
> > This is very confusing and I really think you should keep u-boot,dm-
> > pre-reloc in the orange pi dts file and then make the transition with
> > all the other boards. You're mixing multiple logical steps which makes
> > it really hard to understand what's going on.
> > 
> > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > should be grouped with your second series, not the first one. In your
> > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > 
> > Could you respin the two series to group changes by logic changes
> > instead of the current state of interleaved changes?
> 
> Okay, to make it clear I can send v4 with v3.1 included and updated
> commit log. but I the new series about binman remains same since the
> changes on first patch on the series are relevant.

I think it makes no sense to introduce rk3399-u-boot.dts as part of the
series currently in v3. You need to remove the patch (currently v3.1)
from this series and group it with the new series (binman-related).

Otherwise, you're mixing two unrelated logical changes across two
series.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 15:12                         ` Paul Kocialkowski
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 15:12 UTC (permalink / raw)
  To: u-boot

Hi,

On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > 
> > > > > > > Specification
> > > > > > > - Rockchip RK3399
> > > > > > > - 2GB/4GB DDR3
> > > > > > > - 16GB eMMC
> > > > > > > - SD card slot
> > > > > > 
> > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > 
> > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > 
> > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > 
> > > Which u-boot,dm-pre-reloc are you taking about?
> > > 
> > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > which were used by subsequent boards on the same series.
> > > 
> > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > existing board dts files thought that it will include
> > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > 
> > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > a subsequent series.
> > > 
> > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > node to make use of new boards.  and the same reused by next series
> > > so-that I can add binman global to all rk3399 boards.
> > 
> > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > other boards are still using the previous scheme after the series.
> > 
> > This is very confusing and I really think you should keep u-boot,dm-
> > pre-reloc in the orange pi dts file and then make the transition with
> > all the other boards. You're mixing multiple logical steps which makes
> > it really hard to understand what's going on.
> > 
> > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > should be grouped with your second series, not the first one. In your
> > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > 
> > Could you respin the two series to group changes by logic changes
> > instead of the current state of interleaved changes?
> 
> Okay, to make it clear I can send v4 with v3.1 included and updated
> commit log. but I the new series about binman remains same since the
> changes on first patch on the series are relevant.

I think it makes no sense to introduce rk3399-u-boot.dts as part of the
series currently in v3. You need to remove the patch (currently v3.1)
from this series and group it with the new series (binman-related).

Otherwise, you're mixing two unrelated logical changes across two
series.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 15:12                         ` [U-Boot] " Paul Kocialkowski
@ 2019-04-26 15:18                           ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 15:18 UTC (permalink / raw)
  To: Paul Kocialkowski
  Cc: U-Boot-Denx, linux-rockchip, Akash Gajjar, linux-amarula

On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > >
> > > > > > > > Specification
> > > > > > > > - Rockchip RK3399
> > > > > > > > - 2GB/4GB DDR3
> > > > > > > > - 16GB eMMC
> > > > > > > > - SD card slot
> > > > > > >
> > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > >
> > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > >
> > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > >
> > > > Which u-boot,dm-pre-reloc are you taking about?
> > > >
> > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > which were used by subsequent boards on the same series.
> > > >
> > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > existing board dts files thought that it will include
> > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > >
> > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > a subsequent series.
> > > >
> > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > node to make use of new boards.  and the same reused by next series
> > > > so-that I can add binman global to all rk3399 boards.
> > >
> > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > other boards are still using the previous scheme after the series.
> > >
> > > This is very confusing and I really think you should keep u-boot,dm-
> > > pre-reloc in the orange pi dts file and then make the transition with
> > > all the other boards. You're mixing multiple logical steps which makes
> > > it really hard to understand what's going on.
> > >
> > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > should be grouped with your second series, not the first one. In your
> > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > >
> > > Could you respin the two series to group changes by logic changes
> > > instead of the current state of interleaved changes?
> >
> > Okay, to make it clear I can send v4 with v3.1 included and updated
> > commit log. but I the new series about binman remains same since the
> > changes on first patch on the series are relevant.
>
> I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> series currently in v3. You need to remove the patch (currently v3.1)
> from this series and group it with the new series (binman-related).
>
> Otherwise, you're mixing two unrelated logical changes across two
> series.

rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
to untouch Linux dts files and get introduced initial
rk3399-u-boot.dtsi which doesn't effect any board dts files but use
new boards.

rk3399-u-boot.dtsi is required for binman for adding binman changes,
and indeed binman series has some issues which can take time to merge
and other one can do it before.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 15:18                           ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 15:18 UTC (permalink / raw)
  To: u-boot

On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > >
> > > > > > > > Specification
> > > > > > > > - Rockchip RK3399
> > > > > > > > - 2GB/4GB DDR3
> > > > > > > > - 16GB eMMC
> > > > > > > > - SD card slot
> > > > > > >
> > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > >
> > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > >
> > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > >
> > > > Which u-boot,dm-pre-reloc are you taking about?
> > > >
> > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > which were used by subsequent boards on the same series.
> > > >
> > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > existing board dts files thought that it will include
> > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > >
> > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > a subsequent series.
> > > >
> > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > node to make use of new boards.  and the same reused by next series
> > > > so-that I can add binman global to all rk3399 boards.
> > >
> > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > other boards are still using the previous scheme after the series.
> > >
> > > This is very confusing and I really think you should keep u-boot,dm-
> > > pre-reloc in the orange pi dts file and then make the transition with
> > > all the other boards. You're mixing multiple logical steps which makes
> > > it really hard to understand what's going on.
> > >
> > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > should be grouped with your second series, not the first one. In your
> > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > >
> > > Could you respin the two series to group changes by logic changes
> > > instead of the current state of interleaved changes?
> >
> > Okay, to make it clear I can send v4 with v3.1 included and updated
> > commit log. but I the new series about binman remains same since the
> > changes on first patch on the series are relevant.
>
> I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> series currently in v3. You need to remove the patch (currently v3.1)
> from this series and group it with the new series (binman-related).
>
> Otherwise, you're mixing two unrelated logical changes across two
> series.

rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
to untouch Linux dts files and get introduced initial
rk3399-u-boot.dtsi which doesn't effect any board dts files but use
new boards.

rk3399-u-boot.dtsi is required for binman for adding binman changes,
and indeed binman series has some issues which can take time to merge
and other one can do it before.

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 15:18                           ` [U-Boot] " Jagan Teki
@ 2019-04-26 15:38                             ` Paul Kocialkowski
  -1 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 15:38 UTC (permalink / raw)
  To: Jagan Teki; +Cc: U-Boot-Denx, linux-rockchip, Akash Gajjar, linux-amarula

Hi,

Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > 
> > > > > > > > > Specification
> > > > > > > > > - Rockchip RK3399
> > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > - 16GB eMMC
> > > > > > > > > - SD card slot
> > > > > > > > 
> > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > > > 
> > > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > 
> > > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > > > 
> > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > 
> > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > which were used by subsequent boards on the same series.
> > > > > 
> > > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > > existing board dts files thought that it will include
> > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > 
> > > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > > a subsequent series.
> > > > > 
> > > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > > node to make use of new boards.  and the same reused by next series
> > > > > so-that I can add binman global to all rk3399 boards.
> > > > 
> > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > > other boards are still using the previous scheme after the series.
> > > > 
> > > > This is very confusing and I really think you should keep u-boot,dm-
> > > > pre-reloc in the orange pi dts file and then make the transition with
> > > > all the other boards. You're mixing multiple logical steps which makes
> > > > it really hard to understand what's going on.
> > > > 
> > > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > > should be grouped with your second series, not the first one. In your
> > > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > > > 
> > > > Could you respin the two series to group changes by logic changes
> > > > instead of the current state of interleaved changes?
> > > 
> > > Okay, to make it clear I can send v4 with v3.1 included and updated
> > > commit log. but I the new series about binman remains same since the
> > > changes on first patch on the series are relevant.
> > 
> > I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> > series currently in v3. You need to remove the patch (currently v3.1)
> > from this series and group it with the new series (binman-related).
> > 
> > Otherwise, you're mixing two unrelated logical changes across two
> > series.
> 
> rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
> to untouch Linux dts files and get introduced initial
> rk3399-u-boot.dtsi which doesn't effect any board dts files but use
> new boards.

Yes I think I properly understand that now. The problem is that
currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
series, you are introducing the file and including it in the newly-
introduced devices, but not in the previous ones. This is inconsistent.

Then, in the second series, you are moving existing boards to using
rk3399-u-boot.dtsi, except for the boards you introduced in the first
series. This is inconsistent.

Do you see the problem? I feel like you are missing it and only
focusing on the fact that the series works in practice, which is not
the issue.

> rk3399-u-boot.dtsi is required for binman for adding binman changes,
> and indeed binman series has some issues which can take time to merge
> and other one can do it before.

Yes, it can be done before in the first series (so things will not
break), but it should not be done that way for the reason I'm talking
about. Again, the way changes are split and organized is as import as
the technical changes. It's not sufficient that the series works, it
also has to make sense by grouping logical changes.

Cheers,

Paul

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

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 15:38                             ` Paul Kocialkowski
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 15:38 UTC (permalink / raw)
  To: u-boot

Hi,

Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > 
> > > > > > > > > Specification
> > > > > > > > > - Rockchip RK3399
> > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > - 16GB eMMC
> > > > > > > > > - SD card slot
> > > > > > > > 
> > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > > > 
> > > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > 
> > > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > > > 
> > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > 
> > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > which were used by subsequent boards on the same series.
> > > > > 
> > > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > > existing board dts files thought that it will include
> > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > 
> > > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > > a subsequent series.
> > > > > 
> > > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > > node to make use of new boards.  and the same reused by next series
> > > > > so-that I can add binman global to all rk3399 boards.
> > > > 
> > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > > other boards are still using the previous scheme after the series.
> > > > 
> > > > This is very confusing and I really think you should keep u-boot,dm-
> > > > pre-reloc in the orange pi dts file and then make the transition with
> > > > all the other boards. You're mixing multiple logical steps which makes
> > > > it really hard to understand what's going on.
> > > > 
> > > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > > should be grouped with your second series, not the first one. In your
> > > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > > > 
> > > > Could you respin the two series to group changes by logic changes
> > > > instead of the current state of interleaved changes?
> > > 
> > > Okay, to make it clear I can send v4 with v3.1 included and updated
> > > commit log. but I the new series about binman remains same since the
> > > changes on first patch on the series are relevant.
> > 
> > I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> > series currently in v3. You need to remove the patch (currently v3.1)
> > from this series and group it with the new series (binman-related).
> > 
> > Otherwise, you're mixing two unrelated logical changes across two
> > series.
> 
> rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
> to untouch Linux dts files and get introduced initial
> rk3399-u-boot.dtsi which doesn't effect any board dts files but use
> new boards.

Yes I think I properly understand that now. The problem is that
currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
series, you are introducing the file and including it in the newly-
introduced devices, but not in the previous ones. This is inconsistent.

Then, in the second series, you are moving existing boards to using
rk3399-u-boot.dtsi, except for the boards you introduced in the first
series. This is inconsistent.

Do you see the problem? I feel like you are missing it and only
focusing on the fact that the series works in practice, which is not
the issue.

> rk3399-u-boot.dtsi is required for binman for adding binman changes,
> and indeed binman series has some issues which can take time to merge
> and other one can do it before.

Yes, it can be done before in the first series (so things will not
break), but it should not be done that way for the reason I'm talking
about. Again, the way changes are split and organized is as import as
the technical changes. It's not sufficient that the series works, it
also has to make sense by grouping logical changes.

Cheers,

Paul

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 15:38                             ` [U-Boot] " Paul Kocialkowski
@ 2019-04-26 15:48                               ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 15:48 UTC (permalink / raw)
  To: Paul Kocialkowski
  Cc: U-Boot-Denx, linux-rockchip, Akash Gajjar, linux-amarula

On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> > On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > >
> > > > > > > > > > Specification
> > > > > > > > > > - Rockchip RK3399
> > > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > > - 16GB eMMC
> > > > > > > > > > - SD card slot
> > > > > > > > >
> > > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > > > >
> > > > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > >
> > > > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > > > >
> > > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > >
> > > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > > which were used by subsequent boards on the same series.
> > > > > >
> > > > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > > > existing board dts files thought that it will include
> > > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > >
> > > > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > > > a subsequent series.
> > > > > >
> > > > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > > > node to make use of new boards.  and the same reused by next series
> > > > > > so-that I can add binman global to all rk3399 boards.
> > > > >
> > > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > > > other boards are still using the previous scheme after the series.
> > > > >
> > > > > This is very confusing and I really think you should keep u-boot,dm-
> > > > > pre-reloc in the orange pi dts file and then make the transition with
> > > > > all the other boards. You're mixing multiple logical steps which makes
> > > > > it really hard to understand what's going on.
> > > > >
> > > > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > > > should be grouped with your second series, not the first one. In your
> > > > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > > > >
> > > > > Could you respin the two series to group changes by logic changes
> > > > > instead of the current state of interleaved changes?
> > > >
> > > > Okay, to make it clear I can send v4 with v3.1 included and updated
> > > > commit log. but I the new series about binman remains same since the
> > > > changes on first patch on the series are relevant.
> > >
> > > I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> > > series currently in v3. You need to remove the patch (currently v3.1)
> > > from this series and group it with the new series (binman-related).
> > >
> > > Otherwise, you're mixing two unrelated logical changes across two
> > > series.
> >
> > rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
> > to untouch Linux dts files and get introduced initial
> > rk3399-u-boot.dtsi which doesn't effect any board dts files but use
> > new boards.
>
> Yes I think I properly understand that now. The problem is that
> currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
> series, you are introducing the file and including it in the newly-
> introduced devices, but not in the previous ones. This is inconsistent.
>
> Then, in the second series, you are moving existing boards to using
> rk3399-u-boot.dtsi, except for the boards you introduced in the first
> series. This is inconsistent.
>
> Do you see the problem? I feel like you are missing it and only
> focusing on the fact that the series works in practice, which is not
> the issue.

Not again.

First series, I get introduced rk3399-u-boot.dtsi, and only the new
boards are using this file and next series rest of the boards are
using which indeed a valid step. what is inconsistent here, I don't
understand.

>
> > rk3399-u-boot.dtsi is required for binman for adding binman changes,
> > and indeed binman series has some issues which can take time to merge
> > and other one can do it before.
>
> Yes, it can be done before in the first series (so things will not
> break), but it should not be done that way for the reason I'm talking
> about. Again, the way changes are split and organized is as import as
> the technical changes. It's not sufficient that the series works, it
> also has to make sense by grouping logical changes.

Don't agree your point, let me send v4 will see what Philipp and other
can think off.

thanks for your comments,
Jagan.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 15:48                               ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 15:48 UTC (permalink / raw)
  To: u-boot

On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> > On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > >
> > > > > > > > > > Specification
> > > > > > > > > > - Rockchip RK3399
> > > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > > - 16GB eMMC
> > > > > > > > > > - SD card slot
> > > > > > > > >
> > > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > > > >
> > > > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > >
> > > > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > > > >
> > > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > >
> > > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > > which were used by subsequent boards on the same series.
> > > > > >
> > > > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > > > existing board dts files thought that it will include
> > > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > >
> > > > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > > > a subsequent series.
> > > > > >
> > > > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > > > node to make use of new boards.  and the same reused by next series
> > > > > > so-that I can add binman global to all rk3399 boards.
> > > > >
> > > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > > > other boards are still using the previous scheme after the series.
> > > > >
> > > > > This is very confusing and I really think you should keep u-boot,dm-
> > > > > pre-reloc in the orange pi dts file and then make the transition with
> > > > > all the other boards. You're mixing multiple logical steps which makes
> > > > > it really hard to understand what's going on.
> > > > >
> > > > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > > > should be grouped with your second series, not the first one. In your
> > > > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > > > >
> > > > > Could you respin the two series to group changes by logic changes
> > > > > instead of the current state of interleaved changes?
> > > >
> > > > Okay, to make it clear I can send v4 with v3.1 included and updated
> > > > commit log. but I the new series about binman remains same since the
> > > > changes on first patch on the series are relevant.
> > >
> > > I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> > > series currently in v3. You need to remove the patch (currently v3.1)
> > > from this series and group it with the new series (binman-related).
> > >
> > > Otherwise, you're mixing two unrelated logical changes across two
> > > series.
> >
> > rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
> > to untouch Linux dts files and get introduced initial
> > rk3399-u-boot.dtsi which doesn't effect any board dts files but use
> > new boards.
>
> Yes I think I properly understand that now. The problem is that
> currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
> series, you are introducing the file and including it in the newly-
> introduced devices, but not in the previous ones. This is inconsistent.
>
> Then, in the second series, you are moving existing boards to using
> rk3399-u-boot.dtsi, except for the boards you introduced in the first
> series. This is inconsistent.
>
> Do you see the problem? I feel like you are missing it and only
> focusing on the fact that the series works in practice, which is not
> the issue.

Not again.

First series, I get introduced rk3399-u-boot.dtsi, and only the new
boards are using this file and next series rest of the boards are
using which indeed a valid step. what is inconsistent here, I don't
understand.

>
> > rk3399-u-boot.dtsi is required for binman for adding binman changes,
> > and indeed binman series has some issues which can take time to merge
> > and other one can do it before.
>
> Yes, it can be done before in the first series (so things will not
> break), but it should not be done that way for the reason I'm talking
> about. Again, the way changes are split and organized is as import as
> the technical changes. It's not sufficient that the series works, it
> also has to make sense by grouping logical changes.

Don't agree your point, let me send v4 will see what Philipp and other
can think off.

thanks for your comments,
Jagan.

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 15:48                               ` [U-Boot] " Jagan Teki
@ 2019-04-26 16:08                                 ` Paul Kocialkowski
  -1 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 16:08 UTC (permalink / raw)
  To: Jagan Teki; +Cc: U-Boot-Denx, linux-rockchip, Akash Gajjar, linux-amarula

Hi,

Le vendredi 26 avril 2019 à 21:18 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> > > On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > > > 
> > > > > > > > > > > Specification
> > > > > > > > > > > - Rockchip RK3399
> > > > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > > > - 16GB eMMC
> > > > > > > > > > > - SD card slot
> > > > > > > > > > 
> > > > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > > > > > 
> > > > > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > > > 
> > > > > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > > > > > 
> > > > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > > > 
> > > > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > > > which were used by subsequent boards on the same series.
> > > > > > > 
> > > > > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > > > > existing board dts files thought that it will include
> > > > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > > > 
> > > > > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > > > > a subsequent series.
> > > > > > > 
> > > > > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > > > > node to make use of new boards.  and the same reused by next series
> > > > > > > so-that I can add binman global to all rk3399 boards.
> > > > > > 
> > > > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > > > > other boards are still using the previous scheme after the series.
> > > > > > 
> > > > > > This is very confusing and I really think you should keep u-boot,dm-
> > > > > > pre-reloc in the orange pi dts file and then make the transition with
> > > > > > all the other boards. You're mixing multiple logical steps which makes
> > > > > > it really hard to understand what's going on.
> > > > > > 
> > > > > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > > > > should be grouped with your second series, not the first one. In your
> > > > > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > > > > > 
> > > > > > Could you respin the two series to group changes by logic changes
> > > > > > instead of the current state of interleaved changes?
> > > > > 
> > > > > Okay, to make it clear I can send v4 with v3.1 included and updated
> > > > > commit log. but I the new series about binman remains same since the
> > > > > changes on first patch on the series are relevant.
> > > > 
> > > > I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> > > > series currently in v3. You need to remove the patch (currently v3.1)
> > > > from this series and group it with the new series (binman-related).
> > > > 
> > > > Otherwise, you're mixing two unrelated logical changes across two
> > > > series.
> > > 
> > > rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
> > > to untouch Linux dts files and get introduced initial
> > > rk3399-u-boot.dtsi which doesn't effect any board dts files but use
> > > new boards.
> > 
> > Yes I think I properly understand that now. The problem is that
> > currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
> > series, you are introducing the file and including it in the newly-
> > introduced devices, but not in the previous ones. This is inconsistent.
> > 
> > Then, in the second series, you are moving existing boards to using
> > rk3399-u-boot.dtsi, except for the boards you introduced in the first
> > series. This is inconsistent.
> > 
> > Do you see the problem? I feel like you are missing it and only
> > focusing on the fact that the series works in practice, which is not
> > the issue.
> 
> Not again.
> 
> First series, I get introduced rk3399-u-boot.dtsi, and only the new
> boards are using this file and next series rest of the boards are
> using which indeed a valid step. what is inconsistent here, I don't
> understand.

Yes, what you are describing is exactly the issue. It does not make
sense to introduce a new common u-boot dtsi for rk3399 and add new
devices that use this file *before* switching existing devices to the
new common u-boot dtsi for rk3399 in the same series.

Globally with your series, you are doing 3 things:
- Introducing a common RK3399 u-boot dtsi with the required pre-reloc
entries;
- Adding new RK3399 devices and syncing the dtsi files from Linux;
- Introducing u-boot-rockchip-with-spl.bin.

So it should be 3 distinct series, not two. As you can see, you can
either do step 1 and then step 2 or step 2 and then step 1, but you
cannot mix parts of step 1 into step 2 and vice-versa.

Is it clearer explained this way?

Cheers,

Paul

> > > rk3399-u-boot.dtsi is required for binman for adding binman changes,
> > > and indeed binman series has some issues which can take time to merge
> > > and other one can do it before.
> > 
> > Yes, it can be done before in the first series (so things will not
> > break), but it should not be done that way for the reason I'm talking
> > about. Again, the way changes are split and organized is as import as
> > the technical changes. It's not sufficient that the series works, it
> > also has to make sense by grouping logical changes.
> 
> Don't agree your point, let me send v4 will see what Philipp and other
> can think off.
> 
> thanks for your comments,
> Jagan.

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

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 16:08                                 ` Paul Kocialkowski
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 16:08 UTC (permalink / raw)
  To: u-boot

Hi,

Le vendredi 26 avril 2019 à 21:18 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> > > On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > > > 
> > > > > > > > > > > Specification
> > > > > > > > > > > - Rockchip RK3399
> > > > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > > > - 16GB eMMC
> > > > > > > > > > > - SD card slot
> > > > > > > > > > 
> > > > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > > > > > 
> > > > > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > > > 
> > > > > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > > > > > 
> > > > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > > > 
> > > > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > > > which were used by subsequent boards on the same series.
> > > > > > > 
> > > > > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > > > > existing board dts files thought that it will include
> > > > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > > > 
> > > > > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > > > > a subsequent series.
> > > > > > > 
> > > > > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > > > > node to make use of new boards.  and the same reused by next series
> > > > > > > so-that I can add binman global to all rk3399 boards.
> > > > > > 
> > > > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > > > > other boards are still using the previous scheme after the series.
> > > > > > 
> > > > > > This is very confusing and I really think you should keep u-boot,dm-
> > > > > > pre-reloc in the orange pi dts file and then make the transition with
> > > > > > all the other boards. You're mixing multiple logical steps which makes
> > > > > > it really hard to understand what's going on.
> > > > > > 
> > > > > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > > > > should be grouped with your second series, not the first one. In your
> > > > > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > > > > > 
> > > > > > Could you respin the two series to group changes by logic changes
> > > > > > instead of the current state of interleaved changes?
> > > > > 
> > > > > Okay, to make it clear I can send v4 with v3.1 included and updated
> > > > > commit log. but I the new series about binman remains same since the
> > > > > changes on first patch on the series are relevant.
> > > > 
> > > > I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> > > > series currently in v3. You need to remove the patch (currently v3.1)
> > > > from this series and group it with the new series (binman-related).
> > > > 
> > > > Otherwise, you're mixing two unrelated logical changes across two
> > > > series.
> > > 
> > > rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
> > > to untouch Linux dts files and get introduced initial
> > > rk3399-u-boot.dtsi which doesn't effect any board dts files but use
> > > new boards.
> > 
> > Yes I think I properly understand that now. The problem is that
> > currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
> > series, you are introducing the file and including it in the newly-
> > introduced devices, but not in the previous ones. This is inconsistent.
> > 
> > Then, in the second series, you are moving existing boards to using
> > rk3399-u-boot.dtsi, except for the boards you introduced in the first
> > series. This is inconsistent.
> > 
> > Do you see the problem? I feel like you are missing it and only
> > focusing on the fact that the series works in practice, which is not
> > the issue.
> 
> Not again.
> 
> First series, I get introduced rk3399-u-boot.dtsi, and only the new
> boards are using this file and next series rest of the boards are
> using which indeed a valid step. what is inconsistent here, I don't
> understand.

Yes, what you are describing is exactly the issue. It does not make
sense to introduce a new common u-boot dtsi for rk3399 and add new
devices that use this file *before* switching existing devices to the
new common u-boot dtsi for rk3399 in the same series.

Globally with your series, you are doing 3 things:
- Introducing a common RK3399 u-boot dtsi with the required pre-reloc
entries;
- Adding new RK3399 devices and syncing the dtsi files from Linux;
- Introducing u-boot-rockchip-with-spl.bin.

So it should be 3 distinct series, not two. As you can see, you can
either do step 1 and then step 2 or step 2 and then step 1, but you
cannot mix parts of step 1 into step 2 and vice-versa.

Is it clearer explained this way?

Cheers,

Paul

> > > rk3399-u-boot.dtsi is required for binman for adding binman changes,
> > > and indeed binman series has some issues which can take time to merge
> > > and other one can do it before.
> > 
> > Yes, it can be done before in the first series (so things will not
> > break), but it should not be done that way for the reason I'm talking
> > about. Again, the way changes are split and organized is as import as
> > the technical changes. It's not sufficient that the series works, it
> > also has to make sense by grouping logical changes.
> 
> Don't agree your point, let me send v4 will see what Philipp and other
> can think off.
> 
> thanks for your comments,
> Jagan.

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 16:08                                 ` [U-Boot] " Paul Kocialkowski
@ 2019-04-26 16:09                                   ` Philipp Tomsich
  -1 siblings, 0 replies; 72+ messages in thread
From: Philipp Tomsich @ 2019-04-26 16:09 UTC (permalink / raw)
  To: Paul Kocialkowski
  Cc: U-Boot-Denx, linux-rockchip, linux-amarula, Akash Gajjar



> On 26.04.2019, at 18:08, Paul Kocialkowski <paul.kocialkowski@bootlin.com> wrote:
> 
> Hi,
> 
> Le vendredi 26 avril 2019 à 21:18 +0530, Jagan Teki a écrit :
>> On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
>> <paul.kocialkowski@bootlin.com> wrote:
>>> Hi,
>>> 
>>> Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
>>>> On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
>>>> <paul.kocialkowski@bootlin.com> wrote:
>>>>> Hi,
>>>>> 
>>>>> On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
>>>>>> On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
>>>>>> <paul.kocialkowski@bootlin.com> wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
>>>>>>>> On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
>>>>>>>> <paul.kocialkowski@bootlin.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
>>>>>>>>>> On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
>>>>>>>>>> <paul.kocialkowski@bootlin.com> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
>>>>>>>>>>>> Add initial support for Orangepi RK3399 board.
>>>>>>>>>>>> 
>>>>>>>>>>>> Specification
>>>>>>>>>>>> - Rockchip RK3399
>>>>>>>>>>>> - 2GB/4GB DDR3
>>>>>>>>>>>> - 16GB eMMC
>>>>>>>>>>>> - SD card slot
>>>>>>>>>>> 
>>>>>>>>>>> Looks like you're missing u-boot,dm-pre-reloc to have it working, which
>>>>>>>>>>> will need to be introduced when moving to rk3399-u-boot.dtsi.
>>>>>>>>>> 
>>>>>>>>>> Look like you are confused or doesn't check the patch. This patch have
>>>>>>>>>> rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
>>>>>>>>>> u-boot,dm-pre-reloc for sdmmc.
>>>>>>>>> 
>>>>>>>>> Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
>>>>>>>>> rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
>>>>>>>>> it in your second series when you add it back to rk3399-u-boot.dtsi.
>>>>>>>> 
>>>>>>>> Which u-boot,dm-pre-reloc are you taking about?
>>>>>>>> 
>>>>>>>> v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
>>>>>>>> which were used by subsequent boards on the same series.
>>>>>>>> 
>>>>>>>> The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
>>>>>>>> existing board dts files thought that it will include
>>>>>>>> rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
>>>>>>>> 
>>>>>>>>> It's not okay to submit the board with broken MMC support and fix it in
>>>>>>>>> a subsequent series.
>>>>>>>> 
>>>>>>>> Again, nothing broken. existing boards or dts(i) files are untouched.
>>>>>>>> Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
>>>>>>>> node to make use of new boards.  and the same reused by next series
>>>>>>>> so-that I can add binman global to all rk3399 boards.
>>>>>>> 
>>>>>>> Okay I think I'm getting there. So the Orangepi uses the new scheme
>>>>>>> (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
>>>>>>> other boards are still using the previous scheme after the series.
>>>>>>> 
>>>>>>> This is very confusing and I really think you should keep u-boot,dm-
>>>>>>> pre-reloc in the orange pi dts file and then make the transition with
>>>>>>> all the other boards. You're mixing multiple logical steps which makes
>>>>>>> it really hard to understand what's going on.
>>>>>>> 
>>>>>>> More to that, introducing the rk3399-u-boot.dtsi is a logical step that
>>>>>>> should be grouped with your second series, not the first one. In your
>>>>>>> first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
>>>>>>> 
>>>>>>> Could you respin the two series to group changes by logic changes
>>>>>>> instead of the current state of interleaved changes?
>>>>>> 
>>>>>> Okay, to make it clear I can send v4 with v3.1 included and updated
>>>>>> commit log. but I the new series about binman remains same since the
>>>>>> changes on first patch on the series are relevant.
>>>>> 
>>>>> I think it makes no sense to introduce rk3399-u-boot.dts as part of the
>>>>> series currently in v3. You need to remove the patch (currently v3.1)
>>>>> from this series and group it with the new series (binman-related).
>>>>> 
>>>>> Otherwise, you're mixing two unrelated logical changes across two
>>>>> series.
>>>> 
>>>> rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
>>>> to untouch Linux dts files and get introduced initial
>>>> rk3399-u-boot.dtsi which doesn't effect any board dts files but use
>>>> new boards.
>>> 
>>> Yes I think I properly understand that now. The problem is that
>>> currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
>>> series, you are introducing the file and including it in the newly-
>>> introduced devices, but not in the previous ones. This is inconsistent.
>>> 
>>> Then, in the second series, you are moving existing boards to using
>>> rk3399-u-boot.dtsi, except for the boards you introduced in the first
>>> series. This is inconsistent.
>>> 
>>> Do you see the problem? I feel like you are missing it and only
>>> focusing on the fact that the series works in practice, which is not
>>> the issue.
>> 
>> Not again.
>> 
>> First series, I get introduced rk3399-u-boot.dtsi, and only the new
>> boards are using this file and next series rest of the boards are
>> using which indeed a valid step. what is inconsistent here, I don't
>> understand.
> 
> Yes, what you are describing is exactly the issue. It does not make
> sense to introduce a new common u-boot dtsi for rk3399 and add new
> devices that use this file *before* switching existing devices to the
> new common u-boot dtsi for rk3399 in the same series.

I am with Paul on this one.

Thanks,
Philipp.

> 
> Globally with your series, you are doing 3 things:
> - Introducing a common RK3399 u-boot dtsi with the required pre-reloc
> entries;
> - Adding new RK3399 devices and syncing the dtsi files from Linux;
> - Introducing u-boot-rockchip-with-spl.bin.
> 
> So it should be 3 distinct series, not two. As you can see, you can
> either do step 1 and then step 2 or step 2 and then step 1, but you
> cannot mix parts of step 1 into step 2 and vice-versa.
> 
> Is it clearer explained this way?
> 
> Cheers,
> 
> Paul
> 
>>>> rk3399-u-boot.dtsi is required for binman for adding binman changes,
>>>> and indeed binman series has some issues which can take time to merge
>>>> and other one can do it before.
>>> 
>>> Yes, it can be done before in the first series (so things will not
>>> break), but it should not be done that way for the reason I'm talking
>>> about. Again, the way changes are split and organized is as import as
>>> the technical changes. It's not sufficient that the series works, it
>>> also has to make sense by grouping logical changes.
>> 
>> Don't agree your point, let me send v4 will see what Philipp and other
>> can think off.
>> 
>> thanks for your comments,
>> Jagan.

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

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 16:09                                   ` Philipp Tomsich
  0 siblings, 0 replies; 72+ messages in thread
From: Philipp Tomsich @ 2019-04-26 16:09 UTC (permalink / raw)
  To: u-boot



> On 26.04.2019, at 18:08, Paul Kocialkowski <paul.kocialkowski@bootlin.com> wrote:
> 
> Hi,
> 
> Le vendredi 26 avril 2019 à 21:18 +0530, Jagan Teki a écrit :
>> On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
>> <paul.kocialkowski@bootlin.com> wrote:
>>> Hi,
>>> 
>>> Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
>>>> On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
>>>> <paul.kocialkowski@bootlin.com> wrote:
>>>>> Hi,
>>>>> 
>>>>> On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
>>>>>> On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
>>>>>> <paul.kocialkowski@bootlin.com> wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
>>>>>>>> On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
>>>>>>>> <paul.kocialkowski@bootlin.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
>>>>>>>>>> On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
>>>>>>>>>> <paul.kocialkowski@bootlin.com> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
>>>>>>>>>>>> Add initial support for Orangepi RK3399 board.
>>>>>>>>>>>> 
>>>>>>>>>>>> Specification
>>>>>>>>>>>> - Rockchip RK3399
>>>>>>>>>>>> - 2GB/4GB DDR3
>>>>>>>>>>>> - 16GB eMMC
>>>>>>>>>>>> - SD card slot
>>>>>>>>>>> 
>>>>>>>>>>> Looks like you're missing u-boot,dm-pre-reloc to have it working, which
>>>>>>>>>>> will need to be introduced when moving to rk3399-u-boot.dtsi.
>>>>>>>>>> 
>>>>>>>>>> Look like you are confused or doesn't check the patch. This patch have
>>>>>>>>>> rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
>>>>>>>>>> u-boot,dm-pre-reloc for sdmmc.
>>>>>>>>> 
>>>>>>>>> Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
>>>>>>>>> rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
>>>>>>>>> it in your second series when you add it back to rk3399-u-boot.dtsi.
>>>>>>>> 
>>>>>>>> Which u-boot,dm-pre-reloc are you taking about?
>>>>>>>> 
>>>>>>>> v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
>>>>>>>> which were used by subsequent boards on the same series.
>>>>>>>> 
>>>>>>>> The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
>>>>>>>> existing board dts files thought that it will include
>>>>>>>> rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
>>>>>>>> 
>>>>>>>>> It's not okay to submit the board with broken MMC support and fix it in
>>>>>>>>> a subsequent series.
>>>>>>>> 
>>>>>>>> Again, nothing broken. existing boards or dts(i) files are untouched.
>>>>>>>> Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
>>>>>>>> node to make use of new boards.  and the same reused by next series
>>>>>>>> so-that I can add binman global to all rk3399 boards.
>>>>>>> 
>>>>>>> Okay I think I'm getting there. So the Orangepi uses the new scheme
>>>>>>> (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
>>>>>>> other boards are still using the previous scheme after the series.
>>>>>>> 
>>>>>>> This is very confusing and I really think you should keep u-boot,dm-
>>>>>>> pre-reloc in the orange pi dts file and then make the transition with
>>>>>>> all the other boards. You're mixing multiple logical steps which makes
>>>>>>> it really hard to understand what's going on.
>>>>>>> 
>>>>>>> More to that, introducing the rk3399-u-boot.dtsi is a logical step that
>>>>>>> should be grouped with your second series, not the first one. In your
>>>>>>> first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
>>>>>>> 
>>>>>>> Could you respin the two series to group changes by logic changes
>>>>>>> instead of the current state of interleaved changes?
>>>>>> 
>>>>>> Okay, to make it clear I can send v4 with v3.1 included and updated
>>>>>> commit log. but I the new series about binman remains same since the
>>>>>> changes on first patch on the series are relevant.
>>>>> 
>>>>> I think it makes no sense to introduce rk3399-u-boot.dts as part of the
>>>>> series currently in v3. You need to remove the patch (currently v3.1)
>>>>> from this series and group it with the new series (binman-related).
>>>>> 
>>>>> Otherwise, you're mixing two unrelated logical changes across two
>>>>> series.
>>>> 
>>>> rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
>>>> to untouch Linux dts files and get introduced initial
>>>> rk3399-u-boot.dtsi which doesn't effect any board dts files but use
>>>> new boards.
>>> 
>>> Yes I think I properly understand that now. The problem is that
>>> currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
>>> series, you are introducing the file and including it in the newly-
>>> introduced devices, but not in the previous ones. This is inconsistent.
>>> 
>>> Then, in the second series, you are moving existing boards to using
>>> rk3399-u-boot.dtsi, except for the boards you introduced in the first
>>> series. This is inconsistent.
>>> 
>>> Do you see the problem? I feel like you are missing it and only
>>> focusing on the fact that the series works in practice, which is not
>>> the issue.
>> 
>> Not again.
>> 
>> First series, I get introduced rk3399-u-boot.dtsi, and only the new
>> boards are using this file and next series rest of the boards are
>> using which indeed a valid step. what is inconsistent here, I don't
>> understand.
> 
> Yes, what you are describing is exactly the issue. It does not make
> sense to introduce a new common u-boot dtsi for rk3399 and add new
> devices that use this file *before* switching existing devices to the
> new common u-boot dtsi for rk3399 in the same series.

I am with Paul on this one.

Thanks,
Philipp.

> 
> Globally with your series, you are doing 3 things:
> - Introducing a common RK3399 u-boot dtsi with the required pre-reloc
> entries;
> - Adding new RK3399 devices and syncing the dtsi files from Linux;
> - Introducing u-boot-rockchip-with-spl.bin.
> 
> So it should be 3 distinct series, not two. As you can see, you can
> either do step 1 and then step 2 or step 2 and then step 1, but you
> cannot mix parts of step 1 into step 2 and vice-versa.
> 
> Is it clearer explained this way?
> 
> Cheers,
> 
> Paul
> 
>>>> rk3399-u-boot.dtsi is required for binman for adding binman changes,
>>>> and indeed binman series has some issues which can take time to merge
>>>> and other one can do it before.
>>> 
>>> Yes, it can be done before in the first series (so things will not
>>> break), but it should not be done that way for the reason I'm talking
>>> about. Again, the way changes are split and organized is as import as
>>> the technical changes. It's not sufficient that the series works, it
>>> also has to make sense by grouping logical changes.
>> 
>> Don't agree your point, let me send v4 will see what Philipp and other
>> can think off.
>> 
>> thanks for your comments,
>> Jagan.

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 16:08                                 ` [U-Boot] " Paul Kocialkowski
@ 2019-04-26 16:16                                     ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 16:16 UTC (permalink / raw)
  To: Paul Kocialkowski
  Cc: U-Boot-Denx, Simon Glass, Kever Yang,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Akash Gajjar,
	Philipp Tomsich, linux-amarula

On Fri, Apr 26, 2019 at 9:38 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> Le vendredi 26 avril 2019 à 21:18 +0530, Jagan Teki a écrit :
> > On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> > > > On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > > > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > > > >
> > > > > > > > > > > > Specification
> > > > > > > > > > > > - Rockchip RK3399
> > > > > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > > > > - 16GB eMMC
> > > > > > > > > > > > - SD card slot
> > > > > > > > > > >
> > > > > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > > > > > >
> > > > > > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > > > >
> > > > > > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > > > > > >
> > > > > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > > > >
> > > > > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > > > > which were used by subsequent boards on the same series.
> > > > > > > >
> > > > > > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > > > > > existing board dts files thought that it will include
> > > > > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > > > >
> > > > > > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > > > > > a subsequent series.
> > > > > > > >
> > > > > > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > > > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > > > > > node to make use of new boards.  and the same reused by next series
> > > > > > > > so-that I can add binman global to all rk3399 boards.
> > > > > > >
> > > > > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > > > > > other boards are still using the previous scheme after the series.
> > > > > > >
> > > > > > > This is very confusing and I really think you should keep u-boot,dm-
> > > > > > > pre-reloc in the orange pi dts file and then make the transition with
> > > > > > > all the other boards. You're mixing multiple logical steps which makes
> > > > > > > it really hard to understand what's going on.
> > > > > > >
> > > > > > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > > > > > should be grouped with your second series, not the first one. In your
> > > > > > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > > > > > >
> > > > > > > Could you respin the two series to group changes by logic changes
> > > > > > > instead of the current state of interleaved changes?
> > > > > >
> > > > > > Okay, to make it clear I can send v4 with v3.1 included and updated
> > > > > > commit log. but I the new series about binman remains same since the
> > > > > > changes on first patch on the series are relevant.
> > > > >
> > > > > I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> > > > > series currently in v3. You need to remove the patch (currently v3.1)
> > > > > from this series and group it with the new series (binman-related).
> > > > >
> > > > > Otherwise, you're mixing two unrelated logical changes across two
> > > > > series.
> > > >
> > > > rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
> > > > to untouch Linux dts files and get introduced initial
> > > > rk3399-u-boot.dtsi which doesn't effect any board dts files but use
> > > > new boards.
> > >
> > > Yes I think I properly understand that now. The problem is that
> > > currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
> > > series, you are introducing the file and including it in the newly-
> > > introduced devices, but not in the previous ones. This is inconsistent.
> > >
> > > Then, in the second series, you are moving existing boards to using
> > > rk3399-u-boot.dtsi, except for the boards you introduced in the first
> > > series. This is inconsistent.
> > >
> > > Do you see the problem? I feel like you are missing it and only
> > > focusing on the fact that the series works in practice, which is not
> > > the issue.
> >
> > Not again.
> >
> > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > boards are using this file and next series rest of the boards are
> > using which indeed a valid step. what is inconsistent here, I don't
> > understand.
>
> Yes, what you are describing is exactly the issue. It does not make
> sense to introduce a new common u-boot dtsi for rk3399 and add new
> devices that use this file *before* switching existing devices to the
> new common u-boot dtsi for rk3399 in the same series.

How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
patch says it is an initial one and it is bit hard to add all at once.
ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
unaffected to any of the existing dts files.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 16:16                                     ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 16:16 UTC (permalink / raw)
  To: u-boot

On Fri, Apr 26, 2019 at 9:38 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> Le vendredi 26 avril 2019 à 21:18 +0530, Jagan Teki a écrit :
> > On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> > > > On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > > > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > > > >
> > > > > > > > > > > > Specification
> > > > > > > > > > > > - Rockchip RK3399
> > > > > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > > > > - 16GB eMMC
> > > > > > > > > > > > - SD card slot
> > > > > > > > > > >
> > > > > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > > > > > >
> > > > > > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > > > >
> > > > > > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > > > > > >
> > > > > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > > > >
> > > > > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > > > > which were used by subsequent boards on the same series.
> > > > > > > >
> > > > > > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > > > > > existing board dts files thought that it will include
> > > > > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > > > >
> > > > > > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > > > > > a subsequent series.
> > > > > > > >
> > > > > > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > > > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > > > > > node to make use of new boards.  and the same reused by next series
> > > > > > > > so-that I can add binman global to all rk3399 boards.
> > > > > > >
> > > > > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > > > > > other boards are still using the previous scheme after the series.
> > > > > > >
> > > > > > > This is very confusing and I really think you should keep u-boot,dm-
> > > > > > > pre-reloc in the orange pi dts file and then make the transition with
> > > > > > > all the other boards. You're mixing multiple logical steps which makes
> > > > > > > it really hard to understand what's going on.
> > > > > > >
> > > > > > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > > > > > should be grouped with your second series, not the first one. In your
> > > > > > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > > > > > >
> > > > > > > Could you respin the two series to group changes by logic changes
> > > > > > > instead of the current state of interleaved changes?
> > > > > >
> > > > > > Okay, to make it clear I can send v4 with v3.1 included and updated
> > > > > > commit log. but I the new series about binman remains same since the
> > > > > > changes on first patch on the series are relevant.
> > > > >
> > > > > I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> > > > > series currently in v3. You need to remove the patch (currently v3.1)
> > > > > from this series and group it with the new series (binman-related).
> > > > >
> > > > > Otherwise, you're mixing two unrelated logical changes across two
> > > > > series.
> > > >
> > > > rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
> > > > to untouch Linux dts files and get introduced initial
> > > > rk3399-u-boot.dtsi which doesn't effect any board dts files but use
> > > > new boards.
> > >
> > > Yes I think I properly understand that now. The problem is that
> > > currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
> > > series, you are introducing the file and including it in the newly-
> > > introduced devices, but not in the previous ones. This is inconsistent.
> > >
> > > Then, in the second series, you are moving existing boards to using
> > > rk3399-u-boot.dtsi, except for the boards you introduced in the first
> > > series. This is inconsistent.
> > >
> > > Do you see the problem? I feel like you are missing it and only
> > > focusing on the fact that the series works in practice, which is not
> > > the issue.
> >
> > Not again.
> >
> > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > boards are using this file and next series rest of the boards are
> > using which indeed a valid step. what is inconsistent here, I don't
> > understand.
>
> Yes, what you are describing is exactly the issue. It does not make
> sense to introduce a new common u-boot dtsi for rk3399 and add new
> devices that use this file *before* switching existing devices to the
> new common u-boot dtsi for rk3399 in the same series.

How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
patch says it is an initial one and it is bit hard to add all at once.
ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
unaffected to any of the existing dts files.

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 16:16                                     ` [U-Boot] " Jagan Teki
@ 2019-04-26 16:40                                       ` Paul Kocialkowski
  -1 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 16:40 UTC (permalink / raw)
  To: Jagan Teki; +Cc: U-Boot-Denx, linux-rockchip, Akash Gajjar, linux-amarula

Hi,

Le vendredi 26 avril 2019 à 21:46 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 9:38 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > Le vendredi 26 avril 2019 à 21:18 +0530, Jagan Teki a écrit :
> > > On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> > > > > On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > > > > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > > > Hi,
> > > > > > > > > > > > 
> > > > > > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Specification
> > > > > > > > > > > > > - Rockchip RK3399
> > > > > > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > > > > > - 16GB eMMC
> > > > > > > > > > > > > - SD card slot
> > > > > > > > > > > > 
> > > > > > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > > > > > > > 
> > > > > > > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > > > > > 
> > > > > > > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > > > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > > > > > > > 
> > > > > > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > > > > > 
> > > > > > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > > > > > which were used by subsequent boards on the same series.
> > > > > > > > > 
> > > > > > > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > > > > > > existing board dts files thought that it will include
> > > > > > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > > > > > 
> > > > > > > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > > > > > > a subsequent series.
> > > > > > > > > 
> > > > > > > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > > > > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > > > > > > node to make use of new boards.  and the same reused by next series
> > > > > > > > > so-that I can add binman global to all rk3399 boards.
> > > > > > > > 
> > > > > > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > > > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > > > > > > other boards are still using the previous scheme after the series.
> > > > > > > > 
> > > > > > > > This is very confusing and I really think you should keep u-boot,dm-
> > > > > > > > pre-reloc in the orange pi dts file and then make the transition with
> > > > > > > > all the other boards. You're mixing multiple logical steps which makes
> > > > > > > > it really hard to understand what's going on.
> > > > > > > > 
> > > > > > > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > > > > > > should be grouped with your second series, not the first one. In your
> > > > > > > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > > > > > > > 
> > > > > > > > Could you respin the two series to group changes by logic changes
> > > > > > > > instead of the current state of interleaved changes?
> > > > > > > 
> > > > > > > Okay, to make it clear I can send v4 with v3.1 included and updated
> > > > > > > commit log. but I the new series about binman remains same since the
> > > > > > > changes on first patch on the series are relevant.
> > > > > > 
> > > > > > I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> > > > > > series currently in v3. You need to remove the patch (currently v3.1)
> > > > > > from this series and group it with the new series (binman-related).
> > > > > > 
> > > > > > Otherwise, you're mixing two unrelated logical changes across two
> > > > > > series.
> > > > > 
> > > > > rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
> > > > > to untouch Linux dts files and get introduced initial
> > > > > rk3399-u-boot.dtsi which doesn't effect any board dts files but use
> > > > > new boards.
> > > > 
> > > > Yes I think I properly understand that now. The problem is that
> > > > currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
> > > > series, you are introducing the file and including it in the newly-
> > > > introduced devices, but not in the previous ones. This is inconsistent.
> > > > 
> > > > Then, in the second series, you are moving existing boards to using
> > > > rk3399-u-boot.dtsi, except for the boards you introduced in the first
> > > > series. This is inconsistent.
> > > > 
> > > > Do you see the problem? I feel like you are missing it and only
> > > > focusing on the fact that the series works in practice, which is not
> > > > the issue.
> > > 
> > > Not again.
> > > 
> > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > boards are using this file and next series rest of the boards are
> > > using which indeed a valid step. what is inconsistent here, I don't
> > > understand.
> > 
> > Yes, what you are describing is exactly the issue. It does not make
> > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > devices that use this file *before* switching existing devices to the
> > new common u-boot dtsi for rk3399 in the same series.
> 
> How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> patch says it is an initial one and it is bit hard to add all at once.
> ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> unaffected to any of the existing dts files.

Again, it's not a technical issue. Your proposal works and has no
technical issue. The issue is in how the commits are grouped together.
Patch series need to make logical sense. One patch series should
accomplish one change, and each patch represents a step of that change.

This is how upstream contributions work, and it's a powerful way to
allow both efficient code review and good code quality. We want to keep
things as simple, explicit and well-described as possible, so that
things are easy for reviewers and as many people as possible can
understand the issue and share their thoughts about it.

It is all part of communication with others as part of a community.
It is definitely an implicit rule that is not written down somewhere
precisely, but that's the social contract between developers that work
on a common software project.

In that, contributing to upstream is different than baseline tech
company standards, because you have to take extra steps to describe
your work and explain it to others. You must make sure you give them
all the comfort they need to painlessly understand what you did.

It plays a great deal in having series accepted without going through
very long discussions and numerous iterations. The less questions
maintainers will have about your work, the better. They may disagree
with the decisions you took, but these discussions are purely technical
and can be resolved quickly.

It's basically that: you have to make sure everything is explained and
easy to understand so that the discussions will only be about the
choices you made and not trying to understand why you had to make these
choices.

Cheers,

Paul

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

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 16:40                                       ` Paul Kocialkowski
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 16:40 UTC (permalink / raw)
  To: u-boot

Hi,

Le vendredi 26 avril 2019 à 21:46 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 9:38 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > Le vendredi 26 avril 2019 à 21:18 +0530, Jagan Teki a écrit :
> > > On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> > > > > On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > > > > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > Hi,
> > > > > > > > > > 
> > > > > > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > > > Hi,
> > > > > > > > > > > > 
> > > > > > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Specification
> > > > > > > > > > > > > - Rockchip RK3399
> > > > > > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > > > > > - 16GB eMMC
> > > > > > > > > > > > > - SD card slot
> > > > > > > > > > > > 
> > > > > > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > > > > > > > 
> > > > > > > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > > > > > 
> > > > > > > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > > > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > > > > > > > 
> > > > > > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > > > > > 
> > > > > > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > > > > > which were used by subsequent boards on the same series.
> > > > > > > > > 
> > > > > > > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > > > > > > existing board dts files thought that it will include
> > > > > > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > > > > > 
> > > > > > > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > > > > > > a subsequent series.
> > > > > > > > > 
> > > > > > > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > > > > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > > > > > > node to make use of new boards.  and the same reused by next series
> > > > > > > > > so-that I can add binman global to all rk3399 boards.
> > > > > > > > 
> > > > > > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > > > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > > > > > > other boards are still using the previous scheme after the series.
> > > > > > > > 
> > > > > > > > This is very confusing and I really think you should keep u-boot,dm-
> > > > > > > > pre-reloc in the orange pi dts file and then make the transition with
> > > > > > > > all the other boards. You're mixing multiple logical steps which makes
> > > > > > > > it really hard to understand what's going on.
> > > > > > > > 
> > > > > > > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > > > > > > should be grouped with your second series, not the first one. In your
> > > > > > > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > > > > > > > 
> > > > > > > > Could you respin the two series to group changes by logic changes
> > > > > > > > instead of the current state of interleaved changes?
> > > > > > > 
> > > > > > > Okay, to make it clear I can send v4 with v3.1 included and updated
> > > > > > > commit log. but I the new series about binman remains same since the
> > > > > > > changes on first patch on the series are relevant.
> > > > > > 
> > > > > > I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> > > > > > series currently in v3. You need to remove the patch (currently v3.1)
> > > > > > from this series and group it with the new series (binman-related).
> > > > > > 
> > > > > > Otherwise, you're mixing two unrelated logical changes across two
> > > > > > series.
> > > > > 
> > > > > rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
> > > > > to untouch Linux dts files and get introduced initial
> > > > > rk3399-u-boot.dtsi which doesn't effect any board dts files but use
> > > > > new boards.
> > > > 
> > > > Yes I think I properly understand that now. The problem is that
> > > > currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
> > > > series, you are introducing the file and including it in the newly-
> > > > introduced devices, but not in the previous ones. This is inconsistent.
> > > > 
> > > > Then, in the second series, you are moving existing boards to using
> > > > rk3399-u-boot.dtsi, except for the boards you introduced in the first
> > > > series. This is inconsistent.
> > > > 
> > > > Do you see the problem? I feel like you are missing it and only
> > > > focusing on the fact that the series works in practice, which is not
> > > > the issue.
> > > 
> > > Not again.
> > > 
> > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > boards are using this file and next series rest of the boards are
> > > using which indeed a valid step. what is inconsistent here, I don't
> > > understand.
> > 
> > Yes, what you are describing is exactly the issue. It does not make
> > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > devices that use this file *before* switching existing devices to the
> > new common u-boot dtsi for rk3399 in the same series.
> 
> How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> patch says it is an initial one and it is bit hard to add all at once.
> ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> unaffected to any of the existing dts files.

Again, it's not a technical issue. Your proposal works and has no
technical issue. The issue is in how the commits are grouped together.
Patch series need to make logical sense. One patch series should
accomplish one change, and each patch represents a step of that change.

This is how upstream contributions work, and it's a powerful way to
allow both efficient code review and good code quality. We want to keep
things as simple, explicit and well-described as possible, so that
things are easy for reviewers and as many people as possible can
understand the issue and share their thoughts about it.

It is all part of communication with others as part of a community.
It is definitely an implicit rule that is not written down somewhere
precisely, but that's the social contract between developers that work
on a common software project.

In that, contributing to upstream is different than baseline tech
company standards, because you have to take extra steps to describe
your work and explain it to others. You must make sure you give them
all the comfort they need to painlessly understand what you did.

It plays a great deal in having series accepted without going through
very long discussions and numerous iterations. The less questions
maintainers will have about your work, the better. They may disagree
with the decisions you took, but these discussions are purely technical
and can be resolved quickly.

It's basically that: you have to make sure everything is explained and
easy to understand so that the discussions will only be about the
choices you made and not trying to understand why you had to make these
choices.

Cheers,

Paul

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 16:40                                       ` [U-Boot] " Paul Kocialkowski
@ 2019-04-26 16:53                                         ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 16:53 UTC (permalink / raw)
  To: Paul Kocialkowski
  Cc: U-Boot-Denx, linux-rockchip, Akash Gajjar, linux-amarula

On Fri, Apr 26, 2019 at 10:10 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> Le vendredi 26 avril 2019 à 21:46 +0530, Jagan Teki a écrit :
> > On Fri, Apr 26, 2019 at 9:38 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > Le vendredi 26 avril 2019 à 21:18 +0530, Jagan Teki a écrit :
> > > > On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > >
> > > > > Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> > > > > > On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > > > > > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > > > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Specification
> > > > > > > > > > > > > > - Rockchip RK3399
> > > > > > > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > > > > > > - 16GB eMMC
> > > > > > > > > > > > > > - SD card slot
> > > > > > > > > > > > >
> > > > > > > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > > > > > > > >
> > > > > > > > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > > > > > >
> > > > > > > > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > > > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > > > > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > > > > > > > >
> > > > > > > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > > > > > >
> > > > > > > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > > > > > > which were used by subsequent boards on the same series.
> > > > > > > > > >
> > > > > > > > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > > > > > > > existing board dts files thought that it will include
> > > > > > > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > > > > > >
> > > > > > > > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > > > > > > > a subsequent series.
> > > > > > > > > >
> > > > > > > > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > > > > > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > > > > > > > node to make use of new boards.  and the same reused by next series
> > > > > > > > > > so-that I can add binman global to all rk3399 boards.
> > > > > > > > >
> > > > > > > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > > > > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > > > > > > > other boards are still using the previous scheme after the series.
> > > > > > > > >
> > > > > > > > > This is very confusing and I really think you should keep u-boot,dm-
> > > > > > > > > pre-reloc in the orange pi dts file and then make the transition with
> > > > > > > > > all the other boards. You're mixing multiple logical steps which makes
> > > > > > > > > it really hard to understand what's going on.
> > > > > > > > >
> > > > > > > > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > > > > > > > should be grouped with your second series, not the first one. In your
> > > > > > > > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > > > > > > > >
> > > > > > > > > Could you respin the two series to group changes by logic changes
> > > > > > > > > instead of the current state of interleaved changes?
> > > > > > > >
> > > > > > > > Okay, to make it clear I can send v4 with v3.1 included and updated
> > > > > > > > commit log. but I the new series about binman remains same since the
> > > > > > > > changes on first patch on the series are relevant.
> > > > > > >
> > > > > > > I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> > > > > > > series currently in v3. You need to remove the patch (currently v3.1)
> > > > > > > from this series and group it with the new series (binman-related).
> > > > > > >
> > > > > > > Otherwise, you're mixing two unrelated logical changes across two
> > > > > > > series.
> > > > > >
> > > > > > rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
> > > > > > to untouch Linux dts files and get introduced initial
> > > > > > rk3399-u-boot.dtsi which doesn't effect any board dts files but use
> > > > > > new boards.
> > > > >
> > > > > Yes I think I properly understand that now. The problem is that
> > > > > currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
> > > > > series, you are introducing the file and including it in the newly-
> > > > > introduced devices, but not in the previous ones. This is inconsistent.
> > > > >
> > > > > Then, in the second series, you are moving existing boards to using
> > > > > rk3399-u-boot.dtsi, except for the boards you introduced in the first
> > > > > series. This is inconsistent.
> > > > >
> > > > > Do you see the problem? I feel like you are missing it and only
> > > > > focusing on the fact that the series works in practice, which is not
> > > > > the issue.
> > > >
> > > > Not again.
> > > >
> > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > boards are using this file and next series rest of the boards are
> > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > understand.
> > >
> > > Yes, what you are describing is exactly the issue. It does not make
> > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > devices that use this file *before* switching existing devices to the
> > > new common u-boot dtsi for rk3399 in the same series.
> >
> > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > patch says it is an initial one and it is bit hard to add all at once.
> > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > unaffected to any of the existing dts files.
>
> Again, it's not a technical issue. Your proposal works and has no
> technical issue. The issue is in how the commits are grouped together.
> Patch series need to make logical sense. One patch series should
> accomplish one change, and each patch represents a step of that change.

It's about how you think. say if I wouldn't send the binman, I'm sure
this kind of discussion may not happen. In first mail you said
"something broken and how it can repair next" that indeed doesn't make
any sense of without understanding the whole series of changes.

Any new changes would come up with initial version, that what we
usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
developers are using the same is adding one after another.

>
> This is how upstream contributions work, and it's a powerful way to
> allow both efficient code review and good code quality. We want to keep
> things as simple, explicit and well-described as possible, so that
> things are easy for reviewers and as many people as possible can
> understand the issue and share their thoughts about it.

Yes, we adopt these principles and that what we are really working.

>
> It is all part of communication with others as part of a community.
> It is definitely an implicit rule that is not written down somewhere
> precisely, but that's the social contract between developers that work
> on a common software project.
>
> In that, contributing to upstream is different than baseline tech
> company standards, because you have to take extra steps to describe
> your work and explain it to others. You must make sure you give them
> all the comfort they need to painlessly understand what you did.

I hope all my communication was relevant to the topics, I can even
given the example how things were moved.

>
> It plays a great deal in having series accepted without going through
> very long discussions and numerous iterations. The less questions
> maintainers will have about your work, the better. They may disagree
> with the decisions you took, but these discussions are purely technical
> and can be resolved quickly.

Pure technical, yes ie what I thought off. no problem for me for long
discussion atleast people can understand how things went.

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

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 16:53                                         ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 16:53 UTC (permalink / raw)
  To: u-boot

On Fri, Apr 26, 2019 at 10:10 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> Le vendredi 26 avril 2019 à 21:46 +0530, Jagan Teki a écrit :
> > On Fri, Apr 26, 2019 at 9:38 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > Le vendredi 26 avril 2019 à 21:18 +0530, Jagan Teki a écrit :
> > > > On Fri, Apr 26, 2019 at 9:08 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > >
> > > > > Le vendredi 26 avril 2019 à 20:48 +0530, Jagan Teki a écrit :
> > > > > > On Fri, Apr 26, 2019 at 8:42 PM Paul Kocialkowski
> > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Fri, 2019-04-26 at 20:31 +0530, Jagan Teki wrote:
> > > > > > > > On Fri, Apr 26, 2019 at 8:24 PM Paul Kocialkowski
> > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > On Fri, 2019-04-26 at 20:15 +0530, Jagan Teki wrote:
> > > > > > > > > > On Fri, Apr 26, 2019 at 8:04 PM Paul Kocialkowski
> > > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > On Fri, 2019-04-26 at 19:57 +0530, Jagan Teki wrote:
> > > > > > > > > > > > On Fri, Apr 26, 2019 at 7:47 PM Paul Kocialkowski
> > > > > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, 2019-04-25 at 23:04 +0530, Jagan Teki wrote:
> > > > > > > > > > > > > > Add initial support for Orangepi RK3399 board.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Specification
> > > > > > > > > > > > > > - Rockchip RK3399
> > > > > > > > > > > > > > - 2GB/4GB DDR3
> > > > > > > > > > > > > > - 16GB eMMC
> > > > > > > > > > > > > > - SD card slot
> > > > > > > > > > > > >
> > > > > > > > > > > > > Looks like you're missing u-boot,dm-pre-reloc to have it working, which
> > > > > > > > > > > > > will need to be introduced when moving to rk3399-u-boot.dtsi.
> > > > > > > > > > > >
> > > > > > > > > > > > Look like you are confused or doesn't check the patch. This patch have
> > > > > > > > > > > > rk3399-orangepi-u-boot.dtsi which included rk3399-u-boot.dtsi that has
> > > > > > > > > > > > u-boot,dm-pre-reloc for sdmmc.
> > > > > > > > > > >
> > > > > > > > > > > Well no, in your v3.1 patch, you no longer have u-boot,dm-pre-reloc in
> > > > > > > > > > > rk3399-u-boot.dtsi, so you need to add it in the device dts and remove
> > > > > > > > > > > it in your second series when you add it back to rk3399-u-boot.dtsi.
> > > > > > > > > >
> > > > > > > > > > Which u-boot,dm-pre-reloc are you taking about?
> > > > > > > > > >
> > > > > > > > > > v3.1 has u-boot,dm-pre-reloc for sdmmc, please check it again [1]
> > > > > > > > > > which were used by subsequent boards on the same series.
> > > > > > > > > >
> > > > > > > > > > The diff between v3 vs v3.1 is like v3 removed u-boot,dm-pre-reloc on
> > > > > > > > > > existing board dts files thought that it will include
> > > > > > > > > > rk3399-u-boot.dtsi will automatically, but not ie fixed in v3.1
> > > > > > > > > >
> > > > > > > > > > > It's not okay to submit the board with broken MMC support and fix it in
> > > > > > > > > > > a subsequent series.
> > > > > > > > > >
> > > > > > > > > > Again, nothing broken. existing boards or dts(i) files are untouched.
> > > > > > > > > > Added only initial rk3399-u-boot.dtsi with sdmmc u-boot,dm-pre-reloc
> > > > > > > > > > node to make use of new boards.  and the same reused by next series
> > > > > > > > > > so-that I can add binman global to all rk3399 boards.
> > > > > > > > >
> > > > > > > > > Okay I think I'm getting there. So the Orangepi uses the new scheme
> > > > > > > > > (including rk3399-u-boot.dtsi which has u-boot,dm-pre-reloc) while all
> > > > > > > > > other boards are still using the previous scheme after the series.
> > > > > > > > >
> > > > > > > > > This is very confusing and I really think you should keep u-boot,dm-
> > > > > > > > > pre-reloc in the orange pi dts file and then make the transition with
> > > > > > > > > all the other boards. You're mixing multiple logical steps which makes
> > > > > > > > > it really hard to understand what's going on.
> > > > > > > > >
> > > > > > > > > More to that, introducing the rk3399-u-boot.dtsi is a logical step that
> > > > > > > > > should be grouped with your second series, not the first one. In your
> > > > > > > > > first series, boards have u-boot,dm-pre-reloc in their per-device dtsi.
> > > > > > > > >
> > > > > > > > > Could you respin the two series to group changes by logic changes
> > > > > > > > > instead of the current state of interleaved changes?
> > > > > > > >
> > > > > > > > Okay, to make it clear I can send v4 with v3.1 included and updated
> > > > > > > > commit log. but I the new series about binman remains same since the
> > > > > > > > changes on first patch on the series are relevant.
> > > > > > >
> > > > > > > I think it makes no sense to introduce rk3399-u-boot.dts as part of the
> > > > > > > series currently in v3. You need to remove the patch (currently v3.1)
> > > > > > > from this series and group it with the new series (binman-related).
> > > > > > >
> > > > > > > Otherwise, you're mixing two unrelated logical changes across two
> > > > > > > series.
> > > > > >
> > > > > > rk3399-u-boot.dtsi is require for sdboot on that boards, whole idea is
> > > > > > to untouch Linux dts files and get introduced initial
> > > > > > rk3399-u-boot.dtsi which doesn't effect any board dts files but use
> > > > > > new boards.
> > > > >
> > > > > Yes I think I properly understand that now. The problem is that
> > > > > currently, rk3399 boards do not use rk3399-u-boot.dtsi. In the first
> > > > > series, you are introducing the file and including it in the newly-
> > > > > introduced devices, but not in the previous ones. This is inconsistent.
> > > > >
> > > > > Then, in the second series, you are moving existing boards to using
> > > > > rk3399-u-boot.dtsi, except for the boards you introduced in the first
> > > > > series. This is inconsistent.
> > > > >
> > > > > Do you see the problem? I feel like you are missing it and only
> > > > > focusing on the fact that the series works in practice, which is not
> > > > > the issue.
> > > >
> > > > Not again.
> > > >
> > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > boards are using this file and next series rest of the boards are
> > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > understand.
> > >
> > > Yes, what you are describing is exactly the issue. It does not make
> > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > devices that use this file *before* switching existing devices to the
> > > new common u-boot dtsi for rk3399 in the same series.
> >
> > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > patch says it is an initial one and it is bit hard to add all at once.
> > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > unaffected to any of the existing dts files.
>
> Again, it's not a technical issue. Your proposal works and has no
> technical issue. The issue is in how the commits are grouped together.
> Patch series need to make logical sense. One patch series should
> accomplish one change, and each patch represents a step of that change.

It's about how you think. say if I wouldn't send the binman, I'm sure
this kind of discussion may not happen. In first mail you said
"something broken and how it can repair next" that indeed doesn't make
any sense of without understanding the whole series of changes.

Any new changes would come up with initial version, that what we
usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
developers are using the same is adding one after another.

>
> This is how upstream contributions work, and it's a powerful way to
> allow both efficient code review and good code quality. We want to keep
> things as simple, explicit and well-described as possible, so that
> things are easy for reviewers and as many people as possible can
> understand the issue and share their thoughts about it.

Yes, we adopt these principles and that what we are really working.

>
> It is all part of communication with others as part of a community.
> It is definitely an implicit rule that is not written down somewhere
> precisely, but that's the social contract between developers that work
> on a common software project.
>
> In that, contributing to upstream is different than baseline tech
> company standards, because you have to take extra steps to describe
> your work and explain it to others. You must make sure you give them
> all the comfort they need to painlessly understand what you did.

I hope all my communication was relevant to the topics, I can even
given the example how things were moved.

>
> It plays a great deal in having series accepted without going through
> very long discussions and numerous iterations. The less questions
> maintainers will have about your work, the better. They may disagree
> with the decisions you took, but these discussions are purely technical
> and can be resolved quickly.

Pure technical, yes ie what I thought off. no problem for me for long
discussion atleast people can understand how things went.

Jagan.

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 16:53                                         ` [U-Boot] " Jagan Teki
@ 2019-04-26 17:08                                           ` Paul Kocialkowski
  -1 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 17:08 UTC (permalink / raw)
  To: Jagan Teki; +Cc: U-Boot-Denx, linux-rockchip, Akash Gajjar, linux-amarula

Hi,

Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > > boards are using this file and next series rest of the boards are
> > > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > > understand.
> > > > 
> > > > Yes, what you are describing is exactly the issue. It does not make
> > > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > > devices that use this file *before* switching existing devices to the
> > > > new common u-boot dtsi for rk3399 in the same series.
> > > 
> > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > > patch says it is an initial one and it is bit hard to add all at once.
> > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > unaffected to any of the existing dts files.
> > 
> > Again, it's not a technical issue. Your proposal works and has no
> > technical issue. The issue is in how the commits are grouped together.
> > Patch series need to make logical sense. One patch series should
> > accomplish one change, and each patch represents a step of that change.
> 
> It's about how you think. say if I wouldn't send the binman, I'm sure
> this kind of discussion may not happen. In first mail you said
> "something broken and how it can repair next" that indeed doesn't make
> any sense of without understanding the whole series of changes.

One part to that is that I had misunderstood a few things, but I really
should not have to look at each patch before I can have an idea of what
the series does. Your series is called "rockchip: Add new rk3399
boards" and with the v3.1 change you made, the title is no longer true.
You are doing that + introducing a new rk3399 u-boot dtsi without
switching existing boards to it before adding new ones.

From that moment, you needed to split your changes into two series.
Instead of that, you made another series with mostly unrelated changes
where you included an unrelated commit adding the pre-reloc entries to
the dtsi created in the previous series.

That's an issue for communication with the community.

> Any new changes would come up with initial version, that what we
> usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> developers are using the same is adding one after another.

But you already have boards in the tree that needs the tree. You can
make individual commits for switching boards to the new dtsi, but you
need to do that in the same series as introducing the dtsi if you are
submitting both things at the same time. If you want to have them
merged separately, then you can send device dtsi patches individually
for that, but not as part of another unrelated series.

> > This is how upstream contributions work, and it's a powerful way to
> > allow both efficient code review and good code quality. We want to keep
> > things as simple, explicit and well-described as possible, so that
> > things are easy for reviewers and as many people as possible can
> > understand the issue and share their thoughts about it.
> 
> Yes, we adopt these principles and that what we are really working.
> 
> > It is all part of communication with others as part of a community.
> > It is definitely an implicit rule that is not written down somewhere
> > precisely, but that's the social contract between developers that work
> > on a common software project.
> > 
> > In that, contributing to upstream is different than baseline tech
> > company standards, because you have to take extra steps to describe
> > your work and explain it to others. You must make sure you give them
> > all the comfort they need to painlessly understand what you did.
> 
> I hope all my communication was relevant to the topics, I can even
> given the example how things were moved.

Clearly there was a major communication issue between us. You only
answered on technical topics and never about how your patch series is
organized and what logical changes you are making.

To be honest with you, I feel like we have a general communication
issue where you only seem to focus on technical aspects, when the
issues are about the meta-data of the changes such as commit messages,
code comments and how changes are organized together.

> > It plays a great deal in having series accepted without going through
> > very long discussions and numerous iterations. The less questions
> > maintainers will have about your work, the better. They may disagree
> > with the decisions you took, but these discussions are purely technical
> > and can be resolved quickly.
> 
> Pure technical, yes ie what I thought off. no problem for me for long
> discussion atleast people can understand how things went.

Community discussions can not, and must not be purely technical. This
is not a personal opinion of mine, this is how all free software
communities work. Some care more than others about it, but in very
technical projects like U-Boot and Linux, people need to care about it
a lot.

The more technical the things you are dealing with are, the more you
need to do on the non-technical side to make sure what you are doing is
clear, understood by everyone and makes sense on its own.

Cheers,

Paul

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

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 17:08                                           ` Paul Kocialkowski
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 17:08 UTC (permalink / raw)
  To: u-boot

Hi,

Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > > boards are using this file and next series rest of the boards are
> > > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > > understand.
> > > > 
> > > > Yes, what you are describing is exactly the issue. It does not make
> > > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > > devices that use this file *before* switching existing devices to the
> > > > new common u-boot dtsi for rk3399 in the same series.
> > > 
> > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > > patch says it is an initial one and it is bit hard to add all at once.
> > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > unaffected to any of the existing dts files.
> > 
> > Again, it's not a technical issue. Your proposal works and has no
> > technical issue. The issue is in how the commits are grouped together.
> > Patch series need to make logical sense. One patch series should
> > accomplish one change, and each patch represents a step of that change.
> 
> It's about how you think. say if I wouldn't send the binman, I'm sure
> this kind of discussion may not happen. In first mail you said
> "something broken and how it can repair next" that indeed doesn't make
> any sense of without understanding the whole series of changes.

One part to that is that I had misunderstood a few things, but I really
should not have to look at each patch before I can have an idea of what
the series does. Your series is called "rockchip: Add new rk3399
boards" and with the v3.1 change you made, the title is no longer true.
You are doing that + introducing a new rk3399 u-boot dtsi without
switching existing boards to it before adding new ones.

From that moment, you needed to split your changes into two series.
Instead of that, you made another series with mostly unrelated changes
where you included an unrelated commit adding the pre-reloc entries to
the dtsi created in the previous series.

That's an issue for communication with the community.

> Any new changes would come up with initial version, that what we
> usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> developers are using the same is adding one after another.

But you already have boards in the tree that needs the tree. You can
make individual commits for switching boards to the new dtsi, but you
need to do that in the same series as introducing the dtsi if you are
submitting both things at the same time. If you want to have them
merged separately, then you can send device dtsi patches individually
for that, but not as part of another unrelated series.

> > This is how upstream contributions work, and it's a powerful way to
> > allow both efficient code review and good code quality. We want to keep
> > things as simple, explicit and well-described as possible, so that
> > things are easy for reviewers and as many people as possible can
> > understand the issue and share their thoughts about it.
> 
> Yes, we adopt these principles and that what we are really working.
> 
> > It is all part of communication with others as part of a community.
> > It is definitely an implicit rule that is not written down somewhere
> > precisely, but that's the social contract between developers that work
> > on a common software project.
> > 
> > In that, contributing to upstream is different than baseline tech
> > company standards, because you have to take extra steps to describe
> > your work and explain it to others. You must make sure you give them
> > all the comfort they need to painlessly understand what you did.
> 
> I hope all my communication was relevant to the topics, I can even
> given the example how things were moved.

Clearly there was a major communication issue between us. You only
answered on technical topics and never about how your patch series is
organized and what logical changes you are making.

To be honest with you, I feel like we have a general communication
issue where you only seem to focus on technical aspects, when the
issues are about the meta-data of the changes such as commit messages,
code comments and how changes are organized together.

> > It plays a great deal in having series accepted without going through
> > very long discussions and numerous iterations. The less questions
> > maintainers will have about your work, the better. They may disagree
> > with the decisions you took, but these discussions are purely technical
> > and can be resolved quickly.
> 
> Pure technical, yes ie what I thought off. no problem for me for long
> discussion atleast people can understand how things went.

Community discussions can not, and must not be purely technical. This
is not a personal opinion of mine, this is how all free software
communities work. Some care more than others about it, but in very
technical projects like U-Boot and Linux, people need to care about it
a lot.

The more technical the things you are dealing with are, the more you
need to do on the non-technical side to make sure what you are doing is
clear, understood by everyone and makes sense on its own.

Cheers,

Paul

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 17:08                                           ` [U-Boot] " Paul Kocialkowski
@ 2019-04-26 17:21                                             ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 17:21 UTC (permalink / raw)
  To: Paul Kocialkowski
  Cc: U-Boot-Denx, linux-rockchip, Akash Gajjar, linux-amarula

On Fri, Apr 26, 2019 at 10:38 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > > > boards are using this file and next series rest of the boards are
> > > > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > > > understand.
> > > > >
> > > > > Yes, what you are describing is exactly the issue. It does not make
> > > > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > > > devices that use this file *before* switching existing devices to the
> > > > > new common u-boot dtsi for rk3399 in the same series.
> > > >
> > > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > > > patch says it is an initial one and it is bit hard to add all at once.
> > > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > > unaffected to any of the existing dts files.
> > >
> > > Again, it's not a technical issue. Your proposal works and has no
> > > technical issue. The issue is in how the commits are grouped together.
> > > Patch series need to make logical sense. One patch series should
> > > accomplish one change, and each patch represents a step of that change.
> >
> > It's about how you think. say if I wouldn't send the binman, I'm sure
> > this kind of discussion may not happen. In first mail you said
> > "something broken and how it can repair next" that indeed doesn't make
> > any sense of without understanding the whole series of changes.
>
> One part to that is that I had misunderstood a few things, but I really
> should not have to look at each patch before I can have an idea of what
> the series does. Your series is called "rockchip: Add new rk3399
> boards" and with the v3.1 change you made, the title is no longer true.
> You are doing that + introducing a new rk3399 u-boot dtsi without
> switching existing boards to it before adding new ones.
>
> From that moment, you needed to split your changes into two series.
> Instead of that, you made another series with mostly unrelated changes
> where you included an unrelated commit adding the pre-reloc entries to
> the dtsi created in the previous series.
>
> That's an issue for communication with the community.
>
> > Any new changes would come up with initial version, that what we
> > usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> > developers are using the same is adding one after another.
>
> But you already have boards in the tree that needs the tree. You can
> make individual commits for switching boards to the new dtsi, but you
> need to do that in the same series as introducing the dtsi if you are
> submitting both things at the same time. If you want to have them
> merged separately, then you can send device dtsi patches individually
> for that, but not as part of another unrelated series.
>
> > > This is how upstream contributions work, and it's a powerful way to
> > > allow both efficient code review and good code quality. We want to keep
> > > things as simple, explicit and well-described as possible, so that
> > > things are easy for reviewers and as many people as possible can
> > > understand the issue and share their thoughts about it.
> >
> > Yes, we adopt these principles and that what we are really working.
> >
> > > It is all part of communication with others as part of a community.
> > > It is definitely an implicit rule that is not written down somewhere
> > > precisely, but that's the social contract between developers that work
> > > on a common software project.
> > >
> > > In that, contributing to upstream is different than baseline tech
> > > company standards, because you have to take extra steps to describe
> > > your work and explain it to others. You must make sure you give them
> > > all the comfort they need to painlessly understand what you did.
> >
> > I hope all my communication was relevant to the topics, I can even
> > given the example how things were moved.
>
> Clearly there was a major communication issue between us. You only
> answered on technical topics and never about how your patch series is
> organized and what logical changes you are making.
>
> To be honest with you, I feel like we have a general communication
> issue where you only seem to focus on technical aspects, when the
> issues are about the meta-data of the changes such as commit messages,
> code comments and how changes are organized together.

No one is better in all aspects, and things were improving no one cam
make global statements like this though he can find something gaps on
on previous one. You would better suggest on the commit where it
confused can make me better understanding.

>
> > > It plays a great deal in having series accepted without going through
> > > very long discussions and numerous iterations. The less questions
> > > maintainers will have about your work, the better. They may disagree
> > > with the decisions you took, but these discussions are purely technical
> > > and can be resolved quickly.
> >
> > Pure technical, yes ie what I thought off. no problem for me for long
> > discussion atleast people can understand how things went.
>
> Community discussions can not, and must not be purely technical. This
> is not a personal opinion of mine, this is how all free software
> communities work. Some care more than others about it, but in very
> technical projects like U-Boot and Linux, people need to care about it
> a lot.
>
> The more technical the things you are dealing with are, the more you
> need to do on the non-technical side to make sure what you are doing is
> clear, understood by everyone and makes sense on its own.

True, this is what I'm trying to work always, thanks.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 17:21                                             ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 17:21 UTC (permalink / raw)
  To: u-boot

On Fri, Apr 26, 2019 at 10:38 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > > > boards are using this file and next series rest of the boards are
> > > > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > > > understand.
> > > > >
> > > > > Yes, what you are describing is exactly the issue. It does not make
> > > > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > > > devices that use this file *before* switching existing devices to the
> > > > > new common u-boot dtsi for rk3399 in the same series.
> > > >
> > > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > > > patch says it is an initial one and it is bit hard to add all at once.
> > > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > > unaffected to any of the existing dts files.
> > >
> > > Again, it's not a technical issue. Your proposal works and has no
> > > technical issue. The issue is in how the commits are grouped together.
> > > Patch series need to make logical sense. One patch series should
> > > accomplish one change, and each patch represents a step of that change.
> >
> > It's about how you think. say if I wouldn't send the binman, I'm sure
> > this kind of discussion may not happen. In first mail you said
> > "something broken and how it can repair next" that indeed doesn't make
> > any sense of without understanding the whole series of changes.
>
> One part to that is that I had misunderstood a few things, but I really
> should not have to look at each patch before I can have an idea of what
> the series does. Your series is called "rockchip: Add new rk3399
> boards" and with the v3.1 change you made, the title is no longer true.
> You are doing that + introducing a new rk3399 u-boot dtsi without
> switching existing boards to it before adding new ones.
>
> From that moment, you needed to split your changes into two series.
> Instead of that, you made another series with mostly unrelated changes
> where you included an unrelated commit adding the pre-reloc entries to
> the dtsi created in the previous series.
>
> That's an issue for communication with the community.
>
> > Any new changes would come up with initial version, that what we
> > usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> > developers are using the same is adding one after another.
>
> But you already have boards in the tree that needs the tree. You can
> make individual commits for switching boards to the new dtsi, but you
> need to do that in the same series as introducing the dtsi if you are
> submitting both things at the same time. If you want to have them
> merged separately, then you can send device dtsi patches individually
> for that, but not as part of another unrelated series.
>
> > > This is how upstream contributions work, and it's a powerful way to
> > > allow both efficient code review and good code quality. We want to keep
> > > things as simple, explicit and well-described as possible, so that
> > > things are easy for reviewers and as many people as possible can
> > > understand the issue and share their thoughts about it.
> >
> > Yes, we adopt these principles and that what we are really working.
> >
> > > It is all part of communication with others as part of a community.
> > > It is definitely an implicit rule that is not written down somewhere
> > > precisely, but that's the social contract between developers that work
> > > on a common software project.
> > >
> > > In that, contributing to upstream is different than baseline tech
> > > company standards, because you have to take extra steps to describe
> > > your work and explain it to others. You must make sure you give them
> > > all the comfort they need to painlessly understand what you did.
> >
> > I hope all my communication was relevant to the topics, I can even
> > given the example how things were moved.
>
> Clearly there was a major communication issue between us. You only
> answered on technical topics and never about how your patch series is
> organized and what logical changes you are making.
>
> To be honest with you, I feel like we have a general communication
> issue where you only seem to focus on technical aspects, when the
> issues are about the meta-data of the changes such as commit messages,
> code comments and how changes are organized together.

No one is better in all aspects, and things were improving no one cam
make global statements like this though he can find something gaps on
on previous one. You would better suggest on the commit where it
confused can make me better understanding.

>
> > > It plays a great deal in having series accepted without going through
> > > very long discussions and numerous iterations. The less questions
> > > maintainers will have about your work, the better. They may disagree
> > > with the decisions you took, but these discussions are purely technical
> > > and can be resolved quickly.
> >
> > Pure technical, yes ie what I thought off. no problem for me for long
> > discussion atleast people can understand how things went.
>
> Community discussions can not, and must not be purely technical. This
> is not a personal opinion of mine, this is how all free software
> communities work. Some care more than others about it, but in very
> technical projects like U-Boot and Linux, people need to care about it
> a lot.
>
> The more technical the things you are dealing with are, the more you
> need to do on the non-technical side to make sure what you are doing is
> clear, understood by everyone and makes sense on its own.

True, this is what I'm trying to work always, thanks.

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 17:21                                             ` [U-Boot] " Jagan Teki
@ 2019-04-26 17:37                                               ` Paul Kocialkowski
  -1 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 17:37 UTC (permalink / raw)
  To: Jagan Teki; +Cc: U-Boot-Denx, linux-rockchip, Akash Gajjar, linux-amarula

Hi,

Le vendredi 26 avril 2019 à 22:51 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 10:38 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > > > > boards are using this file and next series rest of the boards are
> > > > > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > > > > understand.
> > > > > > 
> > > > > > Yes, what you are describing is exactly the issue. It does not make
> > > > > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > > > > devices that use this file *before* switching existing devices to the
> > > > > > new common u-boot dtsi for rk3399 in the same series.
> > > > > 
> > > > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > > > > patch says it is an initial one and it is bit hard to add all at once.
> > > > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > > > unaffected to any of the existing dts files.
> > > > 
> > > > Again, it's not a technical issue. Your proposal works and has no
> > > > technical issue. The issue is in how the commits are grouped together.
> > > > Patch series need to make logical sense. One patch series should
> > > > accomplish one change, and each patch represents a step of that change.
> > > 
> > > It's about how you think. say if I wouldn't send the binman, I'm sure
> > > this kind of discussion may not happen. In first mail you said
> > > "something broken and how it can repair next" that indeed doesn't make
> > > any sense of without understanding the whole series of changes.
> > 
> > One part to that is that I had misunderstood a few things, but I really
> > should not have to look at each patch before I can have an idea of what
> > the series does. Your series is called "rockchip: Add new rk3399
> > boards" and with the v3.1 change you made, the title is no longer true.
> > You are doing that + introducing a new rk3399 u-boot dtsi without
> > switching existing boards to it before adding new ones.
> > 
> > From that moment, you needed to split your changes into two series.
> > Instead of that, you made another series with mostly unrelated changes
> > where you included an unrelated commit adding the pre-reloc entries to
> > the dtsi created in the previous series.
> > 
> > That's an issue for communication with the community.
> > 
> > > Any new changes would come up with initial version, that what we
> > > usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> > > developers are using the same is adding one after another.
> > 
> > But you already have boards in the tree that needs the tree. You can
> > make individual commits for switching boards to the new dtsi, but you
> > need to do that in the same series as introducing the dtsi if you are
> > submitting both things at the same time. If you want to have them
> > merged separately, then you can send device dtsi patches individually
> > for that, but not as part of another unrelated series.
> > 
> > > > This is how upstream contributions work, and it's a powerful way to
> > > > allow both efficient code review and good code quality. We want to keep
> > > > things as simple, explicit and well-described as possible, so that
> > > > things are easy for reviewers and as many people as possible can
> > > > understand the issue and share their thoughts about it.
> > > 
> > > Yes, we adopt these principles and that what we are really working.
> > > 
> > > > It is all part of communication with others as part of a community.
> > > > It is definitely an implicit rule that is not written down somewhere
> > > > precisely, but that's the social contract between developers that work
> > > > on a common software project.
> > > > 
> > > > In that, contributing to upstream is different than baseline tech
> > > > company standards, because you have to take extra steps to describe
> > > > your work and explain it to others. You must make sure you give them
> > > > all the comfort they need to painlessly understand what you did.
> > > 
> > > I hope all my communication was relevant to the topics, I can even
> > > given the example how things were moved.
> > 
> > Clearly there was a major communication issue between us. You only
> > answered on technical topics and never about how your patch series is
> > organized and what logical changes you are making.
> > 
> > To be honest with you, I feel like we have a general communication
> > issue where you only seem to focus on technical aspects, when the
> > issues are about the meta-data of the changes such as commit messages,
> > code comments and how changes are organized together.
> 
> No one is better in all aspects, and things were improving no one cam
> make global statements like this though he can find something gaps on
> on previous one. You would better suggest on the commit where it
> confused can make me better understanding.

I am making such a global statement because I've had this issue with
you a few times before already, and from what I could see about sunxi-
related discussions, it seems that others have had similar issues
before too. Each time, it feels like you are not discussing the issue
and answering on mostly-unrelated technical topics, exactly like it's
happening now.

Now this is really nothing personal against you, I have no interest in
pointing out things that need to be worked on in the work you submit in
order to make you feel bad or inferior. But at this point, I feel like
you are not understanding the global issue so I am bringing the
discussion to more general conclusions, since we are talking about
communication issues more generally.

Everyone is trying to improve and it's perfectly fine to have flaws.
For that matter, the situation was already reversed a few times when
you reviewed some of my sunxi patches saying that the commit log was
unclear, and I gladly accepted the criticism to make a better next
revision. I also want to add that you make significant important
contributions to lots of projects I really care about. This thread is a
perfect example of that too, since I plan on using a RK3399 boards you
are introducing for my personal use. So I am more than happy to see you
do all that hard work and I truly value your contributions.

Really, I'm mostly trying to help here and collaborate towards
resolving the situation.

So could you please send 3 distinct series that deal with each one of
the aspects from the list that follows?

- Introducing a common RK3399 u-boot dtsi with the required pre-reloc
entries;
- Adding new RK3399 devices and syncing the dtsi files from Linux;
- Introducing u-boot-rockchip-with-spl.bin.

Thanks,

Paul

> > > > It plays a great deal in having series accepted without going through
> > > > very long discussions and numerous iterations. The less questions
> > > > maintainers will have about your work, the better. They may disagree
> > > > with the decisions you took, but these discussions are purely technical
> > > > and can be resolved quickly.
> > > 
> > > Pure technical, yes ie what I thought off. no problem for me for long
> > > discussion atleast people can understand how things went.
> > 
> > Community discussions can not, and must not be purely technical. This
> > is not a personal opinion of mine, this is how all free software
> > communities work. Some care more than others about it, but in very
> > technical projects like U-Boot and Linux, people need to care about it
> > a lot.
> > 
> > The more technical the things you are dealing with are, the more you
> > need to do on the non-technical side to make sure what you are doing is
> > clear, understood by everyone and makes sense on its own.
> 
> True, this is what I'm trying to work always, thanks.

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

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 17:37                                               ` Paul Kocialkowski
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 17:37 UTC (permalink / raw)
  To: u-boot

Hi,

Le vendredi 26 avril 2019 à 22:51 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 10:38 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > > > > boards are using this file and next series rest of the boards are
> > > > > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > > > > understand.
> > > > > > 
> > > > > > Yes, what you are describing is exactly the issue. It does not make
> > > > > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > > > > devices that use this file *before* switching existing devices to the
> > > > > > new common u-boot dtsi for rk3399 in the same series.
> > > > > 
> > > > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > > > > patch says it is an initial one and it is bit hard to add all at once.
> > > > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > > > unaffected to any of the existing dts files.
> > > > 
> > > > Again, it's not a technical issue. Your proposal works and has no
> > > > technical issue. The issue is in how the commits are grouped together.
> > > > Patch series need to make logical sense. One patch series should
> > > > accomplish one change, and each patch represents a step of that change.
> > > 
> > > It's about how you think. say if I wouldn't send the binman, I'm sure
> > > this kind of discussion may not happen. In first mail you said
> > > "something broken and how it can repair next" that indeed doesn't make
> > > any sense of without understanding the whole series of changes.
> > 
> > One part to that is that I had misunderstood a few things, but I really
> > should not have to look at each patch before I can have an idea of what
> > the series does. Your series is called "rockchip: Add new rk3399
> > boards" and with the v3.1 change you made, the title is no longer true.
> > You are doing that + introducing a new rk3399 u-boot dtsi without
> > switching existing boards to it before adding new ones.
> > 
> > From that moment, you needed to split your changes into two series.
> > Instead of that, you made another series with mostly unrelated changes
> > where you included an unrelated commit adding the pre-reloc entries to
> > the dtsi created in the previous series.
> > 
> > That's an issue for communication with the community.
> > 
> > > Any new changes would come up with initial version, that what we
> > > usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> > > developers are using the same is adding one after another.
> > 
> > But you already have boards in the tree that needs the tree. You can
> > make individual commits for switching boards to the new dtsi, but you
> > need to do that in the same series as introducing the dtsi if you are
> > submitting both things at the same time. If you want to have them
> > merged separately, then you can send device dtsi patches individually
> > for that, but not as part of another unrelated series.
> > 
> > > > This is how upstream contributions work, and it's a powerful way to
> > > > allow both efficient code review and good code quality. We want to keep
> > > > things as simple, explicit and well-described as possible, so that
> > > > things are easy for reviewers and as many people as possible can
> > > > understand the issue and share their thoughts about it.
> > > 
> > > Yes, we adopt these principles and that what we are really working.
> > > 
> > > > It is all part of communication with others as part of a community.
> > > > It is definitely an implicit rule that is not written down somewhere
> > > > precisely, but that's the social contract between developers that work
> > > > on a common software project.
> > > > 
> > > > In that, contributing to upstream is different than baseline tech
> > > > company standards, because you have to take extra steps to describe
> > > > your work and explain it to others. You must make sure you give them
> > > > all the comfort they need to painlessly understand what you did.
> > > 
> > > I hope all my communication was relevant to the topics, I can even
> > > given the example how things were moved.
> > 
> > Clearly there was a major communication issue between us. You only
> > answered on technical topics and never about how your patch series is
> > organized and what logical changes you are making.
> > 
> > To be honest with you, I feel like we have a general communication
> > issue where you only seem to focus on technical aspects, when the
> > issues are about the meta-data of the changes such as commit messages,
> > code comments and how changes are organized together.
> 
> No one is better in all aspects, and things were improving no one cam
> make global statements like this though he can find something gaps on
> on previous one. You would better suggest on the commit where it
> confused can make me better understanding.

I am making such a global statement because I've had this issue with
you a few times before already, and from what I could see about sunxi-
related discussions, it seems that others have had similar issues
before too. Each time, it feels like you are not discussing the issue
and answering on mostly-unrelated technical topics, exactly like it's
happening now.

Now this is really nothing personal against you, I have no interest in
pointing out things that need to be worked on in the work you submit in
order to make you feel bad or inferior. But at this point, I feel like
you are not understanding the global issue so I am bringing the
discussion to more general conclusions, since we are talking about
communication issues more generally.

Everyone is trying to improve and it's perfectly fine to have flaws.
For that matter, the situation was already reversed a few times when
you reviewed some of my sunxi patches saying that the commit log was
unclear, and I gladly accepted the criticism to make a better next
revision. I also want to add that you make significant important
contributions to lots of projects I really care about. This thread is a
perfect example of that too, since I plan on using a RK3399 boards you
are introducing for my personal use. So I am more than happy to see you
do all that hard work and I truly value your contributions.

Really, I'm mostly trying to help here and collaborate towards
resolving the situation.

So could you please send 3 distinct series that deal with each one of
the aspects from the list that follows?

- Introducing a common RK3399 u-boot dtsi with the required pre-reloc
entries;
- Adding new RK3399 devices and syncing the dtsi files from Linux;
- Introducing u-boot-rockchip-with-spl.bin.

Thanks,

Paul

> > > > It plays a great deal in having series accepted without going through
> > > > very long discussions and numerous iterations. The less questions
> > > > maintainers will have about your work, the better. They may disagree
> > > > with the decisions you took, but these discussions are purely technical
> > > > and can be resolved quickly.
> > > 
> > > Pure technical, yes ie what I thought off. no problem for me for long
> > > discussion atleast people can understand how things went.
> > 
> > Community discussions can not, and must not be purely technical. This
> > is not a personal opinion of mine, this is how all free software
> > communities work. Some care more than others about it, but in very
> > technical projects like U-Boot and Linux, people need to care about it
> > a lot.
> > 
> > The more technical the things you are dealing with are, the more you
> > need to do on the non-technical side to make sure what you are doing is
> > clear, understood by everyone and makes sense on its own.
> 
> True, this is what I'm trying to work always, thanks.

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 17:37                                               ` [U-Boot] " Paul Kocialkowski
@ 2019-04-26 17:42                                                   ` Jagan Teki
  -1 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 17:42 UTC (permalink / raw)
  To: Paul Kocialkowski
  Cc: U-Boot-Denx, Simon Glass, Kever Yang,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Akash Gajjar,
	Philipp Tomsich, linux-amarula

On Fri, Apr 26, 2019 at 11:07 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> Le vendredi 26 avril 2019 à 22:51 +0530, Jagan Teki a écrit :
> > On Fri, Apr 26, 2019 at 10:38 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > > > > > boards are using this file and next series rest of the boards are
> > > > > > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > > > > > understand.
> > > > > > >
> > > > > > > Yes, what you are describing is exactly the issue. It does not make
> > > > > > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > > > > > devices that use this file *before* switching existing devices to the
> > > > > > > new common u-boot dtsi for rk3399 in the same series.
> > > > > >
> > > > > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > > > > > patch says it is an initial one and it is bit hard to add all at once.
> > > > > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > > > > unaffected to any of the existing dts files.
> > > > >
> > > > > Again, it's not a technical issue. Your proposal works and has no
> > > > > technical issue. The issue is in how the commits are grouped together.
> > > > > Patch series need to make logical sense. One patch series should
> > > > > accomplish one change, and each patch represents a step of that change.
> > > >
> > > > It's about how you think. say if I wouldn't send the binman, I'm sure
> > > > this kind of discussion may not happen. In first mail you said
> > > > "something broken and how it can repair next" that indeed doesn't make
> > > > any sense of without understanding the whole series of changes.
> > >
> > > One part to that is that I had misunderstood a few things, but I really
> > > should not have to look at each patch before I can have an idea of what
> > > the series does. Your series is called "rockchip: Add new rk3399
> > > boards" and with the v3.1 change you made, the title is no longer true.
> > > You are doing that + introducing a new rk3399 u-boot dtsi without
> > > switching existing boards to it before adding new ones.
> > >
> > > From that moment, you needed to split your changes into two series.
> > > Instead of that, you made another series with mostly unrelated changes
> > > where you included an unrelated commit adding the pre-reloc entries to
> > > the dtsi created in the previous series.
> > >
> > > That's an issue for communication with the community.
> > >
> > > > Any new changes would come up with initial version, that what we
> > > > usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> > > > developers are using the same is adding one after another.
> > >
> > > But you already have boards in the tree that needs the tree. You can
> > > make individual commits for switching boards to the new dtsi, but you
> > > need to do that in the same series as introducing the dtsi if you are
> > > submitting both things at the same time. If you want to have them
> > > merged separately, then you can send device dtsi patches individually
> > > for that, but not as part of another unrelated series.
> > >
> > > > > This is how upstream contributions work, and it's a powerful way to
> > > > > allow both efficient code review and good code quality. We want to keep
> > > > > things as simple, explicit and well-described as possible, so that
> > > > > things are easy for reviewers and as many people as possible can
> > > > > understand the issue and share their thoughts about it.
> > > >
> > > > Yes, we adopt these principles and that what we are really working.
> > > >
> > > > > It is all part of communication with others as part of a community.
> > > > > It is definitely an implicit rule that is not written down somewhere
> > > > > precisely, but that's the social contract between developers that work
> > > > > on a common software project.
> > > > >
> > > > > In that, contributing to upstream is different than baseline tech
> > > > > company standards, because you have to take extra steps to describe
> > > > > your work and explain it to others. You must make sure you give them
> > > > > all the comfort they need to painlessly understand what you did.
> > > >
> > > > I hope all my communication was relevant to the topics, I can even
> > > > given the example how things were moved.
> > >
> > > Clearly there was a major communication issue between us. You only
> > > answered on technical topics and never about how your patch series is
> > > organized and what logical changes you are making.
> > >
> > > To be honest with you, I feel like we have a general communication
> > > issue where you only seem to focus on technical aspects, when the
> > > issues are about the meta-data of the changes such as commit messages,
> > > code comments and how changes are organized together.
> >
> > No one is better in all aspects, and things were improving no one cam
> > make global statements like this though he can find something gaps on
> > on previous one. You would better suggest on the commit where it
> > confused can make me better understanding.
>
> I am making such a global statement because I've had this issue with
> you a few times before already, and from what I could see about sunxi-
> related discussions, it seems that others have had similar issues
> before too. Each time, it feels like you are not discussing the issue
> and answering on mostly-unrelated technical topics, exactly like it's
> happening now.
>
> Now this is really nothing personal against you, I have no interest in
> pointing out things that need to be worked on in the work you submit in
> order to make you feel bad or inferior. But at this point, I feel like
> you are not understanding the global issue so I am bringing the
> discussion to more general conclusions, since we are talking about
> communication issues more generally.
>
> Everyone is trying to improve and it's perfectly fine to have flaws.
> For that matter, the situation was already reversed a few times when
> you reviewed some of my sunxi patches saying that the commit log was
> unclear, and I gladly accepted the criticism to make a better next
> revision. I also want to add that you make significant important
> contributions to lots of projects I really care about. This thread is a
> perfect example of that too, since I plan on using a RK3399 boards you
> are introducing for my personal use. So I am more than happy to see you
> do all that hard work and I truly value your contributions.
>
> Really, I'm mostly trying to help here and collaborate towards
> resolving the situation.

Thanks.

>
> So could you please send 3 distinct series that deal with each one of
> the aspects from the list that follows?

Just now I sent v5, which would resolve what you are thinking of,
please have a look.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 17:42                                                   ` Jagan Teki
  0 siblings, 0 replies; 72+ messages in thread
From: Jagan Teki @ 2019-04-26 17:42 UTC (permalink / raw)
  To: u-boot

On Fri, Apr 26, 2019 at 11:07 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> Le vendredi 26 avril 2019 à 22:51 +0530, Jagan Teki a écrit :
> > On Fri, Apr 26, 2019 at 10:38 PM Paul Kocialkowski
> > <paul.kocialkowski@bootlin.com> wrote:
> > > Hi,
> > >
> > > Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > > > > > boards are using this file and next series rest of the boards are
> > > > > > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > > > > > understand.
> > > > > > >
> > > > > > > Yes, what you are describing is exactly the issue. It does not make
> > > > > > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > > > > > devices that use this file *before* switching existing devices to the
> > > > > > > new common u-boot dtsi for rk3399 in the same series.
> > > > > >
> > > > > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > > > > > patch says it is an initial one and it is bit hard to add all at once.
> > > > > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > > > > unaffected to any of the existing dts files.
> > > > >
> > > > > Again, it's not a technical issue. Your proposal works and has no
> > > > > technical issue. The issue is in how the commits are grouped together.
> > > > > Patch series need to make logical sense. One patch series should
> > > > > accomplish one change, and each patch represents a step of that change.
> > > >
> > > > It's about how you think. say if I wouldn't send the binman, I'm sure
> > > > this kind of discussion may not happen. In first mail you said
> > > > "something broken and how it can repair next" that indeed doesn't make
> > > > any sense of without understanding the whole series of changes.
> > >
> > > One part to that is that I had misunderstood a few things, but I really
> > > should not have to look at each patch before I can have an idea of what
> > > the series does. Your series is called "rockchip: Add new rk3399
> > > boards" and with the v3.1 change you made, the title is no longer true.
> > > You are doing that + introducing a new rk3399 u-boot dtsi without
> > > switching existing boards to it before adding new ones.
> > >
> > > From that moment, you needed to split your changes into two series.
> > > Instead of that, you made another series with mostly unrelated changes
> > > where you included an unrelated commit adding the pre-reloc entries to
> > > the dtsi created in the previous series.
> > >
> > > That's an issue for communication with the community.
> > >
> > > > Any new changes would come up with initial version, that what we
> > > > usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> > > > developers are using the same is adding one after another.
> > >
> > > But you already have boards in the tree that needs the tree. You can
> > > make individual commits for switching boards to the new dtsi, but you
> > > need to do that in the same series as introducing the dtsi if you are
> > > submitting both things at the same time. If you want to have them
> > > merged separately, then you can send device dtsi patches individually
> > > for that, but not as part of another unrelated series.
> > >
> > > > > This is how upstream contributions work, and it's a powerful way to
> > > > > allow both efficient code review and good code quality. We want to keep
> > > > > things as simple, explicit and well-described as possible, so that
> > > > > things are easy for reviewers and as many people as possible can
> > > > > understand the issue and share their thoughts about it.
> > > >
> > > > Yes, we adopt these principles and that what we are really working.
> > > >
> > > > > It is all part of communication with others as part of a community.
> > > > > It is definitely an implicit rule that is not written down somewhere
> > > > > precisely, but that's the social contract between developers that work
> > > > > on a common software project.
> > > > >
> > > > > In that, contributing to upstream is different than baseline tech
> > > > > company standards, because you have to take extra steps to describe
> > > > > your work and explain it to others. You must make sure you give them
> > > > > all the comfort they need to painlessly understand what you did.
> > > >
> > > > I hope all my communication was relevant to the topics, I can even
> > > > given the example how things were moved.
> > >
> > > Clearly there was a major communication issue between us. You only
> > > answered on technical topics and never about how your patch series is
> > > organized and what logical changes you are making.
> > >
> > > To be honest with you, I feel like we have a general communication
> > > issue where you only seem to focus on technical aspects, when the
> > > issues are about the meta-data of the changes such as commit messages,
> > > code comments and how changes are organized together.
> >
> > No one is better in all aspects, and things were improving no one cam
> > make global statements like this though he can find something gaps on
> > on previous one. You would better suggest on the commit where it
> > confused can make me better understanding.
>
> I am making such a global statement because I've had this issue with
> you a few times before already, and from what I could see about sunxi-
> related discussions, it seems that others have had similar issues
> before too. Each time, it feels like you are not discussing the issue
> and answering on mostly-unrelated technical topics, exactly like it's
> happening now.
>
> Now this is really nothing personal against you, I have no interest in
> pointing out things that need to be worked on in the work you submit in
> order to make you feel bad or inferior. But at this point, I feel like
> you are not understanding the global issue so I am bringing the
> discussion to more general conclusions, since we are talking about
> communication issues more generally.
>
> Everyone is trying to improve and it's perfectly fine to have flaws.
> For that matter, the situation was already reversed a few times when
> you reviewed some of my sunxi patches saying that the commit log was
> unclear, and I gladly accepted the criticism to make a better next
> revision. I also want to add that you make significant important
> contributions to lots of projects I really care about. This thread is a
> perfect example of that too, since I plan on using a RK3399 boards you
> are introducing for my personal use. So I am more than happy to see you
> do all that hard work and I truly value your contributions.
>
> Really, I'm mostly trying to help here and collaborate towards
> resolving the situation.

Thanks.

>
> So could you please send 3 distinct series that deal with each one of
> the aspects from the list that follows?

Just now I sent v5, which would resolve what you are thinking of,
please have a look.

^ permalink raw reply	[flat|nested] 72+ messages in thread
* Re: [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
  2019-04-26 17:42                                                   ` [U-Boot] " Jagan Teki
@ 2019-04-26 18:02                                                     ` Paul Kocialkowski
  -1 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 18:02 UTC (permalink / raw)
  To: Jagan Teki; +Cc: U-Boot-Denx, linux-rockchip, Akash Gajjar, linux-amarula

Hi,

Le vendredi 26 avril 2019 à 23:12 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 11:07 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > Le vendredi 26 avril 2019 à 22:51 +0530, Jagan Teki a écrit :
> > > On Fri, Apr 26, 2019 at 10:38 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > > > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > > > > > > boards are using this file and next series rest of the boards are
> > > > > > > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > > > > > > understand.
> > > > > > > > 
> > > > > > > > Yes, what you are describing is exactly the issue. It does not make
> > > > > > > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > > > > > > devices that use this file *before* switching existing devices to the
> > > > > > > > new common u-boot dtsi for rk3399 in the same series.
> > > > > > > 
> > > > > > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > > > > > > patch says it is an initial one and it is bit hard to add all at once.
> > > > > > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > > > > > unaffected to any of the existing dts files.
> > > > > > 
> > > > > > Again, it's not a technical issue. Your proposal works and has no
> > > > > > technical issue. The issue is in how the commits are grouped together.
> > > > > > Patch series need to make logical sense. One patch series should
> > > > > > accomplish one change, and each patch represents a step of that change.
> > > > > 
> > > > > It's about how you think. say if I wouldn't send the binman, I'm sure
> > > > > this kind of discussion may not happen. In first mail you said
> > > > > "something broken and how it can repair next" that indeed doesn't make
> > > > > any sense of without understanding the whole series of changes.
> > > > 
> > > > One part to that is that I had misunderstood a few things, but I really
> > > > should not have to look at each patch before I can have an idea of what
> > > > the series does. Your series is called "rockchip: Add new rk3399
> > > > boards" and with the v3.1 change you made, the title is no longer true.
> > > > You are doing that + introducing a new rk3399 u-boot dtsi without
> > > > switching existing boards to it before adding new ones.
> > > > 
> > > > From that moment, you needed to split your changes into two series.
> > > > Instead of that, you made another series with mostly unrelated changes
> > > > where you included an unrelated commit adding the pre-reloc entries to
> > > > the dtsi created in the previous series.
> > > > 
> > > > That's an issue for communication with the community.
> > > > 
> > > > > Any new changes would come up with initial version, that what we
> > > > > usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> > > > > developers are using the same is adding one after another.
> > > > 
> > > > But you already have boards in the tree that needs the tree. You can
> > > > make individual commits for switching boards to the new dtsi, but you
> > > > need to do that in the same series as introducing the dtsi if you are
> > > > submitting both things at the same time. If you want to have them
> > > > merged separately, then you can send device dtsi patches individually
> > > > for that, but not as part of another unrelated series.
> > > > 
> > > > > > This is how upstream contributions work, and it's a powerful way to
> > > > > > allow both efficient code review and good code quality. We want to keep
> > > > > > things as simple, explicit and well-described as possible, so that
> > > > > > things are easy for reviewers and as many people as possible can
> > > > > > understand the issue and share their thoughts about it.
> > > > > 
> > > > > Yes, we adopt these principles and that what we are really working.
> > > > > 
> > > > > > It is all part of communication with others as part of a community.
> > > > > > It is definitely an implicit rule that is not written down somewhere
> > > > > > precisely, but that's the social contract between developers that work
> > > > > > on a common software project.
> > > > > > 
> > > > > > In that, contributing to upstream is different than baseline tech
> > > > > > company standards, because you have to take extra steps to describe
> > > > > > your work and explain it to others. You must make sure you give them
> > > > > > all the comfort they need to painlessly understand what you did.
> > > > > 
> > > > > I hope all my communication was relevant to the topics, I can even
> > > > > given the example how things were moved.
> > > > 
> > > > Clearly there was a major communication issue between us. You only
> > > > answered on technical topics and never about how your patch series is
> > > > organized and what logical changes you are making.
> > > > 
> > > > To be honest with you, I feel like we have a general communication
> > > > issue where you only seem to focus on technical aspects, when the
> > > > issues are about the meta-data of the changes such as commit messages,
> > > > code comments and how changes are organized together.
> > > 
> > > No one is better in all aspects, and things were improving no one cam
> > > make global statements like this though he can find something gaps on
> > > on previous one. You would better suggest on the commit where it
> > > confused can make me better understanding.
> > 
> > I am making such a global statement because I've had this issue with
> > you a few times before already, and from what I could see about sunxi-
> > related discussions, it seems that others have had similar issues
> > before too. Each time, it feels like you are not discussing the issue
> > and answering on mostly-unrelated technical topics, exactly like it's
> > happening now.
> > 
> > Now this is really nothing personal against you, I have no interest in
> > pointing out things that need to be worked on in the work you submit in
> > order to make you feel bad or inferior. But at this point, I feel like
> > you are not understanding the global issue so I am bringing the
> > discussion to more general conclusions, since we are talking about
> > communication issues more generally.
> > 
> > Everyone is trying to improve and it's perfectly fine to have flaws.
> > For that matter, the situation was already reversed a few times when
> > you reviewed some of my sunxi patches saying that the commit log was
> > unclear, and I gladly accepted the criticism to make a better next
> > revision. I also want to add that you make significant important
> > contributions to lots of projects I really care about. This thread is a
> > perfect example of that too, since I plan on using a RK3399 boards you
> > are introducing for my personal use. So I am more than happy to see you
> > do all that hard work and I truly value your contributions.
> > 
> > Really, I'm mostly trying to help here and collaborate towards
> > resolving the situation.
> 
> Thanks.
> 
> > So could you please send 3 distinct series that deal with each one of
> > the aspects from the list that follows?
> 
> Just now I sent v5, which would resolve what you are thinking of,
> please have a look.

It seems that we're not quite there yet and you still need to split the
series. Looking forward to that!

Cheers,

Paul

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

^ permalink raw reply	[flat|nested] 72+ messages in thread
* [U-Boot] [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support
@ 2019-04-26 18:02                                                     ` Paul Kocialkowski
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Kocialkowski @ 2019-04-26 18:02 UTC (permalink / raw)
  To: u-boot

Hi,

Le vendredi 26 avril 2019 à 23:12 +0530, Jagan Teki a écrit :
> On Fri, Apr 26, 2019 at 11:07 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> > 
> > Le vendredi 26 avril 2019 à 22:51 +0530, Jagan Teki a écrit :
> > > On Fri, Apr 26, 2019 at 10:38 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > > 
> > > > Le vendredi 26 avril 2019 à 22:23 +0530, Jagan Teki a écrit :
> > > > > > > > > First series, I get introduced rk3399-u-boot.dtsi, and only the new
> > > > > > > > > boards are using this file and next series rest of the boards are
> > > > > > > > > using which indeed a valid step. what is inconsistent here, I don't
> > > > > > > > > understand.
> > > > > > > > 
> > > > > > > > Yes, what you are describing is exactly the issue. It does not make
> > > > > > > > sense to introduce a new common u-boot dtsi for rk3399 and add new
> > > > > > > > devices that use this file *before* switching existing devices to the
> > > > > > > > new common u-boot dtsi for rk3399 in the same series.
> > > > > > > 
> > > > > > > How come? existing boards doesn't use rk3399-u-boot.dtsi at all? as
> > > > > > > patch says it is an initial one and it is bit hard to add all at once.
> > > > > > > ie what I did for i.MX6. having said that rk3399-u-boot.dtsi is
> > > > > > > unaffected to any of the existing dts files.
> > > > > > 
> > > > > > Again, it's not a technical issue. Your proposal works and has no
> > > > > > technical issue. The issue is in how the commits are grouped together.
> > > > > > Patch series need to make logical sense. One patch series should
> > > > > > accomplish one change, and each patch represents a step of that change.
> > > > > 
> > > > > It's about how you think. say if I wouldn't send the binman, I'm sure
> > > > > this kind of discussion may not happen. In first mail you said
> > > > > "something broken and how it can repair next" that indeed doesn't make
> > > > > any sense of without understanding the whole series of changes.
> > > > 
> > > > One part to that is that I had misunderstood a few things, but I really
> > > > should not have to look at each patch before I can have an idea of what
> > > > the series does. Your series is called "rockchip: Add new rk3399
> > > > boards" and with the v3.1 change you made, the title is no longer true.
> > > > You are doing that + introducing a new rk3399 u-boot dtsi without
> > > > switching existing boards to it before adding new ones.
> > > > 
> > > > From that moment, you needed to split your changes into two series.
> > > > Instead of that, you made another series with mostly unrelated changes
> > > > where you included an unrelated commit adding the pre-reloc entries to
> > > > the dtsi created in the previous series.
> > > > 
> > > > That's an issue for communication with the community.
> > > > 
> > > > > Any new changes would come up with initial version, that what we
> > > > > usually supported, ie what we did -u-boot.dtsi changes to i.MX6 and
> > > > > developers are using the same is adding one after another.
> > > > 
> > > > But you already have boards in the tree that needs the tree. You can
> > > > make individual commits for switching boards to the new dtsi, but you
> > > > need to do that in the same series as introducing the dtsi if you are
> > > > submitting both things at the same time. If you want to have them
> > > > merged separately, then you can send device dtsi patches individually
> > > > for that, but not as part of another unrelated series.
> > > > 
> > > > > > This is how upstream contributions work, and it's a powerful way to
> > > > > > allow both efficient code review and good code quality. We want to keep
> > > > > > things as simple, explicit and well-described as possible, so that
> > > > > > things are easy for reviewers and as many people as possible can
> > > > > > understand the issue and share their thoughts about it.
> > > > > 
> > > > > Yes, we adopt these principles and that what we are really working.
> > > > > 
> > > > > > It is all part of communication with others as part of a community.
> > > > > > It is definitely an implicit rule that is not written down somewhere
> > > > > > precisely, but that's the social contract between developers that work
> > > > > > on a common software project.
> > > > > > 
> > > > > > In that, contributing to upstream is different than baseline tech
> > > > > > company standards, because you have to take extra steps to describe
> > > > > > your work and explain it to others. You must make sure you give them
> > > > > > all the comfort they need to painlessly understand what you did.
> > > > > 
> > > > > I hope all my communication was relevant to the topics, I can even
> > > > > given the example how things were moved.
> > > > 
> > > > Clearly there was a major communication issue between us. You only
> > > > answered on technical topics and never about how your patch series is
> > > > organized and what logical changes you are making.
> > > > 
> > > > To be honest with you, I feel like we have a general communication
> > > > issue where you only seem to focus on technical aspects, when the
> > > > issues are about the meta-data of the changes such as commit messages,
> > > > code comments and how changes are organized together.
> > > 
> > > No one is better in all aspects, and things were improving no one cam
> > > make global statements like this though he can find something gaps on
> > > on previous one. You would better suggest on the commit where it
> > > confused can make me better understanding.
> > 
> > I am making such a global statement because I've had this issue with
> > you a few times before already, and from what I could see about sunxi-
> > related discussions, it seems that others have had similar issues
> > before too. Each time, it feels like you are not discussing the issue
> > and answering on mostly-unrelated technical topics, exactly like it's
> > happening now.
> > 
> > Now this is really nothing personal against you, I have no interest in
> > pointing out things that need to be worked on in the work you submit in
> > order to make you feel bad or inferior. But at this point, I feel like
> > you are not understanding the global issue so I am bringing the
> > discussion to more general conclusions, since we are talking about
> > communication issues more generally.
> > 
> > Everyone is trying to improve and it's perfectly fine to have flaws.
> > For that matter, the situation was already reversed a few times when
> > you reviewed some of my sunxi patches saying that the commit log was
> > unclear, and I gladly accepted the criticism to make a better next
> > revision. I also want to add that you make significant important
> > contributions to lots of projects I really care about. This thread is a
> > perfect example of that too, since I plan on using a RK3399 boards you
> > are introducing for my personal use. So I am more than happy to see you
> > do all that hard work and I truly value your contributions.
> > 
> > Really, I'm mostly trying to help here and collaborate towards
> > resolving the situation.
> 
> Thanks.
> 
> > So could you please send 3 distinct series that deal with each one of
> > the aspects from the list that follows?
> 
> Just now I sent v5, which would resolve what you are thinking of,
> please have a look.

It seems that we're not quite there yet and you still need to split the
series. Looking forward to that!

Cheers,

Paul

^ permalink raw reply	[flat|nested] 72+ messages in thread
end of thread, other threads:[~2019-04-26 18:02 UTC | newest]

Thread overview: 72+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-25 17:34 [PATCH v3 00/13] rockchip: Add new rk3399 boards Jagan Teki
2019-04-25 17:34 ` [U-Boot] " Jagan Teki
     [not found] ` <20190425173427.13445-1-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
2019-04-25 17:34   ` [PATCH v3 01/13] rockchip: dts: rk3399: Sync rk3399-opp from Linux Jagan Teki
2019-04-25 17:34     ` [U-Boot] " Jagan Teki
2019-04-25 17:34   ` [PATCH v3 02/13] rockchip: dts: rk3399: Sync pwm2_pin_pull_down from Linux 5.1-rc2 Jagan Teki
2019-04-25 17:34     ` [U-Boot] " Jagan Teki
2019-04-25 17:34   ` [PATCH v3 03/13] rockchip: dts: rk3399: Create initial rk3399-u-boot.dtsi Jagan Teki
2019-04-25 17:34     ` [U-Boot] " Jagan Teki
     [not found]     ` <20190425173427.13445-4-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
2019-04-26 13:21       ` Jagan Teki
2019-04-26 13:21         ` [U-Boot] " Jagan Teki
2019-04-26 13:33         ` Paul Kocialkowski
2019-04-26 13:33           ` [U-Boot] " Paul Kocialkowski
2019-04-25 17:34   ` [PATCH v3 04/13] Kconfig: Add default SPL_FIT_GENERATOR for rockchip Jagan Teki
2019-04-25 17:34     ` [U-Boot] " Jagan Teki
2019-04-25 17:34   ` [PATCH v3 05/13] arm: rockchip: rk3399: Move common configs in Kconfig Jagan Teki
2019-04-25 17:34     ` [U-Boot] " Jagan Teki
2019-04-25 17:34   ` [PATCH v3 06/13] rockchip: rk3399: Add Orangepi RK3399 support Jagan Teki
2019-04-25 17:34     ` [U-Boot] " Jagan Teki
2019-04-26 14:17     ` Paul Kocialkowski
2019-04-26 14:17       ` [U-Boot] " Paul Kocialkowski
     [not found]       ` <51dab1c2fea1ca16b892c9face5fd4c6b451d07d.camel-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
2019-04-26 14:27         ` Jagan Teki
2019-04-26 14:27           ` [U-Boot] " Jagan Teki
2019-04-26 14:34           ` Paul Kocialkowski
2019-04-26 14:34             ` [U-Boot] " Paul Kocialkowski
     [not found]             ` <f89a6bbc7390db5f9ed6f7ad732b6451cdea15c4.camel-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
2019-04-26 14:45               ` Jagan Teki
2019-04-26 14:45                 ` [U-Boot] " Jagan Teki
2019-04-26 14:54                 ` Paul Kocialkowski
2019-04-26 14:54                   ` [U-Boot] " Paul Kocialkowski
     [not found]                   ` <5953e5f8b8d45cdc5c208c75b16e831391f3db08.camel-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
2019-04-26 15:01                     ` Jagan Teki
2019-04-26 15:01                       ` [U-Boot] " Jagan Teki
2019-04-26 15:12                       ` Paul Kocialkowski
2019-04-26 15:12                         ` [U-Boot] " Paul Kocialkowski
2019-04-26 15:18                         ` Jagan Teki
2019-04-26 15:18                           ` [U-Boot] " Jagan Teki
2019-04-26 15:38                           ` Paul Kocialkowski
2019-04-26 15:38                             ` [U-Boot] " Paul Kocialkowski
2019-04-26 15:48                             ` Jagan Teki
2019-04-26 15:48                               ` [U-Boot] " Jagan Teki
2019-04-26 16:08                               ` Paul Kocialkowski
2019-04-26 16:08                                 ` [U-Boot] " Paul Kocialkowski
2019-04-26 16:09                                 ` Philipp Tomsich
2019-04-26 16:09                                   ` [U-Boot] " Philipp Tomsich
     [not found]                                 ` <d5d26a75416da7249f21517e080cff2309393dfe.camel-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
2019-04-26 16:16                                   ` Jagan Teki
2019-04-26 16:16                                     ` [U-Boot] " Jagan Teki
2019-04-26 16:40                                     ` Paul Kocialkowski
2019-04-26 16:40                                       ` [U-Boot] " Paul Kocialkowski
2019-04-26 16:53                                       ` Jagan Teki
2019-04-26 16:53                                         ` [U-Boot] " Jagan Teki
2019-04-26 17:08                                         ` Paul Kocialkowski
2019-04-26 17:08                                           ` [U-Boot] " Paul Kocialkowski
2019-04-26 17:21                                           ` Jagan Teki
2019-04-26 17:21                                             ` [U-Boot] " Jagan Teki
2019-04-26 17:37                                             ` Paul Kocialkowski
2019-04-26 17:37                                               ` [U-Boot] " Paul Kocialkowski
     [not found]                                               ` <e1fad022ad1407df514ab8fd4d44485cf3e4f82a.camel-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
2019-04-26 17:42                                                 ` Jagan Teki
2019-04-26 17:42                                                   ` [U-Boot] " Jagan Teki
2019-04-26 18:02                                                   ` Paul Kocialkowski
2019-04-26 18:02                                                     ` [U-Boot] " Paul Kocialkowski
2019-04-25 17:34   ` [PATCH v3 07/13] rockchip: dts: rk3399: Sync rk3399-nanopi4.dtsi from Linux Jagan Teki
2019-04-25 17:34     ` [U-Boot] " Jagan Teki
2019-04-25 17:34   ` [PATCH v3 08/13] rockchip: dts: rk3399: nanopi4: Use CD pin as RK_FUNC_1 Jagan Teki
2019-04-25 17:34     ` [U-Boot] " Jagan Teki
2019-04-25 17:34   ` [PATCH v3 09/13] rockchip: rk3399: Add Nanopi M4 board support Jagan Teki
2019-04-25 17:34     ` [U-Boot] " Jagan Teki
2019-04-25 17:34   ` [PATCH v3 10/13] rockchip: rk3399: Add Nanopi NEO4 " Jagan Teki
2019-04-25 17:34     ` [U-Boot] " Jagan Teki
2019-04-25 17:34   ` [PATCH v3 11/13] rockchip: rk3399: Add Rockpro64 " Jagan Teki
2019-04-25 17:34     ` [U-Boot] " Jagan Teki
2019-04-25 17:34   ` [PATCH v3 12/13] rockchip: rk3399: Add Rock PI 4 support Jagan Teki
2019-04-25 17:34     ` [U-Boot] " Jagan Teki
2019-04-25 17:34   ` [PATCH v3 13/13] doc: rockchip: Add global doc for rk3399 build/flash Jagan Teki
2019-04-25 17:34     ` [U-Boot] " Jagan Teki

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.