* [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support
@ 2019-05-24 11:19 xieqinick at gmail.com
2019-05-24 18:23 ` Jagan Teki
` (2 more replies)
0 siblings, 3 replies; 43+ messages in thread
From: xieqinick at gmail.com @ 2019-05-24 11:19 UTC (permalink / raw)
To: u-boot
From: Nick <nick@khadas.com>
Khadas Edge is a board from Khadas, you can find the detail about it here:
https://www.khadas.com/edge
This patch add basic node for the board and make it able to bring up.
Specification
- Rockchip RK3399
- Dual-Channel 2GB/4GB LPDDR4
- SD card slot
- Onboard 16GB/32GB/128GB eMMC
- RTL8211FD 1Gbps
- AP6356S/AP6398S WiFI/BT
- HDMI Out, DP, MIPI DSI/CSI, eDP
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- Full 4 Lane M.2 Socket
- 16MB SPI Flash
- IR
- Programmable MCU
Signed-off-by: Nick <nick@khadas.com>
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3399-kedge-u-boot.dtsi | 10 +
arch/arm/dts/rk3399-kedge.dts | 611 ++++++++++++++++++++++++++++++++++
board/rockchip/evb_rk3399/MAINTAINERS | 7 +
configs/khadas-edge-rk3399_defconfig | 63 ++++
5 files changed, 692 insertions(+)
create mode 100644 arch/arm/dts/rk3399-kedge-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-kedge.dts
create mode 100644 configs/khadas-edge-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 31ef2b6..d9adecf 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -113,6 +113,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399-puma-ddr1600.dtb \
rk3399-puma-ddr1866.dtb \
rk3399-rock960.dtb \
+ rk3399-kedge.dtb
dtb-$(CONFIG_ROCKCHIP_RV1108) += \
rv1108-elgin-r1.dtb \
diff --git a/arch/arm/dts/rk3399-kedge-u-boot.dtsi b/arch/arm/dts/rk3399-kedge-u-boot.dtsi
new file mode 100644
index 0000000..bf0d54c
--- /dev/null
+++ b/arch/arm/dts/rk3399-kedge-u-boot.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Nick <nick@khadas.com>
+ */
+
+#include "rk3399-u-boot.dtsi"
+
+&sdmmc {
+ pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd &sdmmc_cd>;
+};
diff --git a/arch/arm/dts/rk3399-kedge.dts b/arch/arm/dts/rk3399-kedge.dts
new file mode 100644
index 0000000..e07e699
--- /dev/null
+++ b/arch/arm/dts/rk3399-kedge.dts
@@ -0,0 +1,611 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * RK3399-based Khadas boards device tree source
+ *
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com/edge)
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ model = "Khadas Edge";
+ compatible = "khadas,edge", "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>;
+ };
+
+ 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_host: vcc5v0-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio4 RK_PD1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&host_vbus_drv>;
+ regulator-name = "vcc5v0_host";
+ regulator-always-on;
+ };
+
+ 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>;
+ };
+
+ 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>;
+ };
+
+ 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_PA6 GPIO_ACTIVE_HIGH>;
+ label = "status_led";
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&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";
+};
+
+&i2c4 {
+ 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 = <22 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_apio2: LDO_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc1v8_apio2";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_vldo2: LDO_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "vcc_vldo2";
+
+ 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>;
+ };
+ };
+
+ vccio_sd: LDO_REG4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-init-microvolt = <3000000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcc_vldo5: LDO_REG5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "vcc_vldo5";
+
+ 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;
+ };
+ };
+ };
+ };
+};
+
+&i2c8 {
+ clock-frequency = <400000>;
+ i2c-scl-rising-time-ns = <160>;
+ i2c-scl-falling-time-ns = <30>;
+ status = "okay";
+};
+
+&io_domains {
+ bt656-supply = <&vcc1v8_apio2>;
+ audio-supply = <&vcca1v8_codec>;
+ sdmmc-supply = <&vccio_sd>;
+ gpio1830-supply = <&vcc_3v0>;
+ status = "okay";
+};
+
+&pinctrl {
+ usb2 {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins = <4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ gpio-leds {
+ leds_gpio: leds-gpio {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ cpu_b_sleep: cpu-b-sleep {
+ rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ gpu_sleep: gpu-sleep {
+ rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ pmic_int_l: pmic-int-l {
+ rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ rockchip-key {
+ power_key: power-key {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ 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_1v8>;
+ 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";
+};
+
+&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 = <&vccio_sd>;
+ 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";
+};
+
+&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";
+};
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index f55c92f..bcb058c 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
+
+KHADAS-EDGE
+M: Nick <nick@khadas.com>
+S: Maintained
+F: configs/khadas-edge-rk3399_defconfig
+F: arch/arm/dts/rk3399-kedge.dts
+F: arch/arm/dts/rk3399-kedge-u-boot.dtsi
diff --git a/configs/khadas-edge-rk3399_defconfig b/configs/khadas-edge-rk3399_defconfig
new file mode 100644
index 0000000..a9def59
--- /dev/null
+++ b/configs/khadas-edge-rk3399_defconfig
@@ -0,0 +1,63 @@
+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_NR_DRAM_BANKS=1
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-kedge.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_TEXT_BASE=0xff8c2000
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_SYS_PROMPT="kedge# "
+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_CMD_FS_UUID=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-kedge"
+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_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_PHY_REALTEK=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.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support
2019-05-24 11:19 [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support xieqinick at gmail.com
@ 2019-05-24 18:23 ` Jagan Teki
2019-05-25 3:44 ` Nick Xie
[not found] ` <1558696796-10745-1-git-send-email-xieqinick-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-06-17 8:56 ` xieqinick at gmail.com
2 siblings, 1 reply; 43+ messages in thread
From: Jagan Teki @ 2019-05-24 18:23 UTC (permalink / raw)
To: u-boot
+ CCed to mainatiners.
On Fri, May 24, 2019 at 5:52 PM <xieqinick@gmail.com> wrote:
>
> From: Nick <nick@khadas.com>
>
> Khadas Edge is a board from Khadas, you can find the detail about it here:
> https://www.khadas.com/edge
Drop this http from commit message, we usually don't keep.
>
> This patch add basic node for the board and make it able to bring up.
>
> Specification
> - Rockchip RK3399
> - Dual-Channel 2GB/4GB LPDDR4
> - SD card slot
> - Onboard 16GB/32GB/128GB eMMC
> - RTL8211FD 1Gbps
> - AP6356S/AP6398S WiFI/BT
> - HDMI Out, DP, MIPI DSI/CSI, eDP
> - USB 3.0, 2.0
> - USB Type C power and data
> - GPIO expansion ports
> - Full 4 Lane M.2 Socket
> - 16MB SPI Flash
> - IR
> - Programmable MCU
>
Hope you sync the dts from Linux, if not please submit it and aprove
first, if yes then add commit sha1. This would help to keep track of
syncing dts from Linux later and since dts files are more relatives
same from Linux it always better to approve Linux first interms of
binidngs and all.
> Signed-off-by: Nick <nick@khadas.com>
> ---
> arch/arm/dts/Makefile | 1 +
> arch/arm/dts/rk3399-kedge-u-boot.dtsi | 10 +
> arch/arm/dts/rk3399-kedge.dts | 611 ++++++++++++++++++++++++++++++++++
> board/rockchip/evb_rk3399/MAINTAINERS | 7 +
> configs/khadas-edge-rk3399_defconfig | 63 ++++
> 5 files changed, 692 insertions(+)
> create mode 100644 arch/arm/dts/rk3399-kedge-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-kedge.dts
> create mode 100644 configs/khadas-edge-rk3399_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 31ef2b6..d9adecf 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -113,6 +113,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> rk3399-puma-ddr1600.dtb \
> rk3399-puma-ddr1866.dtb \
> rk3399-rock960.dtb \
> + rk3399-kedge.dtb
Keep it in accending order.
>
> dtb-$(CONFIG_ROCKCHIP_RV1108) += \
> rv1108-elgin-r1.dtb \
> diff --git a/arch/arm/dts/rk3399-kedge-u-boot.dtsi b/arch/arm/dts/rk3399-kedge-u-boot.dtsi
> new file mode 100644
> index 0000000..bf0d54c
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-kedge-u-boot.dtsi
> @@ -0,0 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2019 Nick <nick@khadas.com>
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> +
> +&sdmmc {
> + pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd &sdmmc_cd>;
> +};
> diff --git a/arch/arm/dts/rk3399-kedge.dts b/arch/arm/dts/rk3399-kedge.dts
> new file mode 100644
> index 0000000..e07e699
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-kedge.dts
> @@ -0,0 +1,611 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * RK3399-based Khadas boards device tree source
> + *
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com/edge)
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + model = "Khadas Edge";
> + compatible = "khadas,edge", "rockchip,rk3399";
> +
[snip]
> + status = "okay";
> +};
> diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
> index f55c92f..bcb058c 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
> +
> +KHADAS-EDGE
Same here keep maintain the order.
> +M: Nick <nick@khadas.com>
> +S: Maintained
> +F: configs/khadas-edge-rk3399_defconfig
> +F: arch/arm/dts/rk3399-kedge.dts
> +F: arch/arm/dts/rk3399-kedge-u-boot.dtsi
> diff --git a/configs/khadas-edge-rk3399_defconfig b/configs/khadas-edge-rk3399_defconfig
> new file mode 100644
> index 0000000..a9def59
> --- /dev/null
> +++ b/configs/khadas-edge-rk3399_defconfig
> @@ -0,0 +1,63 @@
> +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_NR_DRAM_BANKS=1
> +CONFIG_SPL_STACK_R_ADDR=0x80000
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-kedge.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_TEXT_BASE=0xff8c2000
> +CONFIG_SPL_STACK_R=y
Seems like you are not using SPL, so use TPL that would take care of
rkbin ddr init like this patch does [1]
[1] https://patchwork.ozlabs.org/patch/1100945/
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support
2019-05-24 18:23 ` Jagan Teki
@ 2019-05-25 3:44 ` Nick Xie
2019-05-25 5:57 ` Jagan Teki
0 siblings, 1 reply; 43+ messages in thread
From: Nick Xie @ 2019-05-25 3:44 UTC (permalink / raw)
To: u-boot
Hello Jagan,
Thanks for your review.
> Hope you sync the dts from Linux, if not please submit it and aprove
> > first, if yes then add commit sha1. This would help to keep track of
> > syncing dts from Linux later and since dts files are more relatives
> > same from Linux it always better to approve Linux first interms of
> > binidngs and all.
As I haven't sent patches to linux upstream yet, my plan is to send patches
to u-boot first, then send patches to linux.
The dts of u-boot must sync from the mainline linux?
Thanks,
Best Regards,
Nick.
Jagan Teki <jagan@amarulasolutions.com> 于2019年5月25日周六 上午2:23写道：
> + CCed to mainatiners.
>
> On Fri, May 24, 2019 at 5:52 PM <xieqinick@gmail.com> wrote:
> >
> > From: Nick <nick@khadas.com>
> >
> > Khadas Edge is a board from Khadas, you can find the detail about it
> here:
> > https://www.khadas.com/edge
>
> Drop this http from commit message, we usually don't keep.
>
> >
> > This patch add basic node for the board and make it able to bring up.
> >
> > Specification
> > - Rockchip RK3399
> > - Dual-Channel 2GB/4GB LPDDR4
> > - SD card slot
> > - Onboard 16GB/32GB/128GB eMMC
> > - RTL8211FD 1Gbps
> > - AP6356S/AP6398S WiFI/BT
> > - HDMI Out, DP, MIPI DSI/CSI, eDP
> > - USB 3.0, 2.0
> > - USB Type C power and data
> > - GPIO expansion ports
> > - Full 4 Lane M.2 Socket
> > - 16MB SPI Flash
> > - IR
> > - Programmable MCU
> >
>
> Hope you sync the dts from Linux, if not please submit it and aprove
> first, if yes then add commit sha1. This would help to keep track of
> syncing dts from Linux later and since dts files are more relatives
> same from Linux it always better to approve Linux first interms of
> binidngs and all.
>
> > Signed-off-by: Nick <nick@khadas.com>
> > ---
> > arch/arm/dts/Makefile | 1 +
> > arch/arm/dts/rk3399-kedge-u-boot.dtsi | 10 +
> > arch/arm/dts/rk3399-kedge.dts | 611
> ++++++++++++++++++++++++++++++++++
> > board/rockchip/evb_rk3399/MAINTAINERS | 7 +
> > configs/khadas-edge-rk3399_defconfig | 63 ++++
> > 5 files changed, 692 insertions(+)
> > create mode 100644 arch/arm/dts/rk3399-kedge-u-boot.dtsi
> > create mode 100644 arch/arm/dts/rk3399-kedge.dts
> > create mode 100644 configs/khadas-edge-rk3399_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 31ef2b6..d9adecf 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -113,6 +113,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> > rk3399-puma-ddr1600.dtb \
> > rk3399-puma-ddr1866.dtb \
> > rk3399-rock960.dtb \
> > + rk3399-kedge.dtb
>
> Keep it in accending order.
>
> >
> > dtb-$(CONFIG_ROCKCHIP_RV1108) += \
> > rv1108-elgin-r1.dtb \
> > diff --git a/arch/arm/dts/rk3399-kedge-u-boot.dtsi
> b/arch/arm/dts/rk3399-kedge-u-boot.dtsi
> > new file mode 100644
> > index 0000000..bf0d54c
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3399-kedge-u-boot.dtsi
> > @@ -0,0 +1,10 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2019 Nick <nick@khadas.com>
> > + */
> > +
> > +#include "rk3399-u-boot.dtsi"
> > +
> > +&sdmmc {
> > + pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd &sdmmc_cd>;
> > +};
> > diff --git a/arch/arm/dts/rk3399-kedge.dts
> b/arch/arm/dts/rk3399-kedge.dts
> > new file mode 100644
> > index 0000000..e07e699
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3399-kedge.dts
> > @@ -0,0 +1,611 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * RK3399-based Khadas boards device tree source
> > + *
> > + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> > + * (https://www.khadas.com/edge)
> > + */
> > +
> > +/dts-v1/;
> > +#include <dt-bindings/input/linux-event-codes.h>
> > +#include "rk3399.dtsi"
> > +#include "rk3399-opp.dtsi"
> > +
> > +/ {
> > + model = "Khadas Edge";
> > + compatible = "khadas,edge", "rockchip,rk3399";
> > +
>
> [snip]
>
> > + status = "okay";
> > +};
> > diff --git a/board/rockchip/evb_rk3399/MAINTAINERS
> b/board/rockchip/evb_rk3399/MAINTAINERS
> > index f55c92f..bcb058c 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
> > +
> > +KHADAS-EDGE
>
> Same here keep maintain the order.
>
> > +M: Nick <nick@khadas.com>
> > +S: Maintained
> > +F: configs/khadas-edge-rk3399_defconfig
> > +F: arch/arm/dts/rk3399-kedge.dts
> > +F: arch/arm/dts/rk3399-kedge-u-boot.dtsi
> > diff --git a/configs/khadas-edge-rk3399_defconfig
> b/configs/khadas-edge-rk3399_defconfig
> > new file mode 100644
> > index 0000000..a9def59
> > --- /dev/null
> > +++ b/configs/khadas-edge-rk3399_defconfig
> > @@ -0,0 +1,63 @@
> > +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_NR_DRAM_BANKS=1
> > +CONFIG_SPL_STACK_R_ADDR=0x80000
> > +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> > +CONFIG_DEBUG_UART_CLOCK=24000000
> > +CONFIG_DEBUG_UART=y
> > +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-kedge.dtb"
> > +# CONFIG_DISPLAY_CPUINFO is not set
> > +CONFIG_DISPLAY_BOARDINFO_LATE=y
> > +CONFIG_SPL_TEXT_BASE=0xff8c2000
> > +CONFIG_SPL_STACK_R=y
>
> Seems like you are not using SPL, so use TPL that would take care of
> rkbin ddr init like this patch does [1]
>
> [1] https://patchwork.ozlabs.org/patch/1100945/
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support
2019-05-25 3:44 ` Nick Xie
@ 2019-05-25 5:57 ` Jagan Teki
2019-07-26 8:00 ` Kever Yang
0 siblings, 1 reply; 43+ messages in thread
From: Jagan Teki @ 2019-05-25 5:57 UTC (permalink / raw)
To: u-boot
On Sat, May 25, 2019 at 9:14 AM Nick Xie <xieqinick@gmail.com> wrote:
>
>
> Hello Jagan,
>
> Thanks for your review.
>
>> > Hope you sync the dts from Linux, if not please submit it and aprove
>> > first, if yes then add commit sha1. This would help to keep track of
>> > syncing dts from Linux later and since dts files are more relatives
>> > same from Linux it always better to approve Linux first interms of
>> > binidngs and all.
>
>
> As I haven't sent patches to linux upstream yet, my plan is to send patches to u-boot first, then send patches to linux.
>
> The dts of u-boot must sync from the mainline linux?
We use dts from Linux and we don't have specific maintainer for these
(atleast no need). DTS files coming from Linux means it's been
reviewed by respective maintainer along with devicetree ML.
^ permalink raw reply [flat|nested] 43+ messages in thread
* [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-05-24 11:19 [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support xieqinick at gmail.com
@ 2019-06-17 7:24 ` xieqinick at gmail.com
[not found] ` <1558696796-10745-1-git-send-email-xieqinick-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-06-17 8:56 ` xieqinick at gmail.com
2 siblings, 0 replies; 43+ messages in thread
From: xieqinick-Re5JQEeQqe8AvxtiuMwx3w @ 2019-06-17 7:24 UTC (permalink / raw)
To: kever.yang-TNX95d0MmH7DzftRWevZcw,
jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
sjg-F7+t8E8rja9g9hUCZPvPmw,
philipp.tomsich-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5,
paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nick-XW3xCAIBE2TQT0dZR+AlfA,
linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
u-boot-0aAXYlwwYIKGBzrmiIFOJg
From: Nick Xie <nick-XW3xCAIBE2TQT0dZR+AlfA@public.gmane.org>
Add devicetree support for Khadas Edge/Edge-V/Captain boards.
Khadas Edge is an expandable Rockchip RK3399 board with goldfinger.
Khadas Captain is the carrier board for Khadas Edge.
Khadas Edge-V is a Khadas VIM form factor Rockchip RK3399 board.
Specification
- Rockchip RK3399
- Dual-Channel 2GB/4GB LPDDR4
- SD card slot
- Onboard 16GB/32GB/128GB eMMC
- RTL8211FD 1Gbps
- AP6356S/AP6398S WiFI/BT
- HDMI Out, DP, MIPI DSI/CSI, eDP
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- Full 4 Lane M.2 Socket
- 16MB SPI Flash
- IR
- Programmable MCU
Commit details of rk3399-khadas-edge-*.dts sync from Mainline Linux Rockchip branch:
(Linux support already merged to Rockchip branch, will merge to mainline linux in 5.3)
"arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards"
(sha1: c2aacceedc86af87428d998e23a1aca24fd8aa2e)
Signed-off-by: Nick Xie <nick-XW3xCAIBE2TQT0dZR+AlfA@public.gmane.org>
---
Changes for v2:
- Sync dts from mainline linux
- Add TPL support
- Update defconfig file
- Drop http from commit message
arch/arm/dts/Makefile | 3 +
.../arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi | 7 +
arch/arm/dts/rk3399-khadas-edge-captain.dts | 27 +
arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi | 7 +
arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi | 7 +
arch/arm/dts/rk3399-khadas-edge-v.dts | 27 +
arch/arm/dts/rk3399-khadas-edge.dts | 13 +
arch/arm/dts/rk3399-khadas-edge.dtsi | 804 +++++++++++++++++++++
board/rockchip/evb_rk3399/MAINTAINERS | 18 +
configs/khadas-edge-captain-rk3399_defconfig | 67 ++
configs/khadas-edge-rk3399_defconfig | 65 ++
configs/khadas-edge-v-rk3399_defconfig | 67 ++
12 files changed, 1112 insertions(+)
create mode 100644 arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-khadas-edge-captain.dts
create mode 100644 arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-khadas-edge-v.dts
create mode 100644 arch/arm/dts/rk3399-khadas-edge.dts
create mode 100644 arch/arm/dts/rk3399-khadas-edge.dtsi
create mode 100644 configs/khadas-edge-captain-rk3399_defconfig
create mode 100644 configs/khadas-edge-rk3399_defconfig
create mode 100644 configs/khadas-edge-v-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 528fb90..824844a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -106,6 +106,9 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399-ficus.dtb \
rk3399-firefly.dtb \
rk3399-gru-bob.dtb \
+ rk3399-khadas-edge.dtb \
+ rk3399-khadas-edge-captain.dtb \
+ rk3399-khadas-edge-v.dtb \
rk3399-nanopc-t4.dtb \
rk3399-nanopi-m4.dtb \
rk3399-nanopi-neo4.dtb \
diff --git a/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
new file mode 100644
index 0000000..569d01e
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+#include "rk3399-khadas-edge-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-khadas-edge-captain.dts b/arch/arm/dts/rk3399-khadas-edge-captain.dts
new file mode 100644
index 0000000..8302e51
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-captain.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include "rk3399-khadas-edge.dtsi"
+
+/ {
+ model = "Khadas Edge-Captain";
+ compatible = "khadas,edge-captain", "rockchip,rk3399";
+};
+
+&gmac {
+ status = "okay";
+};
+
+&pcie_phy {
+ status = "okay";
+};
+
+&pcie0 {
+ ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+ num-lanes = <4>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
new file mode 100644
index 0000000..b4d80c3
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+#include "rk3399-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
new file mode 100644
index 0000000..569d01e
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+#include "rk3399-khadas-edge-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-khadas-edge-v.dts b/arch/arm/dts/rk3399-khadas-edge-v.dts
new file mode 100644
index 0000000..f5dcb99
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-v.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include "rk3399-khadas-edge.dtsi"
+
+/ {
+ model = "Khadas Edge-V";
+ compatible = "khadas,edge-v", "rockchip,rk3399";
+};
+
+&gmac {
+ status = "okay";
+};
+
+&pcie_phy {
+ status = "okay";
+};
+
+&pcie0 {
+ ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+ num-lanes = <4>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3399-khadas-edge.dts b/arch/arm/dts/rk3399-khadas-edge.dts
new file mode 100644
index 0000000..31616e7
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include "rk3399-khadas-edge.dtsi"
+
+/ {
+ model = "Khadas Edge";
+ compatible = "khadas,edge", "rockchip,rk3399";
+};
diff --git a/arch/arm/dts/rk3399-khadas-edge.dtsi b/arch/arm/dts/rk3399-khadas-edge.dtsi
new file mode 100644
index 0000000..4944d78
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge.dtsi
@@ -0,0 +1,804 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.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>;
+ };
+
+ 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 = <&gpio2 RK_PD4 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>;
+ };
+
+ vcc3v3_pcie: vcc3v3-pcie-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_pcie";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vsys_3v3>;
+ };
+
+ /* 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_PD1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_host_en>;
+ regulator-name = "vcc5v0_host";
+ regulator-always-on;
+ vin-supply = <&vsys_5v0>;
+ };
+
+ 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 = <&vsys_3v3>;
+ };
+
+ vsys: vsys {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vsys_3v3: vsys-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vsys>;
+ };
+
+ vsys_5v0: vsys-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_5v0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vsys>;
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1800000>;
+ poll-interval = <100>;
+
+ recovery {
+ label = "Recovery";
+ linux,code = <KEY_VENDOR>;
+ press-threshold-microvolt = <18000>;
+ };
+ };
+
+ 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 = <&sys_led_gpio>, <&user_led_gpio>;
+
+ sys-led {
+ label = "sys_led";
+ linux,default-trigger = "heartbeat";
+ gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led {
+ label = "user_led";
+ default-state = "off";
+ gpios = <&gpio4 RK_PD0 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ cooling-levels = <0 150 200 255>;
+ #cooling-cells = <2>;
+ fan-supply = <&vsys_5v0>;
+ pwms = <&pwm0 0 40000 0>;
+ };
+};
+
+&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>;
+};
+
+&cpu_thermal {
+ trips {
+ cpu_warm: cpu_warm {
+ temperature = <55000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_hot: cpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map2 {
+ trip = <&cpu_warm>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map3 {
+ trip = <&cpu_hot>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+&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>;
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
+&gpu_thermal {
+ trips {
+ gpu_warm: gpu_warm {
+ temperature = <55000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ gpu_hot: gpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map1 {
+ trip = <&gpu_warm>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map2 {
+ trip = <&gpu_hot>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "okay";
+};
+
+&hdmi_sound {
+ 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 = <168>;
+ i2c-scl-falling-time-ns = <4>;
+ status = "okay";
+
+ rk808: pmic@1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <RK_PC6 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 = <&vsys_3v3>;
+ vcc2-supply = <&vsys_3v3>;
+ vcc3-supply = <&vsys_3v3>;
+ vcc4-supply = <&vsys_3v3>;
+ vcc6-supply = <&vsys_3v3>;
+ vcc7-supply = <&vsys_3v3>;
+ vcc8-supply = <&vsys_3v3>;
+ vcc9-supply = <&vsys_3v3>;
+ vcc10-supply = <&vsys_3v3>;
+ vcc11-supply = <&vsys_3v3>;
+ vcc12-supply = <&vsys_3v3>;
+ 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_apio2: LDO_REG1 {
+ regulator-name = "vcc1v8_apio2";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_vldo2: LDO_REG2 {
+ regulator-name = "vcc_vldo2";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_pmupll: LDO_REG3 {
+ regulator-name = "vcc1v8_pmupll";
+ 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>;
+ };
+ };
+
+ vccio_sd: LDO_REG4 {
+ regulator-name = "vccio_sd";
+ 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>;
+ };
+ };
+
+ vcc_vldo5: LDO_REG5 {
+ regulator-name = "vcc_vldo5";
+ 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>;
+ };
+ };
+
+ vcc1v8_codec: LDO_REG7 {
+ 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;
+ };
+ };
+
+ 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 = <&cpu_b_sleep>;
+ 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 = <&vsys_3v3>;
+
+ 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-name = "vdd_gpu";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vsys_3v3>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&i2c8 {
+ clock-frequency = <400000>;
+ i2c-scl-rising-time-ns = <160>;
+ i2c-scl-falling-time-ns = <30>;
+ 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 {
+ bt656-supply = <&vcc1v8_apio2>;
+ audio-supply = <&vcc1v8_codec>;
+ sdmmc-supply = <&vccio_sd>;
+ gpio1830-supply = <&vcc_3v0>;
+ status = "okay";
+};
+
+&pmu_io_domains {
+ pmu1830-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&pinctrl {
+ bt {
+ 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 {
+ rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_l: bt-wake-l {
+ rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ buttons {
+ pwrbtn: pwrbtn {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ leds {
+ sys_led_gpio: sys_led-gpio {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ user_led_gpio: user_led-gpio {
+ rockchip,pins = <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ cpu_b_sleep: cpu-b-sleep {
+ rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ gpu_sleep: gpu-sleep {
+ rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ sdio-pwrseq {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins = <2 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ usb2 {
+ vcc5v0_host_en: vcc5v0-host-en {
+ rockchip,pins = <4 RK_PD1 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>;
+ };
+ };
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcca1v8_s3>;
+ status = "okay";
+};
+
+&sdio0 {
+ /* WiFi & BT combo module Ampak AP6356S */
+ bus-width = <4>;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
+ sd-uhs-sdr104;
+ vqmmc-supply = <&vcc1v8_s3>;
+ vmmc-supply = <&vccio_sd>;
+ status = "okay";
+
+ brcmf: wifi@1 {
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;
+ interrupt-names = "host-wake";
+ brcm,drive-strength = <5>;
+ 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>;
+ 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_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 = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
+ max-speed = <4000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_reg_on_h &bt_host_wake_l &bt_wake_l>;
+ vbat-supply = <&vsys_3v3>;
+ vddio-supply = <&vcc_1v8>;
+ };
+};
+
+&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 3308b35..d9711ab 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -6,6 +6,24 @@ F: include/configs/evb_rk3399.h
F: configs/evb-rk3399_defconfig
F: configs/firefly-rk3399_defconfig
+KHADAS-EDGE
+M: Nick Xie <nick-XW3xCAIBE2TQT0dZR+AlfA@public.gmane.org>
+S: Maintained
+F: configs/khadas-edge-rk3399_defconfig
+F: arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
+
+KHADAS-EDGE-CAPTAIN
+M: Nick Xie <nick-XW3xCAIBE2TQT0dZR+AlfA@public.gmane.org>
+S: Maintained
+F: configs/khadas-edge-captain-rk3399_defconfig
+F: arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
+
+KHADAS-EDGE-V
+M: Nick Xie <nick-XW3xCAIBE2TQT0dZR+AlfA@public.gmane.org>
+S: Maintained
+F: configs/khadas-edge-v-rk3399_defconfig
+F: arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
+
NANOPC-T4
M: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
S: Maintained
diff --git a/configs/khadas-edge-captain-rk3399_defconfig b/configs/khadas-edge-captain-rk3399_defconfig
new file mode 100644
index 0000000..306b1b9
--- /dev/null
+++ b/configs/khadas-edge-captain-rk3399_defconfig
@@ -0,0 +1,67 @@
+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=0x50000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-captain.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
+CONFIG_TPL=y
+CONFIG_SYS_PROMPT="kedge# "
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_UUID=y
+CONFIG_CMD_FS_UUID=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-captain"
+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_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_PHY_REALTEK=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_SPL_TINY_MEMSET=y
+CONFIG_ERRNO_STR=y
diff --git a/configs/khadas-edge-rk3399_defconfig b/configs/khadas-edge-rk3399_defconfig
new file mode 100644
index 0000000..0e33911
--- /dev/null
+++ b/configs/khadas-edge-rk3399_defconfig
@@ -0,0 +1,65 @@
+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=0x50000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
+CONFIG_TPL=y
+CONFIG_SYS_PROMPT="kedge# "
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_UUID=y
+CONFIG_CMD_FS_UUID=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge"
+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_SPL_TINY_MEMSET=y
+CONFIG_ERRNO_STR=y
diff --git a/configs/khadas-edge-v-rk3399_defconfig b/configs/khadas-edge-v-rk3399_defconfig
new file mode 100644
index 0000000..59bf5ca
--- /dev/null
+++ b/configs/khadas-edge-v-rk3399_defconfig
@@ -0,0 +1,67 @@
+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=0x50000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-v.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
+CONFIG_TPL=y
+CONFIG_SYS_PROMPT="kedge# "
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_UUID=y
+CONFIG_CMD_FS_UUID=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-v"
+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_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_PHY_REALTEK=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_SPL_TINY_MEMSET=y
+CONFIG_ERRNO_STR=y
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-17 7:24 ` xieqinick at gmail.com
0 siblings, 0 replies; 43+ messages in thread
From: xieqinick at gmail.com @ 2019-06-17 7:24 UTC (permalink / raw)
To: u-boot
From: Nick Xie <nick@khadas.com>
Add devicetree support for Khadas Edge/Edge-V/Captain boards.
Khadas Edge is an expandable Rockchip RK3399 board with goldfinger.
Khadas Captain is the carrier board for Khadas Edge.
Khadas Edge-V is a Khadas VIM form factor Rockchip RK3399 board.
Specification
- Rockchip RK3399
- Dual-Channel 2GB/4GB LPDDR4
- SD card slot
- Onboard 16GB/32GB/128GB eMMC
- RTL8211FD 1Gbps
- AP6356S/AP6398S WiFI/BT
- HDMI Out, DP, MIPI DSI/CSI, eDP
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- Full 4 Lane M.2 Socket
- 16MB SPI Flash
- IR
- Programmable MCU
Commit details of rk3399-khadas-edge-*.dts sync from Mainline Linux Rockchip branch:
(Linux support already merged to Rockchip branch, will merge to mainline linux in 5.3)
"arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards"
(sha1: c2aacceedc86af87428d998e23a1aca24fd8aa2e)
Signed-off-by: Nick Xie <nick@khadas.com>
---
Changes for v2:
- Sync dts from mainline linux
- Add TPL support
- Update defconfig file
- Drop http from commit message
arch/arm/dts/Makefile | 3 +
.../arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi | 7 +
arch/arm/dts/rk3399-khadas-edge-captain.dts | 27 +
arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi | 7 +
arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi | 7 +
arch/arm/dts/rk3399-khadas-edge-v.dts | 27 +
arch/arm/dts/rk3399-khadas-edge.dts | 13 +
arch/arm/dts/rk3399-khadas-edge.dtsi | 804 +++++++++++++++++++++
board/rockchip/evb_rk3399/MAINTAINERS | 18 +
configs/khadas-edge-captain-rk3399_defconfig | 67 ++
configs/khadas-edge-rk3399_defconfig | 65 ++
configs/khadas-edge-v-rk3399_defconfig | 67 ++
12 files changed, 1112 insertions(+)
create mode 100644 arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-khadas-edge-captain.dts
create mode 100644 arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-khadas-edge-v.dts
create mode 100644 arch/arm/dts/rk3399-khadas-edge.dts
create mode 100644 arch/arm/dts/rk3399-khadas-edge.dtsi
create mode 100644 configs/khadas-edge-captain-rk3399_defconfig
create mode 100644 configs/khadas-edge-rk3399_defconfig
create mode 100644 configs/khadas-edge-v-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 528fb90..824844a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -106,6 +106,9 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399-ficus.dtb \
rk3399-firefly.dtb \
rk3399-gru-bob.dtb \
+ rk3399-khadas-edge.dtb \
+ rk3399-khadas-edge-captain.dtb \
+ rk3399-khadas-edge-v.dtb \
rk3399-nanopc-t4.dtb \
rk3399-nanopi-m4.dtb \
rk3399-nanopi-neo4.dtb \
diff --git a/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
new file mode 100644
index 0000000..569d01e
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+#include "rk3399-khadas-edge-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-khadas-edge-captain.dts b/arch/arm/dts/rk3399-khadas-edge-captain.dts
new file mode 100644
index 0000000..8302e51
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-captain.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include "rk3399-khadas-edge.dtsi"
+
+/ {
+ model = "Khadas Edge-Captain";
+ compatible = "khadas,edge-captain", "rockchip,rk3399";
+};
+
+&gmac {
+ status = "okay";
+};
+
+&pcie_phy {
+ status = "okay";
+};
+
+&pcie0 {
+ ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+ num-lanes = <4>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
new file mode 100644
index 0000000..b4d80c3
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+#include "rk3399-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
new file mode 100644
index 0000000..569d01e
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+#include "rk3399-khadas-edge-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-khadas-edge-v.dts b/arch/arm/dts/rk3399-khadas-edge-v.dts
new file mode 100644
index 0000000..f5dcb99
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-v.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include "rk3399-khadas-edge.dtsi"
+
+/ {
+ model = "Khadas Edge-V";
+ compatible = "khadas,edge-v", "rockchip,rk3399";
+};
+
+&gmac {
+ status = "okay";
+};
+
+&pcie_phy {
+ status = "okay";
+};
+
+&pcie0 {
+ ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+ num-lanes = <4>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3399-khadas-edge.dts b/arch/arm/dts/rk3399-khadas-edge.dts
new file mode 100644
index 0000000..31616e7
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include "rk3399-khadas-edge.dtsi"
+
+/ {
+ model = "Khadas Edge";
+ compatible = "khadas,edge", "rockchip,rk3399";
+};
diff --git a/arch/arm/dts/rk3399-khadas-edge.dtsi b/arch/arm/dts/rk3399-khadas-edge.dtsi
new file mode 100644
index 0000000..4944d78
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge.dtsi
@@ -0,0 +1,804 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.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>;
+ };
+
+ 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 = <&gpio2 RK_PD4 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>;
+ };
+
+ vcc3v3_pcie: vcc3v3-pcie-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_pcie";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vsys_3v3>;
+ };
+
+ /* 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_PD1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_host_en>;
+ regulator-name = "vcc5v0_host";
+ regulator-always-on;
+ vin-supply = <&vsys_5v0>;
+ };
+
+ 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 = <&vsys_3v3>;
+ };
+
+ vsys: vsys {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vsys_3v3: vsys-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vsys>;
+ };
+
+ vsys_5v0: vsys-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_5v0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vsys>;
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1800000>;
+ poll-interval = <100>;
+
+ recovery {
+ label = "Recovery";
+ linux,code = <KEY_VENDOR>;
+ press-threshold-microvolt = <18000>;
+ };
+ };
+
+ 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 = <&sys_led_gpio>, <&user_led_gpio>;
+
+ sys-led {
+ label = "sys_led";
+ linux,default-trigger = "heartbeat";
+ gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led {
+ label = "user_led";
+ default-state = "off";
+ gpios = <&gpio4 RK_PD0 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ cooling-levels = <0 150 200 255>;
+ #cooling-cells = <2>;
+ fan-supply = <&vsys_5v0>;
+ pwms = <&pwm0 0 40000 0>;
+ };
+};
+
+&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>;
+};
+
+&cpu_thermal {
+ trips {
+ cpu_warm: cpu_warm {
+ temperature = <55000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_hot: cpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map2 {
+ trip = <&cpu_warm>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map3 {
+ trip = <&cpu_hot>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+&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>;
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
+&gpu_thermal {
+ trips {
+ gpu_warm: gpu_warm {
+ temperature = <55000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ gpu_hot: gpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map1 {
+ trip = <&gpu_warm>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map2 {
+ trip = <&gpu_hot>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "okay";
+};
+
+&hdmi_sound {
+ 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 = <168>;
+ i2c-scl-falling-time-ns = <4>;
+ status = "okay";
+
+ rk808: pmic at 1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <RK_PC6 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 = <&vsys_3v3>;
+ vcc2-supply = <&vsys_3v3>;
+ vcc3-supply = <&vsys_3v3>;
+ vcc4-supply = <&vsys_3v3>;
+ vcc6-supply = <&vsys_3v3>;
+ vcc7-supply = <&vsys_3v3>;
+ vcc8-supply = <&vsys_3v3>;
+ vcc9-supply = <&vsys_3v3>;
+ vcc10-supply = <&vsys_3v3>;
+ vcc11-supply = <&vsys_3v3>;
+ vcc12-supply = <&vsys_3v3>;
+ 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_apio2: LDO_REG1 {
+ regulator-name = "vcc1v8_apio2";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_vldo2: LDO_REG2 {
+ regulator-name = "vcc_vldo2";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_pmupll: LDO_REG3 {
+ regulator-name = "vcc1v8_pmupll";
+ 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>;
+ };
+ };
+
+ vccio_sd: LDO_REG4 {
+ regulator-name = "vccio_sd";
+ 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>;
+ };
+ };
+
+ vcc_vldo5: LDO_REG5 {
+ regulator-name = "vcc_vldo5";
+ 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>;
+ };
+ };
+
+ vcc1v8_codec: LDO_REG7 {
+ 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;
+ };
+ };
+
+ 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 = <&cpu_b_sleep>;
+ 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 = <&vsys_3v3>;
+
+ 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-name = "vdd_gpu";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vsys_3v3>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&i2c8 {
+ clock-frequency = <400000>;
+ i2c-scl-rising-time-ns = <160>;
+ i2c-scl-falling-time-ns = <30>;
+ 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 {
+ bt656-supply = <&vcc1v8_apio2>;
+ audio-supply = <&vcc1v8_codec>;
+ sdmmc-supply = <&vccio_sd>;
+ gpio1830-supply = <&vcc_3v0>;
+ status = "okay";
+};
+
+&pmu_io_domains {
+ pmu1830-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&pinctrl {
+ bt {
+ 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 {
+ rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_l: bt-wake-l {
+ rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ buttons {
+ pwrbtn: pwrbtn {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ leds {
+ sys_led_gpio: sys_led-gpio {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ user_led_gpio: user_led-gpio {
+ rockchip,pins = <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ cpu_b_sleep: cpu-b-sleep {
+ rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ gpu_sleep: gpu-sleep {
+ rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ sdio-pwrseq {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins = <2 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ usb2 {
+ vcc5v0_host_en: vcc5v0-host-en {
+ rockchip,pins = <4 RK_PD1 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>;
+ };
+ };
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcca1v8_s3>;
+ status = "okay";
+};
+
+&sdio0 {
+ /* WiFi & BT combo module Ampak AP6356S */
+ bus-width = <4>;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
+ sd-uhs-sdr104;
+ vqmmc-supply = <&vcc1v8_s3>;
+ vmmc-supply = <&vccio_sd>;
+ status = "okay";
+
+ brcmf: wifi at 1 {
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;
+ interrupt-names = "host-wake";
+ brcm,drive-strength = <5>;
+ 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>;
+ 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_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 = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
+ max-speed = <4000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_reg_on_h &bt_host_wake_l &bt_wake_l>;
+ vbat-supply = <&vsys_3v3>;
+ vddio-supply = <&vcc_1v8>;
+ };
+};
+
+&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 3308b35..d9711ab 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -6,6 +6,24 @@ F: include/configs/evb_rk3399.h
F: configs/evb-rk3399_defconfig
F: configs/firefly-rk3399_defconfig
+KHADAS-EDGE
+M: Nick Xie <nick@khadas.com>
+S: Maintained
+F: configs/khadas-edge-rk3399_defconfig
+F: arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
+
+KHADAS-EDGE-CAPTAIN
+M: Nick Xie <nick@khadas.com>
+S: Maintained
+F: configs/khadas-edge-captain-rk3399_defconfig
+F: arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
+
+KHADAS-EDGE-V
+M: Nick Xie <nick@khadas.com>
+S: Maintained
+F: configs/khadas-edge-v-rk3399_defconfig
+F: arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
+
NANOPC-T4
M: Jagan Teki <jagan@amarulasolutions.com>
S: Maintained
diff --git a/configs/khadas-edge-captain-rk3399_defconfig b/configs/khadas-edge-captain-rk3399_defconfig
new file mode 100644
index 0000000..306b1b9
--- /dev/null
+++ b/configs/khadas-edge-captain-rk3399_defconfig
@@ -0,0 +1,67 @@
+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=0x50000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-captain.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
+CONFIG_TPL=y
+CONFIG_SYS_PROMPT="kedge# "
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_UUID=y
+CONFIG_CMD_FS_UUID=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-captain"
+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_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_PHY_REALTEK=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_SPL_TINY_MEMSET=y
+CONFIG_ERRNO_STR=y
diff --git a/configs/khadas-edge-rk3399_defconfig b/configs/khadas-edge-rk3399_defconfig
new file mode 100644
index 0000000..0e33911
--- /dev/null
+++ b/configs/khadas-edge-rk3399_defconfig
@@ -0,0 +1,65 @@
+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=0x50000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
+CONFIG_TPL=y
+CONFIG_SYS_PROMPT="kedge# "
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_UUID=y
+CONFIG_CMD_FS_UUID=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge"
+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_SPL_TINY_MEMSET=y
+CONFIG_ERRNO_STR=y
diff --git a/configs/khadas-edge-v-rk3399_defconfig b/configs/khadas-edge-v-rk3399_defconfig
new file mode 100644
index 0000000..59bf5ca
--- /dev/null
+++ b/configs/khadas-edge-v-rk3399_defconfig
@@ -0,0 +1,67 @@
+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=0x50000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-v.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
+CONFIG_TPL=y
+CONFIG_SYS_PROMPT="kedge# "
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_UUID=y
+CONFIG_CMD_FS_UUID=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-v"
+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_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_PHY_REALTEK=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_SPL_TINY_MEMSET=y
+CONFIG_ERRNO_STR=y
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-05-24 11:19 [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support xieqinick at gmail.com
2019-05-24 18:23 ` Jagan Teki
[not found] ` <1558696796-10745-1-git-send-email-xieqinick-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2019-06-17 8:56 ` xieqinick at gmail.com
2019-06-18 7:21 ` Jagan Teki
2 siblings, 1 reply; 43+ messages in thread
From: xieqinick at gmail.com @ 2019-06-17 8:56 UTC (permalink / raw)
To: u-boot
From: Nick Xie <nick@khadas.com>
Add devicetree support for Khadas Edge/Edge-V/Captain boards.
Khadas Edge is an expandable Rockchip RK3399 board with goldfinger.
Khadas Captain is the carrier board for Khadas Edge.
Khadas Edge-V is a Khadas VIM form factor Rockchip RK3399 board.
Specification
- Rockchip RK3399
- Dual-Channel 2GB/4GB LPDDR4
- SD card slot
- Onboard 16GB/32GB/128GB eMMC
- RTL8211FD 1Gbps
- AP6356S/AP6398S WiFI/BT
- HDMI Out, DP, MIPI DSI/CSI, eDP
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- Full 4 Lane M.2 Socket
- 16MB SPI Flash
- IR
- Programmable MCU
Commit details of rk3399-khadas-edge-*.dts sync from Mainline Linux Rockchip branch:
(Linux support already merged to Rockchip branch, will merge to mainline linux in 5.3)
"arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards"
(sha1: c2aacceedc86af87428d998e23a1aca24fd8aa2e)
Signed-off-by: Nick Xie <nick@khadas.com>
---
Changes for v2:
- Sync dts from mainline linux
- Add TPL support
- Update defconfig file
- Drop http from commit message
arch/arm/dts/Makefile | 3 +
.../arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi | 7 +
arch/arm/dts/rk3399-khadas-edge-captain.dts | 27 +
arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi | 7 +
arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi | 7 +
arch/arm/dts/rk3399-khadas-edge-v.dts | 27 +
arch/arm/dts/rk3399-khadas-edge.dts | 13 +
arch/arm/dts/rk3399-khadas-edge.dtsi | 804 +++++++++++++++++++++
board/rockchip/evb_rk3399/MAINTAINERS | 18 +
configs/khadas-edge-captain-rk3399_defconfig | 67 ++
configs/khadas-edge-rk3399_defconfig | 65 ++
configs/khadas-edge-v-rk3399_defconfig | 67 ++
12 files changed, 1112 insertions(+)
create mode 100644 arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-khadas-edge-captain.dts
create mode 100644 arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-khadas-edge-v.dts
create mode 100644 arch/arm/dts/rk3399-khadas-edge.dts
create mode 100644 arch/arm/dts/rk3399-khadas-edge.dtsi
create mode 100644 configs/khadas-edge-captain-rk3399_defconfig
create mode 100644 configs/khadas-edge-rk3399_defconfig
create mode 100644 configs/khadas-edge-v-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 528fb90..824844a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -106,6 +106,9 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399-ficus.dtb \
rk3399-firefly.dtb \
rk3399-gru-bob.dtb \
+ rk3399-khadas-edge.dtb \
+ rk3399-khadas-edge-captain.dtb \
+ rk3399-khadas-edge-v.dtb \
rk3399-nanopc-t4.dtb \
rk3399-nanopi-m4.dtb \
rk3399-nanopi-neo4.dtb \
diff --git a/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
new file mode 100644
index 0000000..569d01e
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+#include "rk3399-khadas-edge-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-khadas-edge-captain.dts b/arch/arm/dts/rk3399-khadas-edge-captain.dts
new file mode 100644
index 0000000..8302e51
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-captain.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include "rk3399-khadas-edge.dtsi"
+
+/ {
+ model = "Khadas Edge-Captain";
+ compatible = "khadas,edge-captain", "rockchip,rk3399";
+};
+
+&gmac {
+ status = "okay";
+};
+
+&pcie_phy {
+ status = "okay";
+};
+
+&pcie0 {
+ ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+ num-lanes = <4>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
new file mode 100644
index 0000000..b4d80c3
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+#include "rk3399-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
new file mode 100644
index 0000000..569d01e
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
@@ -0,0 +1,7 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+#include "rk3399-khadas-edge-u-boot.dtsi"
diff --git a/arch/arm/dts/rk3399-khadas-edge-v.dts b/arch/arm/dts/rk3399-khadas-edge-v.dts
new file mode 100644
index 0000000..f5dcb99
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge-v.dts
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include "rk3399-khadas-edge.dtsi"
+
+/ {
+ model = "Khadas Edge-V";
+ compatible = "khadas,edge-v", "rockchip,rk3399";
+};
+
+&gmac {
+ status = "okay";
+};
+
+&pcie_phy {
+ status = "okay";
+};
+
+&pcie0 {
+ ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+ num-lanes = <4>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3399-khadas-edge.dts b/arch/arm/dts/rk3399-khadas-edge.dts
new file mode 100644
index 0000000..31616e7
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge.dts
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include "rk3399-khadas-edge.dtsi"
+
+/ {
+ model = "Khadas Edge";
+ compatible = "khadas,edge", "rockchip,rk3399";
+};
diff --git a/arch/arm/dts/rk3399-khadas-edge.dtsi b/arch/arm/dts/rk3399-khadas-edge.dtsi
new file mode 100644
index 0000000..4944d78
--- /dev/null
+++ b/arch/arm/dts/rk3399-khadas-edge.dtsi
@@ -0,0 +1,804 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com)
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.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>;
+ };
+
+ 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 = <&gpio2 RK_PD4 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>;
+ };
+
+ vcc3v3_pcie: vcc3v3-pcie-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_pcie";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vsys_3v3>;
+ };
+
+ /* 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_PD1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_host_en>;
+ regulator-name = "vcc5v0_host";
+ regulator-always-on;
+ vin-supply = <&vsys_5v0>;
+ };
+
+ 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 = <&vsys_3v3>;
+ };
+
+ vsys: vsys {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vsys_3v3: vsys-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vsys>;
+ };
+
+ vsys_5v0: vsys-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_5v0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vsys>;
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1800000>;
+ poll-interval = <100>;
+
+ recovery {
+ label = "Recovery";
+ linux,code = <KEY_VENDOR>;
+ press-threshold-microvolt = <18000>;
+ };
+ };
+
+ 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 = <&sys_led_gpio>, <&user_led_gpio>;
+
+ sys-led {
+ label = "sys_led";
+ linux,default-trigger = "heartbeat";
+ gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led {
+ label = "user_led";
+ default-state = "off";
+ gpios = <&gpio4 RK_PD0 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ cooling-levels = <0 150 200 255>;
+ #cooling-cells = <2>;
+ fan-supply = <&vsys_5v0>;
+ pwms = <&pwm0 0 40000 0>;
+ };
+};
+
+&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>;
+};
+
+&cpu_thermal {
+ trips {
+ cpu_warm: cpu_warm {
+ temperature = <55000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_hot: cpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map2 {
+ trip = <&cpu_warm>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map3 {
+ trip = <&cpu_hot>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+&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>;
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
+&gpu_thermal {
+ trips {
+ gpu_warm: gpu_warm {
+ temperature = <55000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ gpu_hot: gpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map1 {
+ trip = <&gpu_warm>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map2 {
+ trip = <&gpu_hot>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "okay";
+};
+
+&hdmi_sound {
+ 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 = <168>;
+ i2c-scl-falling-time-ns = <4>;
+ status = "okay";
+
+ rk808: pmic at 1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <RK_PC6 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 = <&vsys_3v3>;
+ vcc2-supply = <&vsys_3v3>;
+ vcc3-supply = <&vsys_3v3>;
+ vcc4-supply = <&vsys_3v3>;
+ vcc6-supply = <&vsys_3v3>;
+ vcc7-supply = <&vsys_3v3>;
+ vcc8-supply = <&vsys_3v3>;
+ vcc9-supply = <&vsys_3v3>;
+ vcc10-supply = <&vsys_3v3>;
+ vcc11-supply = <&vsys_3v3>;
+ vcc12-supply = <&vsys_3v3>;
+ 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_apio2: LDO_REG1 {
+ regulator-name = "vcc1v8_apio2";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_vldo2: LDO_REG2 {
+ regulator-name = "vcc_vldo2";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_pmupll: LDO_REG3 {
+ regulator-name = "vcc1v8_pmupll";
+ 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>;
+ };
+ };
+
+ vccio_sd: LDO_REG4 {
+ regulator-name = "vccio_sd";
+ 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>;
+ };
+ };
+
+ vcc_vldo5: LDO_REG5 {
+ regulator-name = "vcc_vldo5";
+ 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>;
+ };
+ };
+
+ vcc1v8_codec: LDO_REG7 {
+ 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;
+ };
+ };
+
+ 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 = <&cpu_b_sleep>;
+ 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 = <&vsys_3v3>;
+
+ 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-name = "vdd_gpu";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vsys_3v3>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&i2c8 {
+ clock-frequency = <400000>;
+ i2c-scl-rising-time-ns = <160>;
+ i2c-scl-falling-time-ns = <30>;
+ 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 {
+ bt656-supply = <&vcc1v8_apio2>;
+ audio-supply = <&vcc1v8_codec>;
+ sdmmc-supply = <&vccio_sd>;
+ gpio1830-supply = <&vcc_3v0>;
+ status = "okay";
+};
+
+&pmu_io_domains {
+ pmu1830-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&pinctrl {
+ bt {
+ 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 {
+ rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_l: bt-wake-l {
+ rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ buttons {
+ pwrbtn: pwrbtn {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ leds {
+ sys_led_gpio: sys_led-gpio {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ user_led_gpio: user_led-gpio {
+ rockchip,pins = <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ cpu_b_sleep: cpu-b-sleep {
+ rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ gpu_sleep: gpu-sleep {
+ rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ sdio-pwrseq {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins = <2 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ usb2 {
+ vcc5v0_host_en: vcc5v0-host-en {
+ rockchip,pins = <4 RK_PD1 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>;
+ };
+ };
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcca1v8_s3>;
+ status = "okay";
+};
+
+&sdio0 {
+ /* WiFi & BT combo module Ampak AP6356S */
+ bus-width = <4>;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
+ sd-uhs-sdr104;
+ vqmmc-supply = <&vcc1v8_s3>;
+ vmmc-supply = <&vccio_sd>;
+ status = "okay";
+
+ brcmf: wifi at 1 {
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;
+ interrupt-names = "host-wake";
+ brcm,drive-strength = <5>;
+ 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>;
+ 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_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 = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
+ max-speed = <4000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_reg_on_h &bt_host_wake_l &bt_wake_l>;
+ vbat-supply = <&vsys_3v3>;
+ vddio-supply = <&vcc_1v8>;
+ };
+};
+
+&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 3308b35..d9711ab 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -6,6 +6,24 @@ F: include/configs/evb_rk3399.h
F: configs/evb-rk3399_defconfig
F: configs/firefly-rk3399_defconfig
+KHADAS-EDGE
+M: Nick Xie <nick@khadas.com>
+S: Maintained
+F: configs/khadas-edge-rk3399_defconfig
+F: arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
+
+KHADAS-EDGE-CAPTAIN
+M: Nick Xie <nick@khadas.com>
+S: Maintained
+F: configs/khadas-edge-captain-rk3399_defconfig
+F: arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
+
+KHADAS-EDGE-V
+M: Nick Xie <nick@khadas.com>
+S: Maintained
+F: configs/khadas-edge-v-rk3399_defconfig
+F: arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
+
NANOPC-T4
M: Jagan Teki <jagan@amarulasolutions.com>
S: Maintained
diff --git a/configs/khadas-edge-captain-rk3399_defconfig b/configs/khadas-edge-captain-rk3399_defconfig
new file mode 100644
index 0000000..306b1b9
--- /dev/null
+++ b/configs/khadas-edge-captain-rk3399_defconfig
@@ -0,0 +1,67 @@
+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=0x50000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-captain.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
+CONFIG_TPL=y
+CONFIG_SYS_PROMPT="kedge# "
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_UUID=y
+CONFIG_CMD_FS_UUID=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-captain"
+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_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_PHY_REALTEK=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_SPL_TINY_MEMSET=y
+CONFIG_ERRNO_STR=y
diff --git a/configs/khadas-edge-rk3399_defconfig b/configs/khadas-edge-rk3399_defconfig
new file mode 100644
index 0000000..0e33911
--- /dev/null
+++ b/configs/khadas-edge-rk3399_defconfig
@@ -0,0 +1,65 @@
+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=0x50000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
+CONFIG_TPL=y
+CONFIG_SYS_PROMPT="kedge# "
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_UUID=y
+CONFIG_CMD_FS_UUID=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge"
+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_SPL_TINY_MEMSET=y
+CONFIG_ERRNO_STR=y
diff --git a/configs/khadas-edge-v-rk3399_defconfig b/configs/khadas-edge-v-rk3399_defconfig
new file mode 100644
index 0000000..59bf5ca
--- /dev/null
+++ b/configs/khadas-edge-v-rk3399_defconfig
@@ -0,0 +1,67 @@
+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=0x50000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-v.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
+CONFIG_TPL=y
+CONFIG_SYS_PROMPT="kedge# "
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_UUID=y
+CONFIG_CMD_FS_UUID=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-v"
+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_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_PHY_REALTEK=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_SPL_TINY_MEMSET=y
+CONFIG_ERRNO_STR=y
--
2.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-17 7:24 ` [U-Boot] " xieqinick at gmail.com
(?)
@ 2019-06-18 7:21 ` Kever Yang
-1 siblings, 0 replies; 43+ messages in thread
From: Kever Yang @ 2019-06-18 7:21 UTC (permalink / raw)
To: u-boot
Hi Nick,
Thanks for your patches, please help to split dts and config into
different patches,
and also one patch for one board instead of 3 boards.
One defconfig for board, while Khadas Captain is the carrier board for
Khadas Edge,
the caption and the Edge should able to share one defconfig in U-Boot?
Thanks,
- Kever
On 06/17/2019 03:24 PM, xieqinick at gmail.com wrote:
> From: Nick Xie <nick@khadas.com>
>
> Add devicetree support for Khadas Edge/Edge-V/Captain boards.
> Khadas Edge is an expandable Rockchip RK3399 board with goldfinger.
> Khadas Captain is the carrier board for Khadas Edge.
> Khadas Edge-V is a Khadas VIM form factor Rockchip RK3399 board.
>
> Specification
> - Rockchip RK3399
> - Dual-Channel 2GB/4GB LPDDR4
> - SD card slot
> - Onboard 16GB/32GB/128GB eMMC
> - RTL8211FD 1Gbps
> - AP6356S/AP6398S WiFI/BT
> - HDMI Out, DP, MIPI DSI/CSI, eDP
> - USB 3.0, 2.0
> - USB Type C power and data
> - GPIO expansion ports
> - Full 4 Lane M.2 Socket
> - 16MB SPI Flash
> - IR
> - Programmable MCU
>
> Commit details of rk3399-khadas-edge-*.dts sync from Mainline Linux Rockchip branch:
> (Linux support already merged to Rockchip branch, will merge to mainline linux in 5.3)
> "arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards"
> (sha1: c2aacceedc86af87428d998e23a1aca24fd8aa2e)
>
> Signed-off-by: Nick Xie <nick@khadas.com>
> ---
> Changes for v2:
> - Sync dts from mainline linux
> - Add TPL support
> - Update defconfig file
> - Drop http from commit message
>
>
> arch/arm/dts/Makefile | 3 +
> .../arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi | 7 +
> arch/arm/dts/rk3399-khadas-edge-captain.dts | 27 +
> arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi | 7 +
> arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi | 7 +
> arch/arm/dts/rk3399-khadas-edge-v.dts | 27 +
> arch/arm/dts/rk3399-khadas-edge.dts | 13 +
> arch/arm/dts/rk3399-khadas-edge.dtsi | 804 +++++++++++++++++++++
> board/rockchip/evb_rk3399/MAINTAINERS | 18 +
> configs/khadas-edge-captain-rk3399_defconfig | 67 ++
> configs/khadas-edge-rk3399_defconfig | 65 ++
> configs/khadas-edge-v-rk3399_defconfig | 67 ++
> 12 files changed, 1112 insertions(+)
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-captain.dts
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-v.dts
> create mode 100644 arch/arm/dts/rk3399-khadas-edge.dts
> create mode 100644 arch/arm/dts/rk3399-khadas-edge.dtsi
> create mode 100644 configs/khadas-edge-captain-rk3399_defconfig
> create mode 100644 configs/khadas-edge-rk3399_defconfig
> create mode 100644 configs/khadas-edge-v-rk3399_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 528fb90..824844a 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -106,6 +106,9 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> rk3399-ficus.dtb \
> rk3399-firefly.dtb \
> rk3399-gru-bob.dtb \
> + rk3399-khadas-edge.dtb \
> + rk3399-khadas-edge-captain.dtb \
> + rk3399-khadas-edge-v.dtb \
> rk3399-nanopc-t4.dtb \
> rk3399-nanopi-m4.dtb \
> rk3399-nanopi-neo4.dtb \
> diff --git a/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
> new file mode 100644
> index 0000000..569d01e
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +#include "rk3399-khadas-edge-u-boot.dtsi"
> diff --git a/arch/arm/dts/rk3399-khadas-edge-captain.dts b/arch/arm/dts/rk3399-khadas-edge-captain.dts
> new file mode 100644
> index 0000000..8302e51
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-captain.dts
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +/dts-v1/;
> +#include "rk3399-khadas-edge.dtsi"
> +
> +/ {
> + model = "Khadas Edge-Captain";
> + compatible = "khadas,edge-captain", "rockchip,rk3399";
> +};
> +
> +&gmac {
> + status = "okay";
> +};
> +
> +&pcie_phy {
> + status = "okay";
> +};
> +
> +&pcie0 {
> + ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
> + num-lanes = <4>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
> new file mode 100644
> index 0000000..b4d80c3
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> diff --git a/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
> new file mode 100644
> index 0000000..569d01e
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +#include "rk3399-khadas-edge-u-boot.dtsi"
> diff --git a/arch/arm/dts/rk3399-khadas-edge-v.dts b/arch/arm/dts/rk3399-khadas-edge-v.dts
> new file mode 100644
> index 0000000..f5dcb99
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-v.dts
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +/dts-v1/;
> +#include "rk3399-khadas-edge.dtsi"
> +
> +/ {
> + model = "Khadas Edge-V";
> + compatible = "khadas,edge-v", "rockchip,rk3399";
> +};
> +
> +&gmac {
> + status = "okay";
> +};
> +
> +&pcie_phy {
> + status = "okay";
> +};
> +
> +&pcie0 {
> + ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
> + num-lanes = <4>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/rk3399-khadas-edge.dts b/arch/arm/dts/rk3399-khadas-edge.dts
> new file mode 100644
> index 0000000..31616e7
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge.dts
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +/dts-v1/;
> +#include "rk3399-khadas-edge.dtsi"
> +
> +/ {
> + model = "Khadas Edge";
> + compatible = "khadas,edge", "rockchip,rk3399";
> +};
> diff --git a/arch/arm/dts/rk3399-khadas-edge.dtsi b/arch/arm/dts/rk3399-khadas-edge.dtsi
> new file mode 100644
> index 0000000..4944d78
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge.dtsi
> @@ -0,0 +1,804 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include <dt-bindings/pwm/pwm.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>;
> + };
> +
> + 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 = <&gpio2 RK_PD4 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>;
> + };
> +
> + vcc3v3_pcie: vcc3v3-pcie-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_pcie";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vsys_3v3>;
> + };
> +
> + /* 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_PD1 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc5v0_host_en>;
> + regulator-name = "vcc5v0_host";
> + regulator-always-on;
> + vin-supply = <&vsys_5v0>;
> + };
> +
> + 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 = <&vsys_3v3>;
> + };
> +
> + vsys: vsys {
> + compatible = "regulator-fixed";
> + regulator-name = "vsys";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vsys_3v3: vsys-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vsys_3v3";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vsys>;
> + };
> +
> + vsys_5v0: vsys-5v0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vsys_5v0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vsys>;
> + };
> +
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = <&saradc 1>;
> + io-channel-names = "buttons";
> + keyup-threshold-microvolt = <1800000>;
> + poll-interval = <100>;
> +
> + recovery {
> + label = "Recovery";
> + linux,code = <KEY_VENDOR>;
> + press-threshold-microvolt = <18000>;
> + };
> + };
> +
> + 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 = <&sys_led_gpio>, <&user_led_gpio>;
> +
> + sys-led {
> + label = "sys_led";
> + linux,default-trigger = "heartbeat";
> + gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
> + };
> +
> + user-led {
> + label = "user_led";
> + default-state = "off";
> + gpios = <&gpio4 RK_PD0 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + fan: pwm-fan {
> + compatible = "pwm-fan";
> + cooling-levels = <0 150 200 255>;
> + #cooling-cells = <2>;
> + fan-supply = <&vsys_5v0>;
> + pwms = <&pwm0 0 40000 0>;
> + };
> +};
> +
> +&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>;
> +};
> +
> +&cpu_thermal {
> + trips {
> + cpu_warm: cpu_warm {
> + temperature = <55000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> +
> + cpu_hot: cpu_hot {
> + temperature = <65000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map2 {
> + trip = <&cpu_warm>;
> + cooling-device = <&fan THERMAL_NO_LIMIT 1>;
> + };
> +
> + map3 {
> + trip = <&cpu_hot>;
> + cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> +&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>;
> +};
> +
> +&gpu {
> + mali-supply = <&vdd_gpu>;
> + status = "okay";
> +};
> +
> +&gpu_thermal {
> + trips {
> + gpu_warm: gpu_warm {
> + temperature = <55000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> +
> + gpu_hot: gpu_hot {
> + temperature = <65000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map1 {
> + trip = <&gpu_warm>;
> + cooling-device = <&fan THERMAL_NO_LIMIT 1>;
> + };
> +
> + map2 {
> + trip = <&gpu_hot>;
> + cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> +&hdmi {
> + ddc-i2c-bus = <&i2c3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&hdmi_cec>;
> + status = "okay";
> +};
> +
> +&hdmi_sound {
> + 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 = <168>;
> + i2c-scl-falling-time-ns = <4>;
> + status = "okay";
> +
> + rk808: pmic at 1b {
> + compatible = "rockchip,rk808";
> + reg = <0x1b>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <RK_PC6 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 = <&vsys_3v3>;
> + vcc2-supply = <&vsys_3v3>;
> + vcc3-supply = <&vsys_3v3>;
> + vcc4-supply = <&vsys_3v3>;
> + vcc6-supply = <&vsys_3v3>;
> + vcc7-supply = <&vsys_3v3>;
> + vcc8-supply = <&vsys_3v3>;
> + vcc9-supply = <&vsys_3v3>;
> + vcc10-supply = <&vsys_3v3>;
> + vcc11-supply = <&vsys_3v3>;
> + vcc12-supply = <&vsys_3v3>;
> + 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_apio2: LDO_REG1 {
> + regulator-name = "vcc1v8_apio2";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_vldo2: LDO_REG2 {
> + regulator-name = "vcc_vldo2";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc1v8_pmupll: LDO_REG3 {
> + regulator-name = "vcc1v8_pmupll";
> + 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>;
> + };
> + };
> +
> + vccio_sd: LDO_REG4 {
> + regulator-name = "vccio_sd";
> + 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>;
> + };
> + };
> +
> + vcc_vldo5: LDO_REG5 {
> + regulator-name = "vcc_vldo5";
> + 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>;
> + };
> + };
> +
> + vcc1v8_codec: LDO_REG7 {
> + 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;
> + };
> + };
> +
> + 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 = <&cpu_b_sleep>;
> + 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 = <&vsys_3v3>;
> +
> + 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-name = "vdd_gpu";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1500000>;
> + regulator-ramp-delay = <1000>;
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <&vsys_3v3>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +};
> +
> +&i2c8 {
> + clock-frequency = <400000>;
> + i2c-scl-rising-time-ns = <160>;
> + i2c-scl-falling-time-ns = <30>;
> + 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 {
> + bt656-supply = <&vcc1v8_apio2>;
> + audio-supply = <&vcc1v8_codec>;
> + sdmmc-supply = <&vccio_sd>;
> + gpio1830-supply = <&vcc_3v0>;
> + status = "okay";
> +};
> +
> +&pmu_io_domains {
> + pmu1830-supply = <&vcc_1v8>;
> + status = "okay";
> +};
> +
> +&pinctrl {
> + bt {
> + 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 {
> + rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + bt_wake_l: bt-wake-l {
> + rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + buttons {
> + pwrbtn: pwrbtn {
> + rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + leds {
> + sys_led_gpio: sys_led-gpio {
> + rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + user_led_gpio: user_led-gpio {
> + rockchip,pins = <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + pmic_int_l: pmic-int-l {
> + rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> +
> + cpu_b_sleep: cpu-b-sleep {
> + rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> +
> + gpu_sleep: gpu-sleep {
> + rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> + };
> +
> + sdio-pwrseq {
> + wifi_enable_h: wifi-enable-h {
> + rockchip,pins = <2 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + usb2 {
> + vcc5v0_host_en: vcc5v0-host-en {
> + rockchip,pins = <4 RK_PD1 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>;
> + };
> + };
> +};
> +
> +&pwm0 {
> + status = "okay";
> +};
> +
> +&pwm2 {
> + status = "okay";
> +};
> +
> +&saradc {
> + vref-supply = <&vcca1v8_s3>;
> + status = "okay";
> +};
> +
> +&sdio0 {
> + /* WiFi & BT combo module Ampak AP6356S */
> + bus-width = <4>;
> + cap-sdio-irq;
> + cap-sd-highspeed;
> + keep-power-in-suspend;
> + mmc-pwrseq = <&sdio_pwrseq>;
> + non-removable;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
> + sd-uhs-sdr104;
> + vqmmc-supply = <&vcc1v8_s3>;
> + vmmc-supply = <&vccio_sd>;
> + status = "okay";
> +
> + brcmf: wifi at 1 {
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <&gpio0>;
> + interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;
> + interrupt-names = "host-wake";
> + brcm,drive-strength = <5>;
> + 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>;
> + 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_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 = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
> + max-speed = <4000000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&bt_reg_on_h &bt_host_wake_l &bt_wake_l>;
> + vbat-supply = <&vsys_3v3>;
> + vddio-supply = <&vcc_1v8>;
> + };
> +};
> +
> +&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 3308b35..d9711ab 100644
> --- a/board/rockchip/evb_rk3399/MAINTAINERS
> +++ b/board/rockchip/evb_rk3399/MAINTAINERS
> @@ -6,6 +6,24 @@ F: include/configs/evb_rk3399.h
> F: configs/evb-rk3399_defconfig
> F: configs/firefly-rk3399_defconfig
>
> +KHADAS-EDGE
> +M: Nick Xie <nick@khadas.com>
> +S: Maintained
> +F: configs/khadas-edge-rk3399_defconfig
> +F: arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
> +
> +KHADAS-EDGE-CAPTAIN
> +M: Nick Xie <nick@khadas.com>
> +S: Maintained
> +F: configs/khadas-edge-captain-rk3399_defconfig
> +F: arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
> +
> +KHADAS-EDGE-V
> +M: Nick Xie <nick@khadas.com>
> +S: Maintained
> +F: configs/khadas-edge-v-rk3399_defconfig
> +F: arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
> +
> NANOPC-T4
> M: Jagan Teki <jagan@amarulasolutions.com>
> S: Maintained
> diff --git a/configs/khadas-edge-captain-rk3399_defconfig b/configs/khadas-edge-captain-rk3399_defconfig
> new file mode 100644
> index 0000000..306b1b9
> --- /dev/null
> +++ b/configs/khadas-edge-captain-rk3399_defconfig
> @@ -0,0 +1,67 @@
> +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=0x50000
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL_STACK_R_ADDR=0x80000
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-captain.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
> +CONFIG_TPL=y
> +CONFIG_SYS_PROMPT="kedge# "
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_UUID=y
> +CONFIG_CMD_FS_UUID=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-captain"
> +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_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_PHY_REALTEK=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_SPL_TINY_MEMSET=y
> +CONFIG_ERRNO_STR=y
> diff --git a/configs/khadas-edge-rk3399_defconfig b/configs/khadas-edge-rk3399_defconfig
> new file mode 100644
> index 0000000..0e33911
> --- /dev/null
> +++ b/configs/khadas-edge-rk3399_defconfig
> @@ -0,0 +1,65 @@
> +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=0x50000
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL_STACK_R_ADDR=0x80000
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
> +CONFIG_TPL=y
> +CONFIG_SYS_PROMPT="kedge# "
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_UUID=y
> +CONFIG_CMD_FS_UUID=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge"
> +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_SPL_TINY_MEMSET=y
> +CONFIG_ERRNO_STR=y
> diff --git a/configs/khadas-edge-v-rk3399_defconfig b/configs/khadas-edge-v-rk3399_defconfig
> new file mode 100644
> index 0000000..59bf5ca
> --- /dev/null
> +++ b/configs/khadas-edge-v-rk3399_defconfig
> @@ -0,0 +1,67 @@
> +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=0x50000
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL_STACK_R_ADDR=0x80000
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-v.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
> +CONFIG_TPL=y
> +CONFIG_SYS_PROMPT="kedge# "
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_UUID=y
> +CONFIG_CMD_FS_UUID=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-v"
> +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_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_PHY_REALTEK=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_SPL_TINY_MEMSET=y
> +CONFIG_ERRNO_STR=y
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-17 8:56 ` xieqinick at gmail.com
@ 2019-06-18 7:21 ` Jagan Teki
0 siblings, 0 replies; 43+ messages in thread
From: Jagan Teki @ 2019-06-18 7:21 UTC (permalink / raw)
To: u-boot
On Mon, Jun 17, 2019 at 2:27 PM <xieqinick@gmail.com> wrote:
>
> From: Nick Xie <nick@khadas.com>
>
> Add devicetree support for Khadas Edge/Edge-V/Captain boards.
> Khadas Edge is an expandable Rockchip RK3399 board with goldfinger.
> Khadas Captain is the carrier board for Khadas Edge.
> Khadas Edge-V is a Khadas VIM form factor Rockchip RK3399 board.
>
> Specification
> - Rockchip RK3399
> - Dual-Channel 2GB/4GB LPDDR4
> - SD card slot
> - Onboard 16GB/32GB/128GB eMMC
> - RTL8211FD 1Gbps
> - AP6356S/AP6398S WiFI/BT
> - HDMI Out, DP, MIPI DSI/CSI, eDP
> - USB 3.0, 2.0
> - USB Type C power and data
> - GPIO expansion ports
> - Full 4 Lane M.2 Socket
> - 16MB SPI Flash
> - IR
> - Programmable MCU
>
> Commit details of rk3399-khadas-edge-*.dts sync from Mainline Linux Rockchip branch:
> (Linux support already merged to Rockchip branch, will merge to mainline linux in 5.3)
> "arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards"
> (sha1: c2aacceedc86af87428d998e23a1aca24fd8aa2e)
>
> Signed-off-by: Nick Xie <nick@khadas.com>
> ---
> Changes for v2:
> - Sync dts from mainline linux
> - Add TPL support
> - Update defconfig file
> - Drop http from commit message
00. Break this into multiple patches, since it is an initial support
patch, patch per board make more sense to review and support.
01. Rebase on top of LPDDR4 [1] series and use timings from dtsi
[1] https://patchwork.ozlabs.org/cover/1116734/
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-17 7:24 ` [U-Boot] " xieqinick at gmail.com
@ 2019-06-18 8:25 ` Paul Kocialkowski
-1 siblings, 0 replies; 43+ messages in thread
From: Paul Kocialkowski @ 2019-06-18 8:25 UTC (permalink / raw)
To: xieqinick-Re5JQEeQqe8AvxtiuMwx3w,
kever.yang-TNX95d0MmH7DzftRWevZcw,
jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
sjg-F7+t8E8rja9g9hUCZPvPmw,
philipp.tomsich-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nick-XW3xCAIBE2TQT0dZR+AlfA,
linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
u-boot-0aAXYlwwYIKGBzrmiIFOJg
Hi,
On Mon, 2019-06-17 at 15:24 +0800, xieqinick-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> From: Nick Xie <nick-XW3xCAIBE2TQT0dZR+AlfA@public.gmane.org>
Was this tested with SPL support? I don't see DRAM configuration here
so it seems that it relies on the non-free rockchip loader.
If that is the case, could you please indicate that in the commit
message?
To maintainers: please do not merge this series before DRAM init and
SPL support is available for these boards.
It seems that other RK3399 boards were merged without SPL support and
sofar, I have the feeling that nobody cared to explain how we got into
this broken situation. Please don't merge any more such board.
Cheers,
Paul
> Add devicetree support for Khadas Edge/Edge-V/Captain boards.
> Khadas Edge is an expandable Rockchip RK3399 board with goldfinger.
> Khadas Captain is the carrier board for Khadas Edge.
> Khadas Edge-V is a Khadas VIM form factor Rockchip RK3399 board.
>
> Specification
> - Rockchip RK3399
> - Dual-Channel 2GB/4GB LPDDR4
> - SD card slot
> - Onboard 16GB/32GB/128GB eMMC
> - RTL8211FD 1Gbps
> - AP6356S/AP6398S WiFI/BT
> - HDMI Out, DP, MIPI DSI/CSI, eDP
> - USB 3.0, 2.0
> - USB Type C power and data
> - GPIO expansion ports
> - Full 4 Lane M.2 Socket
> - 16MB SPI Flash
> - IR
> - Programmable MCU
>
> Commit details of rk3399-khadas-edge-*.dts sync from Mainline Linux Rockchip branch:
> (Linux support already merged to Rockchip branch, will merge to mainline linux in 5.3)
> "arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards"
> (sha1: c2aacceedc86af87428d998e23a1aca24fd8aa2e)
>
> Signed-off-by: Nick Xie <nick-XW3xCAIBE2TQT0dZR+AlfA@public.gmane.org>
> ---
> Changes for v2:
> - Sync dts from mainline linux
> - Add TPL support
> - Update defconfig file
> - Drop http from commit message
>
>
> arch/arm/dts/Makefile | 3 +
> .../arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi | 7 +
> arch/arm/dts/rk3399-khadas-edge-captain.dts | 27 +
> arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi | 7 +
> arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi | 7 +
> arch/arm/dts/rk3399-khadas-edge-v.dts | 27 +
> arch/arm/dts/rk3399-khadas-edge.dts | 13 +
> arch/arm/dts/rk3399-khadas-edge.dtsi | 804 +++++++++++++++++++++
> board/rockchip/evb_rk3399/MAINTAINERS | 18 +
> configs/khadas-edge-captain-rk3399_defconfig | 67 ++
> configs/khadas-edge-rk3399_defconfig | 65 ++
> configs/khadas-edge-v-rk3399_defconfig | 67 ++
> 12 files changed, 1112 insertions(+)
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-captain.dts
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-v.dts
> create mode 100644 arch/arm/dts/rk3399-khadas-edge.dts
> create mode 100644 arch/arm/dts/rk3399-khadas-edge.dtsi
> create mode 100644 configs/khadas-edge-captain-rk3399_defconfig
> create mode 100644 configs/khadas-edge-rk3399_defconfig
> create mode 100644 configs/khadas-edge-v-rk3399_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 528fb90..824844a 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -106,6 +106,9 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> rk3399-ficus.dtb \
> rk3399-firefly.dtb \
> rk3399-gru-bob.dtb \
> + rk3399-khadas-edge.dtb \
> + rk3399-khadas-edge-captain.dtb \
> + rk3399-khadas-edge-v.dtb \
> rk3399-nanopc-t4.dtb \
> rk3399-nanopi-m4.dtb \
> rk3399-nanopi-neo4.dtb \
> diff --git a/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
> new file mode 100644
> index 0000000..569d01e
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +#include "rk3399-khadas-edge-u-boot.dtsi"
> diff --git a/arch/arm/dts/rk3399-khadas-edge-captain.dts b/arch/arm/dts/rk3399-khadas-edge-captain.dts
> new file mode 100644
> index 0000000..8302e51
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-captain.dts
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +/dts-v1/;
> +#include "rk3399-khadas-edge.dtsi"
> +
> +/ {
> + model = "Khadas Edge-Captain";
> + compatible = "khadas,edge-captain", "rockchip,rk3399";
> +};
> +
> +&gmac {
> + status = "okay";
> +};
> +
> +&pcie_phy {
> + status = "okay";
> +};
> +
> +&pcie0 {
> + ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
> + num-lanes = <4>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
> new file mode 100644
> index 0000000..b4d80c3
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> diff --git a/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
> new file mode 100644
> index 0000000..569d01e
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +#include "rk3399-khadas-edge-u-boot.dtsi"
> diff --git a/arch/arm/dts/rk3399-khadas-edge-v.dts b/arch/arm/dts/rk3399-khadas-edge-v.dts
> new file mode 100644
> index 0000000..f5dcb99
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-v.dts
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +/dts-v1/;
> +#include "rk3399-khadas-edge.dtsi"
> +
> +/ {
> + model = "Khadas Edge-V";
> + compatible = "khadas,edge-v", "rockchip,rk3399";
> +};
> +
> +&gmac {
> + status = "okay";
> +};
> +
> +&pcie_phy {
> + status = "okay";
> +};
> +
> +&pcie0 {
> + ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
> + num-lanes = <4>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/rk3399-khadas-edge.dts b/arch/arm/dts/rk3399-khadas-edge.dts
> new file mode 100644
> index 0000000..31616e7
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge.dts
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +/dts-v1/;
> +#include "rk3399-khadas-edge.dtsi"
> +
> +/ {
> + model = "Khadas Edge";
> + compatible = "khadas,edge", "rockchip,rk3399";
> +};
> diff --git a/arch/arm/dts/rk3399-khadas-edge.dtsi b/arch/arm/dts/rk3399-khadas-edge.dtsi
> new file mode 100644
> index 0000000..4944d78
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge.dtsi
> @@ -0,0 +1,804 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include <dt-bindings/pwm/pwm.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>;
> + };
> +
> + 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 = <&gpio2 RK_PD4 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>;
> + };
> +
> + vcc3v3_pcie: vcc3v3-pcie-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_pcie";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vsys_3v3>;
> + };
> +
> + /* 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_PD1 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc5v0_host_en>;
> + regulator-name = "vcc5v0_host";
> + regulator-always-on;
> + vin-supply = <&vsys_5v0>;
> + };
> +
> + 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 = <&vsys_3v3>;
> + };
> +
> + vsys: vsys {
> + compatible = "regulator-fixed";
> + regulator-name = "vsys";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vsys_3v3: vsys-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vsys_3v3";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vsys>;
> + };
> +
> + vsys_5v0: vsys-5v0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vsys_5v0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vsys>;
> + };
> +
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = <&saradc 1>;
> + io-channel-names = "buttons";
> + keyup-threshold-microvolt = <1800000>;
> + poll-interval = <100>;
> +
> + recovery {
> + label = "Recovery";
> + linux,code = <KEY_VENDOR>;
> + press-threshold-microvolt = <18000>;
> + };
> + };
> +
> + 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 = <&sys_led_gpio>, <&user_led_gpio>;
> +
> + sys-led {
> + label = "sys_led";
> + linux,default-trigger = "heartbeat";
> + gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
> + };
> +
> + user-led {
> + label = "user_led";
> + default-state = "off";
> + gpios = <&gpio4 RK_PD0 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + fan: pwm-fan {
> + compatible = "pwm-fan";
> + cooling-levels = <0 150 200 255>;
> + #cooling-cells = <2>;
> + fan-supply = <&vsys_5v0>;
> + pwms = <&pwm0 0 40000 0>;
> + };
> +};
> +
> +&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>;
> +};
> +
> +&cpu_thermal {
> + trips {
> + cpu_warm: cpu_warm {
> + temperature = <55000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> +
> + cpu_hot: cpu_hot {
> + temperature = <65000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map2 {
> + trip = <&cpu_warm>;
> + cooling-device = <&fan THERMAL_NO_LIMIT 1>;
> + };
> +
> + map3 {
> + trip = <&cpu_hot>;
> + cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> +&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>;
> +};
> +
> +&gpu {
> + mali-supply = <&vdd_gpu>;
> + status = "okay";
> +};
> +
> +&gpu_thermal {
> + trips {
> + gpu_warm: gpu_warm {
> + temperature = <55000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> +
> + gpu_hot: gpu_hot {
> + temperature = <65000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map1 {
> + trip = <&gpu_warm>;
> + cooling-device = <&fan THERMAL_NO_LIMIT 1>;
> + };
> +
> + map2 {
> + trip = <&gpu_hot>;
> + cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> +&hdmi {
> + ddc-i2c-bus = <&i2c3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&hdmi_cec>;
> + status = "okay";
> +};
> +
> +&hdmi_sound {
> + 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 = <168>;
> + i2c-scl-falling-time-ns = <4>;
> + status = "okay";
> +
> + rk808: pmic@1b {
> + compatible = "rockchip,rk808";
> + reg = <0x1b>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <RK_PC6 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 = <&vsys_3v3>;
> + vcc2-supply = <&vsys_3v3>;
> + vcc3-supply = <&vsys_3v3>;
> + vcc4-supply = <&vsys_3v3>;
> + vcc6-supply = <&vsys_3v3>;
> + vcc7-supply = <&vsys_3v3>;
> + vcc8-supply = <&vsys_3v3>;
> + vcc9-supply = <&vsys_3v3>;
> + vcc10-supply = <&vsys_3v3>;
> + vcc11-supply = <&vsys_3v3>;
> + vcc12-supply = <&vsys_3v3>;
> + 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_apio2: LDO_REG1 {
> + regulator-name = "vcc1v8_apio2";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_vldo2: LDO_REG2 {
> + regulator-name = "vcc_vldo2";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc1v8_pmupll: LDO_REG3 {
> + regulator-name = "vcc1v8_pmupll";
> + 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>;
> + };
> + };
> +
> + vccio_sd: LDO_REG4 {
> + regulator-name = "vccio_sd";
> + 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>;
> + };
> + };
> +
> + vcc_vldo5: LDO_REG5 {
> + regulator-name = "vcc_vldo5";
> + 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>;
> + };
> + };
> +
> + vcc1v8_codec: LDO_REG7 {
> + 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;
> + };
> + };
> +
> + 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 = <&cpu_b_sleep>;
> + 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 = <&vsys_3v3>;
> +
> + 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-name = "vdd_gpu";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1500000>;
> + regulator-ramp-delay = <1000>;
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <&vsys_3v3>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +};
> +
> +&i2c8 {
> + clock-frequency = <400000>;
> + i2c-scl-rising-time-ns = <160>;
> + i2c-scl-falling-time-ns = <30>;
> + 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 {
> + bt656-supply = <&vcc1v8_apio2>;
> + audio-supply = <&vcc1v8_codec>;
> + sdmmc-supply = <&vccio_sd>;
> + gpio1830-supply = <&vcc_3v0>;
> + status = "okay";
> +};
> +
> +&pmu_io_domains {
> + pmu1830-supply = <&vcc_1v8>;
> + status = "okay";
> +};
> +
> +&pinctrl {
> + bt {
> + 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 {
> + rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + bt_wake_l: bt-wake-l {
> + rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + buttons {
> + pwrbtn: pwrbtn {
> + rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + leds {
> + sys_led_gpio: sys_led-gpio {
> + rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + user_led_gpio: user_led-gpio {
> + rockchip,pins = <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + pmic_int_l: pmic-int-l {
> + rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> +
> + cpu_b_sleep: cpu-b-sleep {
> + rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> +
> + gpu_sleep: gpu-sleep {
> + rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> + };
> +
> + sdio-pwrseq {
> + wifi_enable_h: wifi-enable-h {
> + rockchip,pins = <2 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + usb2 {
> + vcc5v0_host_en: vcc5v0-host-en {
> + rockchip,pins = <4 RK_PD1 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>;
> + };
> + };
> +};
> +
> +&pwm0 {
> + status = "okay";
> +};
> +
> +&pwm2 {
> + status = "okay";
> +};
> +
> +&saradc {
> + vref-supply = <&vcca1v8_s3>;
> + status = "okay";
> +};
> +
> +&sdio0 {
> + /* WiFi & BT combo module Ampak AP6356S */
> + bus-width = <4>;
> + cap-sdio-irq;
> + cap-sd-highspeed;
> + keep-power-in-suspend;
> + mmc-pwrseq = <&sdio_pwrseq>;
> + non-removable;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
> + sd-uhs-sdr104;
> + vqmmc-supply = <&vcc1v8_s3>;
> + vmmc-supply = <&vccio_sd>;
> + status = "okay";
> +
> + brcmf: wifi@1 {
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <&gpio0>;
> + interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;
> + interrupt-names = "host-wake";
> + brcm,drive-strength = <5>;
> + 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>;
> + 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_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 = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
> + max-speed = <4000000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&bt_reg_on_h &bt_host_wake_l &bt_wake_l>;
> + vbat-supply = <&vsys_3v3>;
> + vddio-supply = <&vcc_1v8>;
> + };
> +};
> +
> +&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 3308b35..d9711ab 100644
> --- a/board/rockchip/evb_rk3399/MAINTAINERS
> +++ b/board/rockchip/evb_rk3399/MAINTAINERS
> @@ -6,6 +6,24 @@ F: include/configs/evb_rk3399.h
> F: configs/evb-rk3399_defconfig
> F: configs/firefly-rk3399_defconfig
>
> +KHADAS-EDGE
> +M: Nick Xie <nick-XW3xCAIBE2TQT0dZR+AlfA@public.gmane.org>
> +S: Maintained
> +F: configs/khadas-edge-rk3399_defconfig
> +F: arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
> +
> +KHADAS-EDGE-CAPTAIN
> +M: Nick Xie <nick-XW3xCAIBE2TQT0dZR+AlfA@public.gmane.org>
> +S: Maintained
> +F: configs/khadas-edge-captain-rk3399_defconfig
> +F: arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
> +
> +KHADAS-EDGE-V
> +M: Nick Xie <nick-XW3xCAIBE2TQT0dZR+AlfA@public.gmane.org>
> +S: Maintained
> +F: configs/khadas-edge-v-rk3399_defconfig
> +F: arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
> +
> NANOPC-T4
> M: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> S: Maintained
> diff --git a/configs/khadas-edge-captain-rk3399_defconfig b/configs/khadas-edge-captain-rk3399_defconfig
> new file mode 100644
> index 0000000..306b1b9
> --- /dev/null
> +++ b/configs/khadas-edge-captain-rk3399_defconfig
> @@ -0,0 +1,67 @@
> +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=0x50000
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL_STACK_R_ADDR=0x80000
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-captain.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
> +CONFIG_TPL=y
> +CONFIG_SYS_PROMPT="kedge# "
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_UUID=y
> +CONFIG_CMD_FS_UUID=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-captain"
> +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_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_PHY_REALTEK=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_SPL_TINY_MEMSET=y
> +CONFIG_ERRNO_STR=y
> diff --git a/configs/khadas-edge-rk3399_defconfig b/configs/khadas-edge-rk3399_defconfig
> new file mode 100644
> index 0000000..0e33911
> --- /dev/null
> +++ b/configs/khadas-edge-rk3399_defconfig
> @@ -0,0 +1,65 @@
> +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=0x50000
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL_STACK_R_ADDR=0x80000
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
> +CONFIG_TPL=y
> +CONFIG_SYS_PROMPT="kedge# "
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_UUID=y
> +CONFIG_CMD_FS_UUID=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge"
> +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_SPL_TINY_MEMSET=y
> +CONFIG_ERRNO_STR=y
> diff --git a/configs/khadas-edge-v-rk3399_defconfig b/configs/khadas-edge-v-rk3399_defconfig
> new file mode 100644
> index 0000000..59bf5ca
> --- /dev/null
> +++ b/configs/khadas-edge-v-rk3399_defconfig
> @@ -0,0 +1,67 @@
> +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=0x50000
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL_STACK_R_ADDR=0x80000
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-v.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
> +CONFIG_TPL=y
> +CONFIG_SYS_PROMPT="kedge# "
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_UUID=y
> +CONFIG_CMD_FS_UUID=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-v"
> +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_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_PHY_REALTEK=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_SPL_TINY_MEMSET=y
> +CONFIG_ERRNO_STR=y
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-18 8:25 ` Paul Kocialkowski
0 siblings, 0 replies; 43+ messages in thread
From: Paul Kocialkowski @ 2019-06-18 8:25 UTC (permalink / raw)
To: u-boot
Hi,
On Mon, 2019-06-17 at 15:24 +0800, xieqinick at gmail.com wrote:
> From: Nick Xie <nick@khadas.com>
Was this tested with SPL support? I don't see DRAM configuration here
so it seems that it relies on the non-free rockchip loader.
If that is the case, could you please indicate that in the commit
message?
To maintainers: please do not merge this series before DRAM init and
SPL support is available for these boards.
It seems that other RK3399 boards were merged without SPL support and
sofar, I have the feeling that nobody cared to explain how we got into
this broken situation. Please don't merge any more such board.
Cheers,
Paul
> Add devicetree support for Khadas Edge/Edge-V/Captain boards.
> Khadas Edge is an expandable Rockchip RK3399 board with goldfinger.
> Khadas Captain is the carrier board for Khadas Edge.
> Khadas Edge-V is a Khadas VIM form factor Rockchip RK3399 board.
>
> Specification
> - Rockchip RK3399
> - Dual-Channel 2GB/4GB LPDDR4
> - SD card slot
> - Onboard 16GB/32GB/128GB eMMC
> - RTL8211FD 1Gbps
> - AP6356S/AP6398S WiFI/BT
> - HDMI Out, DP, MIPI DSI/CSI, eDP
> - USB 3.0, 2.0
> - USB Type C power and data
> - GPIO expansion ports
> - Full 4 Lane M.2 Socket
> - 16MB SPI Flash
> - IR
> - Programmable MCU
>
> Commit details of rk3399-khadas-edge-*.dts sync from Mainline Linux Rockchip branch:
> (Linux support already merged to Rockchip branch, will merge to mainline linux in 5.3)
> "arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards"
> (sha1: c2aacceedc86af87428d998e23a1aca24fd8aa2e)
>
> Signed-off-by: Nick Xie <nick@khadas.com>
> ---
> Changes for v2:
> - Sync dts from mainline linux
> - Add TPL support
> - Update defconfig file
> - Drop http from commit message
>
>
> arch/arm/dts/Makefile | 3 +
> .../arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi | 7 +
> arch/arm/dts/rk3399-khadas-edge-captain.dts | 27 +
> arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi | 7 +
> arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi | 7 +
> arch/arm/dts/rk3399-khadas-edge-v.dts | 27 +
> arch/arm/dts/rk3399-khadas-edge.dts | 13 +
> arch/arm/dts/rk3399-khadas-edge.dtsi | 804 +++++++++++++++++++++
> board/rockchip/evb_rk3399/MAINTAINERS | 18 +
> configs/khadas-edge-captain-rk3399_defconfig | 67 ++
> configs/khadas-edge-rk3399_defconfig | 65 ++
> configs/khadas-edge-v-rk3399_defconfig | 67 ++
> 12 files changed, 1112 insertions(+)
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-captain.dts
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
> create mode 100644 arch/arm/dts/rk3399-khadas-edge-v.dts
> create mode 100644 arch/arm/dts/rk3399-khadas-edge.dts
> create mode 100644 arch/arm/dts/rk3399-khadas-edge.dtsi
> create mode 100644 configs/khadas-edge-captain-rk3399_defconfig
> create mode 100644 configs/khadas-edge-rk3399_defconfig
> create mode 100644 configs/khadas-edge-v-rk3399_defconfig
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 528fb90..824844a 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -106,6 +106,9 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> rk3399-ficus.dtb \
> rk3399-firefly.dtb \
> rk3399-gru-bob.dtb \
> + rk3399-khadas-edge.dtb \
> + rk3399-khadas-edge-captain.dtb \
> + rk3399-khadas-edge-v.dtb \
> rk3399-nanopc-t4.dtb \
> rk3399-nanopi-m4.dtb \
> rk3399-nanopi-neo4.dtb \
> diff --git a/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
> new file mode 100644
> index 0000000..569d01e
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +#include "rk3399-khadas-edge-u-boot.dtsi"
> diff --git a/arch/arm/dts/rk3399-khadas-edge-captain.dts b/arch/arm/dts/rk3399-khadas-edge-captain.dts
> new file mode 100644
> index 0000000..8302e51
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-captain.dts
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +/dts-v1/;
> +#include "rk3399-khadas-edge.dtsi"
> +
> +/ {
> + model = "Khadas Edge-Captain";
> + compatible = "khadas,edge-captain", "rockchip,rk3399";
> +};
> +
> +&gmac {
> + status = "okay";
> +};
> +
> +&pcie_phy {
> + status = "okay";
> +};
> +
> +&pcie0 {
> + ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
> + num-lanes = <4>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
> new file mode 100644
> index 0000000..b4d80c3
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +#include "rk3399-u-boot.dtsi"
> diff --git a/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi b/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
> new file mode 100644
> index 0000000..569d01e
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
> @@ -0,0 +1,7 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +#include "rk3399-khadas-edge-u-boot.dtsi"
> diff --git a/arch/arm/dts/rk3399-khadas-edge-v.dts b/arch/arm/dts/rk3399-khadas-edge-v.dts
> new file mode 100644
> index 0000000..f5dcb99
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge-v.dts
> @@ -0,0 +1,27 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +/dts-v1/;
> +#include "rk3399-khadas-edge.dtsi"
> +
> +/ {
> + model = "Khadas Edge-V";
> + compatible = "khadas,edge-v", "rockchip,rk3399";
> +};
> +
> +&gmac {
> + status = "okay";
> +};
> +
> +&pcie_phy {
> + status = "okay";
> +};
> +
> +&pcie0 {
> + ep-gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
> + num-lanes = <4>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/rk3399-khadas-edge.dts b/arch/arm/dts/rk3399-khadas-edge.dts
> new file mode 100644
> index 0000000..31616e7
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge.dts
> @@ -0,0 +1,13 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +/dts-v1/;
> +#include "rk3399-khadas-edge.dtsi"
> +
> +/ {
> + model = "Khadas Edge";
> + compatible = "khadas,edge", "rockchip,rk3399";
> +};
> diff --git a/arch/arm/dts/rk3399-khadas-edge.dtsi b/arch/arm/dts/rk3399-khadas-edge.dtsi
> new file mode 100644
> index 0000000..4944d78
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-khadas-edge.dtsi
> @@ -0,0 +1,804 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
> + * (https://www.khadas.com)
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include <dt-bindings/pwm/pwm.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>;
> + };
> +
> + 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 = <&gpio2 RK_PD4 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>;
> + };
> +
> + vcc3v3_pcie: vcc3v3-pcie-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_pcie";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vsys_3v3>;
> + };
> +
> + /* 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_PD1 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc5v0_host_en>;
> + regulator-name = "vcc5v0_host";
> + regulator-always-on;
> + vin-supply = <&vsys_5v0>;
> + };
> +
> + 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 = <&vsys_3v3>;
> + };
> +
> + vsys: vsys {
> + compatible = "regulator-fixed";
> + regulator-name = "vsys";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vsys_3v3: vsys-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vsys_3v3";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vsys>;
> + };
> +
> + vsys_5v0: vsys-5v0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vsys_5v0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vsys>;
> + };
> +
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = <&saradc 1>;
> + io-channel-names = "buttons";
> + keyup-threshold-microvolt = <1800000>;
> + poll-interval = <100>;
> +
> + recovery {
> + label = "Recovery";
> + linux,code = <KEY_VENDOR>;
> + press-threshold-microvolt = <18000>;
> + };
> + };
> +
> + 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 = <&sys_led_gpio>, <&user_led_gpio>;
> +
> + sys-led {
> + label = "sys_led";
> + linux,default-trigger = "heartbeat";
> + gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
> + };
> +
> + user-led {
> + label = "user_led";
> + default-state = "off";
> + gpios = <&gpio4 RK_PD0 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + fan: pwm-fan {
> + compatible = "pwm-fan";
> + cooling-levels = <0 150 200 255>;
> + #cooling-cells = <2>;
> + fan-supply = <&vsys_5v0>;
> + pwms = <&pwm0 0 40000 0>;
> + };
> +};
> +
> +&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>;
> +};
> +
> +&cpu_thermal {
> + trips {
> + cpu_warm: cpu_warm {
> + temperature = <55000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> +
> + cpu_hot: cpu_hot {
> + temperature = <65000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map2 {
> + trip = <&cpu_warm>;
> + cooling-device = <&fan THERMAL_NO_LIMIT 1>;
> + };
> +
> + map3 {
> + trip = <&cpu_hot>;
> + cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> +&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>;
> +};
> +
> +&gpu {
> + mali-supply = <&vdd_gpu>;
> + status = "okay";
> +};
> +
> +&gpu_thermal {
> + trips {
> + gpu_warm: gpu_warm {
> + temperature = <55000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> +
> + gpu_hot: gpu_hot {
> + temperature = <65000>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> + };
> +
> + cooling-maps {
> + map1 {
> + trip = <&gpu_warm>;
> + cooling-device = <&fan THERMAL_NO_LIMIT 1>;
> + };
> +
> + map2 {
> + trip = <&gpu_hot>;
> + cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
> + };
> + };
> +};
> +
> +&hdmi {
> + ddc-i2c-bus = <&i2c3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&hdmi_cec>;
> + status = "okay";
> +};
> +
> +&hdmi_sound {
> + 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 = <168>;
> + i2c-scl-falling-time-ns = <4>;
> + status = "okay";
> +
> + rk808: pmic at 1b {
> + compatible = "rockchip,rk808";
> + reg = <0x1b>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <RK_PC6 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 = <&vsys_3v3>;
> + vcc2-supply = <&vsys_3v3>;
> + vcc3-supply = <&vsys_3v3>;
> + vcc4-supply = <&vsys_3v3>;
> + vcc6-supply = <&vsys_3v3>;
> + vcc7-supply = <&vsys_3v3>;
> + vcc8-supply = <&vsys_3v3>;
> + vcc9-supply = <&vsys_3v3>;
> + vcc10-supply = <&vsys_3v3>;
> + vcc11-supply = <&vsys_3v3>;
> + vcc12-supply = <&vsys_3v3>;
> + 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_apio2: LDO_REG1 {
> + regulator-name = "vcc1v8_apio2";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_vldo2: LDO_REG2 {
> + regulator-name = "vcc_vldo2";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc1v8_pmupll: LDO_REG3 {
> + regulator-name = "vcc1v8_pmupll";
> + 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>;
> + };
> + };
> +
> + vccio_sd: LDO_REG4 {
> + regulator-name = "vccio_sd";
> + 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>;
> + };
> + };
> +
> + vcc_vldo5: LDO_REG5 {
> + regulator-name = "vcc_vldo5";
> + 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>;
> + };
> + };
> +
> + vcc1v8_codec: LDO_REG7 {
> + 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;
> + };
> + };
> +
> + 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 = <&cpu_b_sleep>;
> + 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 = <&vsys_3v3>;
> +
> + 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-name = "vdd_gpu";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1500000>;
> + regulator-ramp-delay = <1000>;
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <&vsys_3v3>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +};
> +
> +&i2c8 {
> + clock-frequency = <400000>;
> + i2c-scl-rising-time-ns = <160>;
> + i2c-scl-falling-time-ns = <30>;
> + 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 {
> + bt656-supply = <&vcc1v8_apio2>;
> + audio-supply = <&vcc1v8_codec>;
> + sdmmc-supply = <&vccio_sd>;
> + gpio1830-supply = <&vcc_3v0>;
> + status = "okay";
> +};
> +
> +&pmu_io_domains {
> + pmu1830-supply = <&vcc_1v8>;
> + status = "okay";
> +};
> +
> +&pinctrl {
> + bt {
> + 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 {
> + rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + bt_wake_l: bt-wake-l {
> + rockchip,pins = <2 RK_PD2 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + buttons {
> + pwrbtn: pwrbtn {
> + rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + leds {
> + sys_led_gpio: sys_led-gpio {
> + rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + user_led_gpio: user_led-gpio {
> + rockchip,pins = <4 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + pmic_int_l: pmic-int-l {
> + rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> +
> + cpu_b_sleep: cpu-b-sleep {
> + rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> +
> + gpu_sleep: gpu-sleep {
> + rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> + };
> +
> + sdio-pwrseq {
> + wifi_enable_h: wifi-enable-h {
> + rockchip,pins = <2 RK_PD4 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + usb2 {
> + vcc5v0_host_en: vcc5v0-host-en {
> + rockchip,pins = <4 RK_PD1 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>;
> + };
> + };
> +};
> +
> +&pwm0 {
> + status = "okay";
> +};
> +
> +&pwm2 {
> + status = "okay";
> +};
> +
> +&saradc {
> + vref-supply = <&vcca1v8_s3>;
> + status = "okay";
> +};
> +
> +&sdio0 {
> + /* WiFi & BT combo module Ampak AP6356S */
> + bus-width = <4>;
> + cap-sdio-irq;
> + cap-sd-highspeed;
> + keep-power-in-suspend;
> + mmc-pwrseq = <&sdio_pwrseq>;
> + non-removable;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdio0_bus4 &sdio0_cmd &sdio0_clk>;
> + sd-uhs-sdr104;
> + vqmmc-supply = <&vcc1v8_s3>;
> + vmmc-supply = <&vccio_sd>;
> + status = "okay";
> +
> + brcmf: wifi at 1 {
> + compatible = "brcm,bcm4329-fmac";
> + interrupt-parent = <&gpio0>;
> + interrupts = <RK_PA3 GPIO_ACTIVE_HIGH>;
> + interrupt-names = "host-wake";
> + brcm,drive-strength = <5>;
> + 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>;
> + 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_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 = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
> + max-speed = <4000000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&bt_reg_on_h &bt_host_wake_l &bt_wake_l>;
> + vbat-supply = <&vsys_3v3>;
> + vddio-supply = <&vcc_1v8>;
> + };
> +};
> +
> +&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 3308b35..d9711ab 100644
> --- a/board/rockchip/evb_rk3399/MAINTAINERS
> +++ b/board/rockchip/evb_rk3399/MAINTAINERS
> @@ -6,6 +6,24 @@ F: include/configs/evb_rk3399.h
> F: configs/evb-rk3399_defconfig
> F: configs/firefly-rk3399_defconfig
>
> +KHADAS-EDGE
> +M: Nick Xie <nick@khadas.com>
> +S: Maintained
> +F: configs/khadas-edge-rk3399_defconfig
> +F: arch/arm/dts/rk3399-khadas-edge-u-boot.dtsi
> +
> +KHADAS-EDGE-CAPTAIN
> +M: Nick Xie <nick@khadas.com>
> +S: Maintained
> +F: configs/khadas-edge-captain-rk3399_defconfig
> +F: arch/arm/dts/rk3399-khadas-edge-captain-u-boot.dtsi
> +
> +KHADAS-EDGE-V
> +M: Nick Xie <nick@khadas.com>
> +S: Maintained
> +F: configs/khadas-edge-v-rk3399_defconfig
> +F: arch/arm/dts/rk3399-khadas-edge-v-u-boot.dtsi
> +
> NANOPC-T4
> M: Jagan Teki <jagan@amarulasolutions.com>
> S: Maintained
> diff --git a/configs/khadas-edge-captain-rk3399_defconfig b/configs/khadas-edge-captain-rk3399_defconfig
> new file mode 100644
> index 0000000..306b1b9
> --- /dev/null
> +++ b/configs/khadas-edge-captain-rk3399_defconfig
> @@ -0,0 +1,67 @@
> +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=0x50000
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL_STACK_R_ADDR=0x80000
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-captain.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
> +CONFIG_TPL=y
> +CONFIG_SYS_PROMPT="kedge# "
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_UUID=y
> +CONFIG_CMD_FS_UUID=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-captain"
> +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_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_PHY_REALTEK=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_SPL_TINY_MEMSET=y
> +CONFIG_ERRNO_STR=y
> diff --git a/configs/khadas-edge-rk3399_defconfig b/configs/khadas-edge-rk3399_defconfig
> new file mode 100644
> index 0000000..0e33911
> --- /dev/null
> +++ b/configs/khadas-edge-rk3399_defconfig
> @@ -0,0 +1,65 @@
> +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=0x50000
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL_STACK_R_ADDR=0x80000
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
> +CONFIG_TPL=y
> +CONFIG_SYS_PROMPT="kedge# "
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_UUID=y
> +CONFIG_CMD_FS_UUID=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge"
> +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_SPL_TINY_MEMSET=y
> +CONFIG_ERRNO_STR=y
> diff --git a/configs/khadas-edge-v-rk3399_defconfig b/configs/khadas-edge-v-rk3399_defconfig
> new file mode 100644
> index 0000000..59bf5ca
> --- /dev/null
> +++ b/configs/khadas-edge-v-rk3399_defconfig
> @@ -0,0 +1,67 @@
> +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=0x50000
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_SPL_STACK_R_ADDR=0x80000
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-khadas-edge-v.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
> +CONFIG_TPL=y
> +CONFIG_SYS_PROMPT="kedge# "
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPIO=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_I2C=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_CMD_UUID=y
> +CONFIG_CMD_FS_UUID=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-khadas-edge-v"
> +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_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_PHY_REALTEK=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_SPL_TINY_MEMSET=y
> +CONFIG_ERRNO_STR=y
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-18 8:25 ` [U-Boot] " Paul Kocialkowski
@ 2019-06-18 8:57 ` Jagan Teki
-1 siblings, 0 replies; 43+ messages in thread
From: Jagan Teki @ 2019-06-18 8:57 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: U-Boot-Denx, Simon Glass, Kever Yang,
open list:ARM/Rockchip SoC...,
nick-XW3xCAIBE2TQT0dZR+AlfA, Philipp Tomsich, linux-amarula,
Nick Xie
On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
<paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>
> Hi,
>
> On Mon, 2019-06-17 at 15:24 +0800, xieqinick-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> > From: Nick Xie <nick-XW3xCAIBE2TQT0dZR+AlfA@public.gmane.org>
>
> Was this tested with SPL support? I don't see DRAM configuration here
> so it seems that it relies on the non-free rockchip loader.
>
> If that is the case, could you please indicate that in the commit
> message?
>
> To maintainers: please do not merge this series before DRAM init and
> SPL support is available for these boards.
>
> It seems that other RK3399 boards were merged without SPL support and
> sofar, I have the feeling that nobody cared to explain how we got into
> this broken situation. Please don't merge any more such board.
fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
with TPL-enabled (which was discussed on the threads, if you remember)
with below boot chain.
rkbin (TPL) -> SPL -> U-Boot proper
Same case for this board as well.
Jagan.
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-18 8:57 ` Jagan Teki
0 siblings, 0 replies; 43+ messages in thread
From: Jagan Teki @ 2019-06-18 8:57 UTC (permalink / raw)
To: u-boot
On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
<paul.kocialkowski@bootlin.com> wrote:
>
> Hi,
>
> On Mon, 2019-06-17 at 15:24 +0800, xieqinick at gmail.com wrote:
> > From: Nick Xie <nick@khadas.com>
>
> Was this tested with SPL support? I don't see DRAM configuration here
> so it seems that it relies on the non-free rockchip loader.
>
> If that is the case, could you please indicate that in the commit
> message?
>
> To maintainers: please do not merge this series before DRAM init and
> SPL support is available for these boards.
>
> It seems that other RK3399 boards were merged without SPL support and
> sofar, I have the feeling that nobody cared to explain how we got into
> this broken situation. Please don't merge any more such board.
fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
with TPL-enabled (which was discussed on the threads, if you remember)
with below boot chain.
rkbin (TPL) -> SPL -> U-Boot proper
Same case for this board as well.
Jagan.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-18 8:57 ` [U-Boot] " Jagan Teki
@ 2019-06-18 9:03 ` Paul Kocialkowski
-1 siblings, 0 replies; 43+ messages in thread
From: Paul Kocialkowski @ 2019-06-18 9:03 UTC (permalink / raw)
To: Jagan Teki
Cc: U-Boot-Denx, open list:ARM/Rockchip SoC...,
nick, linux-amarula, Nick Xie
Hi,
On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> >
> > On Mon, 2019-06-17 at 15:24 +0800, xieqinick@gmail.com wrote:
> > > From: Nick Xie <nick@khadas.com>
> >
> > Was this tested with SPL support? I don't see DRAM configuration here
> > so it seems that it relies on the non-free rockchip loader.
> >
> > If that is the case, could you please indicate that in the commit
> > message?
> >
> > To maintainers: please do not merge this series before DRAM init and
> > SPL support is available for these boards.
> >
> > It seems that other RK3399 boards were merged without SPL support and
> > sofar, I have the feeling that nobody cared to explain how we got into
> > this broken situation. Please don't merge any more such board.
>
> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> with TPL-enabled (which was discussed on the threads, if you remember)
> with below boot chain.
>
> rkbin (TPL) -> SPL -> U-Boot proper
>
> Same case for this board as well.
Here is a quote from Philipp Tomsich on the thread we discussed this:
" On some boards, there will be no TPL and only a SPL stage that will
initialise DRAM (as the move to having TPL on the RK3399 is optional).
I agree with Paul that the DRAM init should be part of U-Boot whenever
we add new boards and make an open DRAM init a prerequisite. "
So even if I frequently confuse SPL and TPL, it doesn't change the fact
that no board should be merged without proper DRAM init.
Please stop pushing for merging these boards. I'm not sure what we
should do about the boards that were merged already without DRAM init,
but maybe they should be reverted.
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] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-18 9:03 ` Paul Kocialkowski
0 siblings, 0 replies; 43+ messages in thread
From: Paul Kocialkowski @ 2019-06-18 9:03 UTC (permalink / raw)
To: u-boot
Hi,
On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> <paul.kocialkowski@bootlin.com> wrote:
> > Hi,
> >
> > On Mon, 2019-06-17 at 15:24 +0800, xieqinick at gmail.com wrote:
> > > From: Nick Xie <nick@khadas.com>
> >
> > Was this tested with SPL support? I don't see DRAM configuration here
> > so it seems that it relies on the non-free rockchip loader.
> >
> > If that is the case, could you please indicate that in the commit
> > message?
> >
> > To maintainers: please do not merge this series before DRAM init and
> > SPL support is available for these boards.
> >
> > It seems that other RK3399 boards were merged without SPL support and
> > sofar, I have the feeling that nobody cared to explain how we got into
> > this broken situation. Please don't merge any more such board.
>
> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> with TPL-enabled (which was discussed on the threads, if you remember)
> with below boot chain.
>
> rkbin (TPL) -> SPL -> U-Boot proper
>
> Same case for this board as well.
Here is a quote from Philipp Tomsich on the thread we discussed this:
" On some boards, there will be no TPL and only a SPL stage that will
initialise DRAM (as the move to having TPL on the RK3399 is optional).
I agree with Paul that the DRAM init should be part of U-Boot whenever
we add new boards and make an open DRAM init a prerequisite. "
So even if I frequently confuse SPL and TPL, it doesn't change the fact
that no board should be merged without proper DRAM init.
Please stop pushing for merging these boards. I'm not sure what we
should do about the boards that were merged already without DRAM init,
but maybe they should be reverted.
Cheers,
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-18 9:03 ` [U-Boot] " Paul Kocialkowski
@ 2019-06-18 10:08 ` Kever Yang
-1 siblings, 0 replies; 43+ messages in thread
From: Kever Yang @ 2019-06-18 10:08 UTC (permalink / raw)
To: Paul Kocialkowski, Jagan Teki
Cc: U-Boot-Denx, open list:ARM/Rockchip SoC...,
nick, linux-amarula, Nick Xie
Hi Paul,
On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> Hi,
>
> On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
>> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
>> <paul.kocialkowski@bootlin.com> wrote:
>>> Hi,
>>>
>>> On Mon, 2019-06-17 at 15:24 +0800, xieqinick@gmail.com wrote:
>>>> From: Nick Xie <nick@khadas.com>
>>> Was this tested with SPL support? I don't see DRAM configuration here
>>> so it seems that it relies on the non-free rockchip loader.
>>>
>>> If that is the case, could you please indicate that in the commit
>>> message?
>>>
>>> To maintainers: please do not merge this series before DRAM init and
>>> SPL support is available for these boards.
>>>
>>> It seems that other RK3399 boards were merged without SPL support and
>>> sofar, I have the feeling that nobody cared to explain how we got into
>>> this broken situation. Please don't merge any more such board.
>> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
>> with TPL-enabled (which was discussed on the threads, if you remember)
>> with below boot chain.
>>
>> rkbin (TPL) -> SPL -> U-Boot proper
>>
>> Same case for this board as well.
> Here is a quote from Philipp Tomsich on the thread we discussed this:
>
> " On some boards, there will be no TPL and only a SPL stage that will
> initialise DRAM (as the move to having TPL on the RK3399 is optional).
>
> I agree with Paul that the DRAM init should be part of U-Boot whenever
> we add new boards and make an open DRAM init a prerequisite. "
>
> So even if I frequently confuse SPL and TPL, it doesn't change the fact
> that no board should be merged without proper DRAM init.
>
> Please stop pushing for merging these boards. I'm not sure what we
> should do about the boards that were merged already without DRAM init,
> but maybe they should be reverted.
I don't think we have to have full DRAM init source code for each
board before we can merge it, I believe most of the board on U-Boot
mainline need to removed due to this rule. There are so many boards
from different vendor need a binary loader before U-Boot, and I can
see only very few drivers for dram at driver/ram/, and I believe rockchip
is already the most open vendor on this area.
I won't use this rule to stop developers contribute there source code,
for a board support, we only need the board to have the full documentation
about how to setup and boot with upstream U-Boot. and I think the
most of people cares more about features in U-Boot proper. Everything
before U-Boot proper, you can use TPL/SPL or alternative to use binary
from vendor, as you can see all over the U-Boot mainline now, although
we encourage people to use full open source TPL/SPL.
Specifically for U-Boot Rockchip platform, I would like people to
support not only U-Boot
proper, but also for full SPL(ATF, OP-TEE support, itb image and other
features)
support. And for DRAM init,
- if this belongs to SPL for this board, you must implement it or else
SPL won't work;
- if this does not belong to SPL for this board, you need implement full
function SPL;
and you can either to have full function TPL with DRAM init(which is
prefered)
or alternatively use binary loader from vendor.
I'm not sure if you have write a new dram driver for a board, but I know
even the board vendor may not have the capability to write the DRAM
driver, so this should not stop developers contribute to all other 99%
features on U-Boot.
Thanks,
- Kever
>
> Cheers,
>
> Paul
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-18 10:08 ` Kever Yang
0 siblings, 0 replies; 43+ messages in thread
From: Kever Yang @ 2019-06-18 10:08 UTC (permalink / raw)
To: u-boot
Hi Paul,
On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> Hi,
>
> On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
>> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
>> <paul.kocialkowski@bootlin.com> wrote:
>>> Hi,
>>>
>>> On Mon, 2019-06-17 at 15:24 +0800, xieqinick at gmail.com wrote:
>>>> From: Nick Xie <nick@khadas.com>
>>> Was this tested with SPL support? I don't see DRAM configuration here
>>> so it seems that it relies on the non-free rockchip loader.
>>>
>>> If that is the case, could you please indicate that in the commit
>>> message?
>>>
>>> To maintainers: please do not merge this series before DRAM init and
>>> SPL support is available for these boards.
>>>
>>> It seems that other RK3399 boards were merged without SPL support and
>>> sofar, I have the feeling that nobody cared to explain how we got into
>>> this broken situation. Please don't merge any more such board.
>> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
>> with TPL-enabled (which was discussed on the threads, if you remember)
>> with below boot chain.
>>
>> rkbin (TPL) -> SPL -> U-Boot proper
>>
>> Same case for this board as well.
> Here is a quote from Philipp Tomsich on the thread we discussed this:
>
> " On some boards, there will be no TPL and only a SPL stage that will
> initialise DRAM (as the move to having TPL on the RK3399 is optional).
>
> I agree with Paul that the DRAM init should be part of U-Boot whenever
> we add new boards and make an open DRAM init a prerequisite. "
>
> So even if I frequently confuse SPL and TPL, it doesn't change the fact
> that no board should be merged without proper DRAM init.
>
> Please stop pushing for merging these boards. I'm not sure what we
> should do about the boards that were merged already without DRAM init,
> but maybe they should be reverted.
I don't think we have to have full DRAM init source code for each
board before we can merge it, I believe most of the board on U-Boot
mainline need to removed due to this rule. There are so many boards
from different vendor need a binary loader before U-Boot, and I can
see only very few drivers for dram at driver/ram/, and I believe rockchip
is already the most open vendor on this area.
I won't use this rule to stop developers contribute there source code,
for a board support, we only need the board to have the full documentation
about how to setup and boot with upstream U-Boot. and I think the
most of people cares more about features in U-Boot proper. Everything
before U-Boot proper, you can use TPL/SPL or alternative to use binary
from vendor, as you can see all over the U-Boot mainline now, although
we encourage people to use full open source TPL/SPL.
Specifically for U-Boot Rockchip platform, I would like people to
support not only U-Boot
proper, but also for full SPL(ATF, OP-TEE support, itb image and other
features)
support. And for DRAM init,
- if this belongs to SPL for this board, you must implement it or else
SPL won't work;
- if this does not belong to SPL for this board, you need implement full
function SPL;
and you can either to have full function TPL with DRAM init(which is
prefered)
or alternatively use binary loader from vendor.
I'm not sure if you have write a new dram driver for a board, but I know
even the board vendor may not have the capability to write the DRAM
driver, so this should not stop developers contribute to all other 99%
features on U-Boot.
Thanks,
- Kever
>
> Cheers,
>
> Paul
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-18 10:08 ` [U-Boot] " Kever Yang
@ 2019-06-18 12:47 ` Paul Kocialkowski
-1 siblings, 0 replies; 43+ messages in thread
From: Paul Kocialkowski @ 2019-06-18 12:47 UTC (permalink / raw)
To: Kever Yang, Jagan Teki
Cc: U-Boot-Denx, open list:ARM/Rockchip SoC...,
nick, linux-amarula, Nick Xie
Hi Kever,
On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> Hi Paul,
>
>
> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > >
> > > > On Mon, 2019-06-17 at 15:24 +0800, xieqinick@gmail.com wrote:
> > > > > From: Nick Xie <nick@khadas.com>
> > > > Was this tested with SPL support? I don't see DRAM configuration here
> > > > so it seems that it relies on the non-free rockchip loader.
> > > >
> > > > If that is the case, could you please indicate that in the commit
> > > > message?
> > > >
> > > > To maintainers: please do not merge this series before DRAM init and
> > > > SPL support is available for these boards.
> > > >
> > > > It seems that other RK3399 boards were merged without SPL support and
> > > > sofar, I have the feeling that nobody cared to explain how we got into
> > > > this broken situation. Please don't merge any more such board.
> > > fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > > with TPL-enabled (which was discussed on the threads, if you remember)
> > > with below boot chain.
> > >
> > > rkbin (TPL) -> SPL -> U-Boot proper
> > >
> > > Same case for this board as well.
> > Here is a quote from Philipp Tomsich on the thread we discussed this:
> >
> > " On some boards, there will be no TPL and only a SPL stage that will
> > initialise DRAM (as the move to having TPL on the RK3399 is optional).
> >
> > I agree with Paul that the DRAM init should be part of U-Boot whenever
> > we add new boards and make an open DRAM init a prerequisite. "
> >
> > So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > that no board should be merged without proper DRAM init.
> >
> > Please stop pushing for merging these boards. I'm not sure what we
> > should do about the boards that were merged already without DRAM init,
> > but maybe they should be reverted.
>
> I don't think we have to have full DRAM init source code for each
> board before we can merge it, I believe most of the board on U-Boot
> mainline need to removed due to this rule. There are so many boards
> from different vendor need a binary loader before U-Boot, and I can
> see only very few drivers for dram at driver/ram/, and I believe rockchip
> is already the most open vendor on this area.
Well, I am not talking about full DRAM init source code as in dynamic
link training. I am talking about having at least static DRAM register
configuration values, which is present for a good number of rockchip
boards.
Of course, it would be best if Rockchip would consider releasing this
source code, which would be the easiest and friendliest solution
towards the community here. Are there internal discussions ongoing
about this? If not, it would be greatly appreciated to start such
discussions and clearly identify what the blocking points are.
> I won't use this rule to stop developers contribute there source code,
This is really sad and I think that Philipp was, like me, inclined to
go towards the other direction.
> for a board support, we only need the board to have the full documentation
> about how to setup and boot with upstream U-Boot. and I think the
> most of people cares more about features in U-Boot proper. Everything
> before U-Boot proper, you can use TPL/SPL or alternative to use binary
> from vendor, as you can see all over the U-Boot mainline now, although
> we encourage people to use full open source TPL/SPL.
> Specifically for U-Boot Rockchip platform, I would like people to
> support not only U-Boot
> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> features)
> support. And for DRAM init,
> - if this belongs to SPL for this board, you must implement it or else
> SPL won't work;
> - if this does not belong to SPL for this board, you need implement full
> function SPL;
> and you can either to have full function TPL with DRAM init(which is
> prefered)
> or alternatively use binary loader from vendor.
This is not really a technical argument here, more of a policy argument
that ensures we have full free software support for the boards we
support, and not only half-cooked support (that will most likely never
be completed as soon as something that works gets merged). So it is a
strategical decision, not a strictly pragmatic one.
I think reverting patches adding support for boards with no DRAM
configuration at all would send a message in the right direction here.
> I'm not sure if you have write a new dram driver for a board, but I know
> even the board vendor may not have the capability to write the DRAM
> driver, so this should not stop developers contribute to all other 99%
> features on U-Boot.
What they can do is run the non-free blob, dump the registers
afterwards and then use that in the DRAM configuration dtsi. Perhaps
one could write up a tool to ease the process if they think the process
is too much for a regular bringup.
Most of the time, the DRAM chips are soldered so the calibrated values
have about no reason to change over time and can just be kept as-is.
What do you think?
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] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-18 12:47 ` Paul Kocialkowski
0 siblings, 0 replies; 43+ messages in thread
From: Paul Kocialkowski @ 2019-06-18 12:47 UTC (permalink / raw)
To: u-boot
Hi Kever,
On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> Hi Paul,
>
>
> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > > <paul.kocialkowski@bootlin.com> wrote:
> > > > Hi,
> > > >
> > > > On Mon, 2019-06-17 at 15:24 +0800, xieqinick at gmail.com wrote:
> > > > > From: Nick Xie <nick@khadas.com>
> > > > Was this tested with SPL support? I don't see DRAM configuration here
> > > > so it seems that it relies on the non-free rockchip loader.
> > > >
> > > > If that is the case, could you please indicate that in the commit
> > > > message?
> > > >
> > > > To maintainers: please do not merge this series before DRAM init and
> > > > SPL support is available for these boards.
> > > >
> > > > It seems that other RK3399 boards were merged without SPL support and
> > > > sofar, I have the feeling that nobody cared to explain how we got into
> > > > this broken situation. Please don't merge any more such board.
> > > fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > > with TPL-enabled (which was discussed on the threads, if you remember)
> > > with below boot chain.
> > >
> > > rkbin (TPL) -> SPL -> U-Boot proper
> > >
> > > Same case for this board as well.
> > Here is a quote from Philipp Tomsich on the thread we discussed this:
> >
> > " On some boards, there will be no TPL and only a SPL stage that will
> > initialise DRAM (as the move to having TPL on the RK3399 is optional).
> >
> > I agree with Paul that the DRAM init should be part of U-Boot whenever
> > we add new boards and make an open DRAM init a prerequisite. "
> >
> > So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > that no board should be merged without proper DRAM init.
> >
> > Please stop pushing for merging these boards. I'm not sure what we
> > should do about the boards that were merged already without DRAM init,
> > but maybe they should be reverted.
>
> I don't think we have to have full DRAM init source code for each
> board before we can merge it, I believe most of the board on U-Boot
> mainline need to removed due to this rule. There are so many boards
> from different vendor need a binary loader before U-Boot, and I can
> see only very few drivers for dram at driver/ram/, and I believe rockchip
> is already the most open vendor on this area.
Well, I am not talking about full DRAM init source code as in dynamic
link training. I am talking about having at least static DRAM register
configuration values, which is present for a good number of rockchip
boards.
Of course, it would be best if Rockchip would consider releasing this
source code, which would be the easiest and friendliest solution
towards the community here. Are there internal discussions ongoing
about this? If not, it would be greatly appreciated to start such
discussions and clearly identify what the blocking points are.
> I won't use this rule to stop developers contribute there source code,
This is really sad and I think that Philipp was, like me, inclined to
go towards the other direction.
> for a board support, we only need the board to have the full documentation
> about how to setup and boot with upstream U-Boot. and I think the
> most of people cares more about features in U-Boot proper. Everything
> before U-Boot proper, you can use TPL/SPL or alternative to use binary
> from vendor, as you can see all over the U-Boot mainline now, although
> we encourage people to use full open source TPL/SPL.
> Specifically for U-Boot Rockchip platform, I would like people to
> support not only U-Boot
> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> features)
> support. And for DRAM init,
> - if this belongs to SPL for this board, you must implement it or else
> SPL won't work;
> - if this does not belong to SPL for this board, you need implement full
> function SPL;
> and you can either to have full function TPL with DRAM init(which is
> prefered)
> or alternatively use binary loader from vendor.
This is not really a technical argument here, more of a policy argument
that ensures we have full free software support for the boards we
support, and not only half-cooked support (that will most likely never
be completed as soon as something that works gets merged). So it is a
strategical decision, not a strictly pragmatic one.
I think reverting patches adding support for boards with no DRAM
configuration at all would send a message in the right direction here.
> I'm not sure if you have write a new dram driver for a board, but I know
> even the board vendor may not have the capability to write the DRAM
> driver, so this should not stop developers contribute to all other 99%
> features on U-Boot.
What they can do is run the non-free blob, dump the registers
afterwards and then use that in the DRAM configuration dtsi. Perhaps
one could write up a tool to ease the process if they think the process
is too much for a regular bringup.
Most of the time, the DRAM chips are soldered so the calibrated values
have about no reason to change over time and can just be kept as-is.
What do you think?
Cheers,
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-18 12:47 ` [U-Boot] " Paul Kocialkowski
@ 2019-06-18 16:12 ` Mark Kettenis
-1 siblings, 0 replies; 43+ messages in thread
From: Mark Kettenis @ 2019-06-18 16:12 UTC (permalink / raw)
To: Paul Kocialkowski; +Cc: linux-rockchip, u-boot, nick, linux-amarula, xieqinick
> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> Date: Tue, 18 Jun 2019 14:47:33 +0200
>
> Hi Kever,
>
> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> > Hi Paul,
> >
> >
> > On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > > Hi,
> > >
> > > On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > > On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On Mon, 2019-06-17 at 15:24 +0800, xieqinick@gmail.com wrote:
> > > > > > From: Nick Xie <nick@khadas.com>
> > > > > Was this tested with SPL support? I don't see DRAM configuration here
> > > > > so it seems that it relies on the non-free rockchip loader.
> > > > >
> > > > > If that is the case, could you please indicate that in the commit
> > > > > message?
> > > > >
> > > > > To maintainers: please do not merge this series before DRAM init and
> > > > > SPL support is available for these boards.
> > > > >
> > > > > It seems that other RK3399 boards were merged without SPL support and
> > > > > sofar, I have the feeling that nobody cared to explain how we got into
> > > > > this broken situation. Please don't merge any more such board.
> > > > fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > > > with TPL-enabled (which was discussed on the threads, if you remember)
> > > > with below boot chain.
> > > >
> > > > rkbin (TPL) -> SPL -> U-Boot proper
> > > >
> > > > Same case for this board as well.
> > > Here is a quote from Philipp Tomsich on the thread we discussed this:
> > >
> > > " On some boards, there will be no TPL and only a SPL stage that will
> > > initialise DRAM (as the move to having TPL on the RK3399 is optional).
> > >
> > > I agree with Paul that the DRAM init should be part of U-Boot whenever
> > > we add new boards and make an open DRAM init a prerequisite. "
> > >
> > > So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > > that no board should be merged without proper DRAM init.
> > >
> > > Please stop pushing for merging these boards. I'm not sure what we
> > > should do about the boards that were merged already without DRAM init,
> > > but maybe they should be reverted.
> >
> > I don't think we have to have full DRAM init source code for each
> > board before we can merge it, I believe most of the board on U-Boot
> > mainline need to removed due to this rule. There are so many boards
> > from different vendor need a binary loader before U-Boot, and I can
> > see only very few drivers for dram at driver/ram/, and I believe rockchip
> > is already the most open vendor on this area.
>
> Well, I am not talking about full DRAM init source code as in dynamic
> link training. I am talking about having at least static DRAM register
> configuration values, which is present for a good number of rockchip
> boards.
>
> Of course, it would be best if Rockchip would consider releasing this
> source code, which would be the easiest and friendliest solution
> towards the community here. Are there internal discussions ongoing
> about this? If not, it would be greatly appreciated to start such
> discussions and clearly identify what the blocking points are.
>
> > I won't use this rule to stop developers contribute there source code,
>
> This is really sad and I think that Philipp was, like me, inclined to
> go towards the other direction.
>
> > for a board support, we only need the board to have the full documentation
> > about how to setup and boot with upstream U-Boot. and I think the
> > most of people cares more about features in U-Boot proper. Everything
> > before U-Boot proper, you can use TPL/SPL or alternative to use binary
> > from vendor, as you can see all over the U-Boot mainline now, although
> > we encourage people to use full open source TPL/SPL.
> > Specifically for U-Boot Rockchip platform, I would like people to
> > support not only U-Boot
> > proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> > features)
> > support. And for DRAM init,
> > - if this belongs to SPL for this board, you must implement it or else
> > SPL won't work;
> > - if this does not belong to SPL for this board, you need implement full
> > function SPL;
> > and you can either to have full function TPL with DRAM init(which is
> > prefered)
> > or alternatively use binary loader from vendor.
>
> This is not really a technical argument here, more of a policy argument
> that ensures we have full free software support for the boards we
> support, and not only half-cooked support (that will most likely never
> be completed as soon as something that works gets merged). So it is a
> strategical decision, not a strictly pragmatic one.
While having full open source software support for boards is a noble
goal, I think there should be some room for pragmatism here. A
significant number of u_boot targets rely on closed source components.
In the particular case of RK3399 the situation is better than for
other boards since you can combine the binary loader from the vendor
with mainline U-Boot and mainline ATF to create a firmware where (as
far as we can tell) no closed soure component remains active after
U-Boot and ATF take over control.
> I think reverting patches adding support for boards with no DRAM
> configuration at all would send a message in the right direction here.
Frankly, I don't think that would help. It would just drive more
people to the vendor U-Boot that has more bugs and includes a vendor
supplied ATF binary.
> > I'm not sure if you have write a new dram driver for a board, but I know
> > even the board vendor may not have the capability to write the DRAM
> > driver, so this should not stop developers contribute to all other 99%
> > features on U-Boot.
>
> What they can do is run the non-free blob, dump the registers
> afterwards and then use that in the DRAM configuration dtsi. Perhaps
> one could write up a tool to ease the process if they think the process
> is too much for a regular bringup.
>
> Most of the time, the DRAM chips are soldered so the calibrated values
> have about no reason to change over time and can just be kept as-is.
>
> What do you think?
Hopefully the pending diff to add support for other DRAM types beyond
those that are already supported would make bring us a long way in
that direction. Maybe one of the existing timings will already work
for the boards that are being discussed here.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-18 16:12 ` Mark Kettenis
0 siblings, 0 replies; 43+ messages in thread
From: Mark Kettenis @ 2019-06-18 16:12 UTC (permalink / raw)
To: u-boot
> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> Date: Tue, 18 Jun 2019 14:47:33 +0200
>
> Hi Kever,
>
> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> > Hi Paul,
> >
> >
> > On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > > Hi,
> > >
> > > On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > > On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > Hi,
> > > > >
> > > > > On Mon, 2019-06-17 at 15:24 +0800, xieqinick at gmail.com wrote:
> > > > > > From: Nick Xie <nick@khadas.com>
> > > > > Was this tested with SPL support? I don't see DRAM configuration here
> > > > > so it seems that it relies on the non-free rockchip loader.
> > > > >
> > > > > If that is the case, could you please indicate that in the commit
> > > > > message?
> > > > >
> > > > > To maintainers: please do not merge this series before DRAM init and
> > > > > SPL support is available for these boards.
> > > > >
> > > > > It seems that other RK3399 boards were merged without SPL support and
> > > > > sofar, I have the feeling that nobody cared to explain how we got into
> > > > > this broken situation. Please don't merge any more such board.
> > > > fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > > > with TPL-enabled (which was discussed on the threads, if you remember)
> > > > with below boot chain.
> > > >
> > > > rkbin (TPL) -> SPL -> U-Boot proper
> > > >
> > > > Same case for this board as well.
> > > Here is a quote from Philipp Tomsich on the thread we discussed this:
> > >
> > > " On some boards, there will be no TPL and only a SPL stage that will
> > > initialise DRAM (as the move to having TPL on the RK3399 is optional).
> > >
> > > I agree with Paul that the DRAM init should be part of U-Boot whenever
> > > we add new boards and make an open DRAM init a prerequisite. "
> > >
> > > So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > > that no board should be merged without proper DRAM init.
> > >
> > > Please stop pushing for merging these boards. I'm not sure what we
> > > should do about the boards that were merged already without DRAM init,
> > > but maybe they should be reverted.
> >
> > I don't think we have to have full DRAM init source code for each
> > board before we can merge it, I believe most of the board on U-Boot
> > mainline need to removed due to this rule. There are so many boards
> > from different vendor need a binary loader before U-Boot, and I can
> > see only very few drivers for dram at driver/ram/, and I believe rockchip
> > is already the most open vendor on this area.
>
> Well, I am not talking about full DRAM init source code as in dynamic
> link training. I am talking about having at least static DRAM register
> configuration values, which is present for a good number of rockchip
> boards.
>
> Of course, it would be best if Rockchip would consider releasing this
> source code, which would be the easiest and friendliest solution
> towards the community here. Are there internal discussions ongoing
> about this? If not, it would be greatly appreciated to start such
> discussions and clearly identify what the blocking points are.
>
> > I won't use this rule to stop developers contribute there source code,
>
> This is really sad and I think that Philipp was, like me, inclined to
> go towards the other direction.
>
> > for a board support, we only need the board to have the full documentation
> > about how to setup and boot with upstream U-Boot. and I think the
> > most of people cares more about features in U-Boot proper. Everything
> > before U-Boot proper, you can use TPL/SPL or alternative to use binary
> > from vendor, as you can see all over the U-Boot mainline now, although
> > we encourage people to use full open source TPL/SPL.
> > Specifically for U-Boot Rockchip platform, I would like people to
> > support not only U-Boot
> > proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> > features)
> > support. And for DRAM init,
> > - if this belongs to SPL for this board, you must implement it or else
> > SPL won't work;
> > - if this does not belong to SPL for this board, you need implement full
> > function SPL;
> > and you can either to have full function TPL with DRAM init(which is
> > prefered)
> > or alternatively use binary loader from vendor.
>
> This is not really a technical argument here, more of a policy argument
> that ensures we have full free software support for the boards we
> support, and not only half-cooked support (that will most likely never
> be completed as soon as something that works gets merged). So it is a
> strategical decision, not a strictly pragmatic one.
While having full open source software support for boards is a noble
goal, I think there should be some room for pragmatism here. A
significant number of u_boot targets rely on closed source components.
In the particular case of RK3399 the situation is better than for
other boards since you can combine the binary loader from the vendor
with mainline U-Boot and mainline ATF to create a firmware where (as
far as we can tell) no closed soure component remains active after
U-Boot and ATF take over control.
> I think reverting patches adding support for boards with no DRAM
> configuration at all would send a message in the right direction here.
Frankly, I don't think that would help. It would just drive more
people to the vendor U-Boot that has more bugs and includes a vendor
supplied ATF binary.
> > I'm not sure if you have write a new dram driver for a board, but I know
> > even the board vendor may not have the capability to write the DRAM
> > driver, so this should not stop developers contribute to all other 99%
> > features on U-Boot.
>
> What they can do is run the non-free blob, dump the registers
> afterwards and then use that in the DRAM configuration dtsi. Perhaps
> one could write up a tool to ease the process if they think the process
> is too much for a regular bringup.
>
> Most of the time, the DRAM chips are soldered so the calibrated values
> have about no reason to change over time and can just be kept as-is.
>
> What do you think?
Hopefully the pending diff to add support for other DRAM types beyond
those that are already supported would make bring us a long way in
that direction. Maybe one of the existing timings will already work
for the boards that are being discussed here.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-18 16:12 ` [U-Boot] " Mark Kettenis
@ 2019-06-19 1:42 ` Kever Yang
-1 siblings, 0 replies; 43+ messages in thread
From: Kever Yang @ 2019-06-19 1:42 UTC (permalink / raw)
To: Mark Kettenis, Paul Kocialkowski
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
u-boot-0aAXYlwwYIKGBzrmiIFOJg,
jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
nick-XW3xCAIBE2TQT0dZR+AlfA,
linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
xieqinick-Re5JQEeQqe8AvxtiuMwx3w
Hi Paul,
On 06/19/2019 12:12 AM, Mark Kettenis wrote:
>> From: Paul Kocialkowski <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
>> Date: Tue, 18 Jun 2019 14:47:33 +0200
>>
>> Hi Kever,
>>
>> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
>>> Hi Paul,
>>>
>>>
>>> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
>>>> Hi,
>>>>
>>>> On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
>>>>> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
>>>>> <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, 2019-06-17 at 15:24 +0800, xieqinick-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
>>>>>>> From: Nick Xie <nick-XW3xCAIBE2TQT0dZR+AlfA@public.gmane.org>
>>>>>> Was this tested with SPL support? I don't see DRAM configuration here
>>>>>> so it seems that it relies on the non-free rockchip loader.
>>>>>>
>>>>>> If that is the case, could you please indicate that in the commit
>>>>>> message?
>>>>>>
>>>>>> To maintainers: please do not merge this series before DRAM init and
>>>>>> SPL support is available for these boards.
>>>>>>
>>>>>> It seems that other RK3399 boards were merged without SPL support and
>>>>>> sofar, I have the feeling that nobody cared to explain how we got into
>>>>>> this broken situation. Please don't merge any more such board.
>>>>> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
>>>>> with TPL-enabled (which was discussed on the threads, if you remember)
>>>>> with below boot chain.
>>>>>
>>>>> rkbin (TPL) -> SPL -> U-Boot proper
>>>>>
>>>>> Same case for this board as well.
>>>> Here is a quote from Philipp Tomsich on the thread we discussed this:
>>>>
>>>> " On some boards, there will be no TPL and only a SPL stage that will
>>>> initialise DRAM (as the move to having TPL on the RK3399 is optional).
>>>>
>>>> I agree with Paul that the DRAM init should be part of U-Boot whenever
>>>> we add new boards and make an open DRAM init a prerequisite. "
>>>>
>>>> So even if I frequently confuse SPL and TPL, it doesn't change the fact
>>>> that no board should be merged without proper DRAM init.
>>>>
>>>> Please stop pushing for merging these boards. I'm not sure what we
>>>> should do about the boards that were merged already without DRAM init,
>>>> but maybe they should be reverted.
>>> I don't think we have to have full DRAM init source code for each
>>> board before we can merge it, I believe most of the board on U-Boot
>>> mainline need to removed due to this rule. There are so many boards
>>> from different vendor need a binary loader before U-Boot, and I can
>>> see only very few drivers for dram at driver/ram/, and I believe rockchip
>>> is already the most open vendor on this area.
>> Well, I am not talking about full DRAM init source code as in dynamic
>> link training. I am talking about having at least static DRAM register
>> configuration values,
I can tell you that this is no work for all the boards, you can see how
rockchip
lpddr4(WIP, send by Jagan) driver works.
>> which is present for a good number of rockchip
>> boards.
No, there is no rockchip board only have static DRAM register
configuration values,
that maybe happens in other vendor.
>>
>> Of course, it would be best if Rockchip would consider releasing this
>> source code,
Rockchip already release all the DRAM init source code, including DDR3 ,
LPDDR3,
and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
everything,
which is not only static register configuration.
As I have said, rockchip is already the most open vendor in this area
till now, I don't know
if you have working on rockchip SoC based boards.
>> which would be the easiest and friendliest solution
>> towards the community here. Are there internal discussions ongoing
>> about this? If not, it would be greatly appreciated to start such
>> discussions and clearly identify what the blocking points are.
>>
>>> I won't use this rule to stop developers contribute there source code,
>> This is really sad and I think that Philipp was, like me, inclined to
>> go towards the other direction.
>>
>>> for a board support, we only need the board to have the full documentation
>>> about how to setup and boot with upstream U-Boot. and I think the
>>> most of people cares more about features in U-Boot proper. Everything
>>> before U-Boot proper, you can use TPL/SPL or alternative to use binary
>>> from vendor, as you can see all over the U-Boot mainline now, although
>>> we encourage people to use full open source TPL/SPL.
>>> Specifically for U-Boot Rockchip platform, I would like people to
>>> support not only U-Boot
>>> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
>>> features)
>>> support. And for DRAM init,
>>> - if this belongs to SPL for this board, you must implement it or else
>>> SPL won't work;
>>> - if this does not belong to SPL for this board, you need implement full
>>> function SPL;
>>> and you can either to have full function TPL with DRAM init(which is
>>> prefered)
>>> or alternatively use binary loader from vendor.
>> This is not really a technical argument here, more of a policy argument
>> that ensures we have full free software support for the boards we
>> support, and not only half-cooked support (that will most likely never
>> be completed as soon as something that works gets merged). So it is a
>> strategical decision, not a strictly pragmatic one.
> While having full open source software support for boards is a noble
> goal, I think there should be some room for pragmatism here. A
> significant number of u_boot targets rely on closed source components.
> In the particular case of RK3399 the situation is better than for
> other boards since you can combine the binary loader from the vendor
> with mainline U-Boot and mainline ATF to create a firmware where (as
> far as we can tell) no closed soure component remains active after
> U-Boot and ATF take over control.
>
>> I think reverting patches adding support for boards with no DRAM
>> configuration at all would send a message in the right direction here.
As a developer, I agree on this, but as a maintainer, I know too many
developers not able to do it and what most of developers need is other
features in U-Boot or SPL, and I would like the U-Boot mainline is more
active with more and more developers. So I'm afraid I agree with Mark
at this time for the policy.
If all the other SoC platforms can have the same rule for DRAM init driver
is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
imx, aml, and all others, then I would very happy to follow the rule.
Rockchip is open for open source the DRAM driver, you have to know this
is the decision by the vendor, but not any of developers.
On rockchip platform, developers no need to concern about the DRAM
driver(which is pretty hard for most developers) because rockchip
already contribute it.
For the time now, I know there will be full DRAM driver for rockchip SoC,
so the SoC/board support could be step by step:
U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
As you can see the rockchip LPDDR4 driver send by Jagan, has 99 patches
in V2, you can't use static register configuration to do this, and maybe you
can't have a workable version if rockchip don't release it, but I don't
think it's
correct to make all those boards with lpddr4 float outside the mainline
support
because many developers are using the boards, they can only use vendor
branch
if the board not support by mainline.
So I think merge those patches already make board work on mainline U-Boot
is pretty important for open source community.
Thanks,
- Kever
> Frankly, I don't think that would help. It would just drive more
> people to the vendor U-Boot that has more bugs and includes a vendor
> supplied ATF binary.
>
>>> I'm not sure if you have write a new dram driver for a board, but I know
>>> even the board vendor may not have the capability to write the DRAM
>>> driver, so this should not stop developers contribute to all other 99%
>>> features on U-Boot.
>> What they can do is run the non-free blob, dump the registers
>> afterwards and then use that in the DRAM configuration dtsi. Perhaps
>> one could write up a tool to ease the process if they think the process
>> is too much for a regular bringup.
>>
>> Most of the time, the DRAM chips are soldered so the calibrated values
>> have about no reason to change over time and can just be kept as-is.
>>
>> What do you think?
> Hopefully the pending diff to add support for other DRAM types beyond
> those that are already supported would make bring us a long way in
> that direction. Maybe one of the existing timings will already work
> for the boards that are being discussed here.
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-19 1:42 ` Kever Yang
0 siblings, 0 replies; 43+ messages in thread
From: Kever Yang @ 2019-06-19 1:42 UTC (permalink / raw)
To: u-boot
Hi Paul,
On 06/19/2019 12:12 AM, Mark Kettenis wrote:
>> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>> Date: Tue, 18 Jun 2019 14:47:33 +0200
>>
>> Hi Kever,
>>
>> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
>>> Hi Paul,
>>>
>>>
>>> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
>>>> Hi,
>>>>
>>>> On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
>>>>> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
>>>>> <paul.kocialkowski@bootlin.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, 2019-06-17 at 15:24 +0800, xieqinick at gmail.com wrote:
>>>>>>> From: Nick Xie <nick@khadas.com>
>>>>>> Was this tested with SPL support? I don't see DRAM configuration here
>>>>>> so it seems that it relies on the non-free rockchip loader.
>>>>>>
>>>>>> If that is the case, could you please indicate that in the commit
>>>>>> message?
>>>>>>
>>>>>> To maintainers: please do not merge this series before DRAM init and
>>>>>> SPL support is available for these boards.
>>>>>>
>>>>>> It seems that other RK3399 boards were merged without SPL support and
>>>>>> sofar, I have the feeling that nobody cared to explain how we got into
>>>>>> this broken situation. Please don't merge any more such board.
>>>>> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
>>>>> with TPL-enabled (which was discussed on the threads, if you remember)
>>>>> with below boot chain.
>>>>>
>>>>> rkbin (TPL) -> SPL -> U-Boot proper
>>>>>
>>>>> Same case for this board as well.
>>>> Here is a quote from Philipp Tomsich on the thread we discussed this:
>>>>
>>>> " On some boards, there will be no TPL and only a SPL stage that will
>>>> initialise DRAM (as the move to having TPL on the RK3399 is optional).
>>>>
>>>> I agree with Paul that the DRAM init should be part of U-Boot whenever
>>>> we add new boards and make an open DRAM init a prerequisite. "
>>>>
>>>> So even if I frequently confuse SPL and TPL, it doesn't change the fact
>>>> that no board should be merged without proper DRAM init.
>>>>
>>>> Please stop pushing for merging these boards. I'm not sure what we
>>>> should do about the boards that were merged already without DRAM init,
>>>> but maybe they should be reverted.
>>> I don't think we have to have full DRAM init source code for each
>>> board before we can merge it, I believe most of the board on U-Boot
>>> mainline need to removed due to this rule. There are so many boards
>>> from different vendor need a binary loader before U-Boot, and I can
>>> see only very few drivers for dram at driver/ram/, and I believe rockchip
>>> is already the most open vendor on this area.
>> Well, I am not talking about full DRAM init source code as in dynamic
>> link training. I am talking about having at least static DRAM register
>> configuration values,
I can tell you that this is no work for all the boards, you can see how
rockchip
lpddr4(WIP, send by Jagan) driver works.
>> which is present for a good number of rockchip
>> boards.
No, there is no rockchip board only have static DRAM register
configuration values,
that maybe happens in other vendor.
>>
>> Of course, it would be best if Rockchip would consider releasing this
>> source code,
Rockchip already release all the DRAM init source code, including DDR3 ,
LPDDR3,
and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
everything,
which is not only static register configuration.
As I have said, rockchip is already the most open vendor in this area
till now, I don't know
if you have working on rockchip SoC based boards.
>> which would be the easiest and friendliest solution
>> towards the community here. Are there internal discussions ongoing
>> about this? If not, it would be greatly appreciated to start such
>> discussions and clearly identify what the blocking points are.
>>
>>> I won't use this rule to stop developers contribute there source code,
>> This is really sad and I think that Philipp was, like me, inclined to
>> go towards the other direction.
>>
>>> for a board support, we only need the board to have the full documentation
>>> about how to setup and boot with upstream U-Boot. and I think the
>>> most of people cares more about features in U-Boot proper. Everything
>>> before U-Boot proper, you can use TPL/SPL or alternative to use binary
>>> from vendor, as you can see all over the U-Boot mainline now, although
>>> we encourage people to use full open source TPL/SPL.
>>> Specifically for U-Boot Rockchip platform, I would like people to
>>> support not only U-Boot
>>> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
>>> features)
>>> support. And for DRAM init,
>>> - if this belongs to SPL for this board, you must implement it or else
>>> SPL won't work;
>>> - if this does not belong to SPL for this board, you need implement full
>>> function SPL;
>>> and you can either to have full function TPL with DRAM init(which is
>>> prefered)
>>> or alternatively use binary loader from vendor.
>> This is not really a technical argument here, more of a policy argument
>> that ensures we have full free software support for the boards we
>> support, and not only half-cooked support (that will most likely never
>> be completed as soon as something that works gets merged). So it is a
>> strategical decision, not a strictly pragmatic one.
> While having full open source software support for boards is a noble
> goal, I think there should be some room for pragmatism here. A
> significant number of u_boot targets rely on closed source components.
> In the particular case of RK3399 the situation is better than for
> other boards since you can combine the binary loader from the vendor
> with mainline U-Boot and mainline ATF to create a firmware where (as
> far as we can tell) no closed soure component remains active after
> U-Boot and ATF take over control.
>
>> I think reverting patches adding support for boards with no DRAM
>> configuration at all would send a message in the right direction here.
As a developer, I agree on this, but as a maintainer, I know too many
developers not able to do it and what most of developers need is other
features in U-Boot or SPL, and I would like the U-Boot mainline is more
active with more and more developers. So I'm afraid I agree with Mark
at this time for the policy.
If all the other SoC platforms can have the same rule for DRAM init driver
is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
imx, aml, and all others, then I would very happy to follow the rule.
Rockchip is open for open source the DRAM driver, you have to know this
is the decision by the vendor, but not any of developers.
On rockchip platform, developers no need to concern about the DRAM
driver(which is pretty hard for most developers) because rockchip
already contribute it.
For the time now, I know there will be full DRAM driver for rockchip SoC,
so the SoC/board support could be step by step:
U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
As you can see the rockchip LPDDR4 driver send by Jagan, has 99 patches
in V2, you can't use static register configuration to do this, and maybe you
can't have a workable version if rockchip don't release it, but I don't
think it's
correct to make all those boards with lpddr4 float outside the mainline
support
because many developers are using the boards, they can only use vendor
branch
if the board not support by mainline.
So I think merge those patches already make board work on mainline U-Boot
is pretty important for open source community.
Thanks,
- Kever
> Frankly, I don't think that would help. It would just drive more
> people to the vendor U-Boot that has more bugs and includes a vendor
> supplied ATF binary.
>
>>> I'm not sure if you have write a new dram driver for a board, but I know
>>> even the board vendor may not have the capability to write the DRAM
>>> driver, so this should not stop developers contribute to all other 99%
>>> features on U-Boot.
>> What they can do is run the non-free blob, dump the registers
>> afterwards and then use that in the DRAM configuration dtsi. Perhaps
>> one could write up a tool to ease the process if they think the process
>> is too much for a regular bringup.
>>
>> Most of the time, the DRAM chips are soldered so the calibrated values
>> have about no reason to change over time and can just be kept as-is.
>>
>> What do you think?
> Hopefully the pending diff to add support for other DRAM types beyond
> those that are already supported would make bring us a long way in
> that direction. Maybe one of the existing timings will already work
> for the boards that are being discussed here.
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-19 1:42 ` Kever Yang
@ 2019-06-19 16:54 ` Paul Kocialkowski
-1 siblings, 0 replies; 43+ messages in thread
From: Paul Kocialkowski @ 2019-06-19 16:54 UTC (permalink / raw)
To: Kever Yang, Mark Kettenis
Cc: linux-rockchip, Maxime Ripard, u-boot, nick, linux-amarula, xieqinick
Hi Kever,
Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
> Hi Paul,
>
>
> On 06/19/2019 12:12 AM, Mark Kettenis wrote:
> > > From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > > Date: Tue, 18 Jun 2019 14:47:33 +0200
> > >
> > > Hi Kever,
> > >
> > > On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> > > > Hi Paul,
> > > >
> > > >
> > > > On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > > > > Hi,
> > > > >
> > > > > On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > > > > On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Mon, 2019-06-17 at 15:24 +0800, xieqinick@gmail.com wrote:
> > > > > > > > From: Nick Xie <nick@khadas.com>
> > > > > > > Was this tested with SPL support? I don't see DRAM configuration here
> > > > > > > so it seems that it relies on the non-free rockchip loader.
> > > > > > >
> > > > > > > If that is the case, could you please indicate that in the commit
> > > > > > > message?
> > > > > > >
> > > > > > > To maintainers: please do not merge this series before DRAM init and
> > > > > > > SPL support is available for these boards.
> > > > > > >
> > > > > > > It seems that other RK3399 boards were merged without SPL support and
> > > > > > > sofar, I have the feeling that nobody cared to explain how we got into
> > > > > > > this broken situation. Please don't merge any more such board.
> > > > > > fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > > > > > with TPL-enabled (which was discussed on the threads, if you remember)
> > > > > > with below boot chain.
> > > > > >
> > > > > > rkbin (TPL) -> SPL -> U-Boot proper
> > > > > >
> > > > > > Same case for this board as well.
> > > > > Here is a quote from Philipp Tomsich on the thread we discussed this:
> > > > >
> > > > > " On some boards, there will be no TPL and only a SPL stage that will
> > > > > initialise DRAM (as the move to having TPL on the RK3399 is optional).
> > > > >
> > > > > I agree with Paul that the DRAM init should be part of U-Boot whenever
> > > > > we add new boards and make an open DRAM init a prerequisite. "
> > > > >
> > > > > So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > > > > that no board should be merged without proper DRAM init.
> > > > >
> > > > > Please stop pushing for merging these boards. I'm not sure what we
> > > > > should do about the boards that were merged already without DRAM init,
> > > > > but maybe they should be reverted.
> > > > I don't think we have to have full DRAM init source code for each
> > > > board before we can merge it, I believe most of the board on U-Boot
> > > > mainline need to removed due to this rule. There are so many boards
> > > > from different vendor need a binary loader before U-Boot, and I can
> > > > see only very few drivers for dram at driver/ram/, and I believe rockchip
> > > > is already the most open vendor on this area.
> > > Well, I am not talking about full DRAM init source code as in dynamic
> > > link training. I am talking about having at least static DRAM register
> > > configuration values,
>
> I can tell you that this is no work for all the boards, you can see how
> rockchip lpddr4(WIP, send by Jagan) driver works.
I thought that LPDDR4 works the same as other types of DRAM where we
have a dtsi array with timings configuration. Of course, some more
registers need to be set up, but we already have support for that or
it's quite close (for LPDDR4).
> > > which is present for a good number of rockchip
> > > boards.
>
> No, there is no rockchip board only have static DRAM register
> configuration values, that maybe happens in other vendor.
I was implying that, as far as I know, it is the case for DRAM timings
on Rockchip as well as most of the platforms that I know of. In the
end, any code handling DRAM will end up writing timings to the
controller's registers. If the DRAM is part of the PCB and doesn't
change/move, then the timings don't change in particular.
Is there something specific about Rockchip that makes it require
different DRAM timings at each boot?
> > > Of course, it would be best if Rockchip would consider releasing this
> > > source code,
>
> Rockchip already release all the DRAM init source code, including DDR3 ,
> LPDDR3,
> and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
> everything,
> which is not only static register configuration.
> As I have said, rockchip is already the most open vendor in this area
> till now, I don't know
> if you have working on rockchip SoC based boards.
You are quite right about that, but I was thinking about the code to
calculate DRAM timings (with link-training and such) which is often not
available as free software, and I am not aware of Rockchip having
released that code (but feel free to correct me if I'm wrong).
> > > which would be the easiest and friendliest solution
> > > towards the community here. Are there internal discussions ongoing
> > > about this? If not, it would be greatly appreciated to start such
> > > discussions and clearly identify what the blocking points are.
> > >
> > > > I won't use this rule to stop developers contribute there source code,
> > > This is really sad and I think that Philipp was, like me, inclined to
> > > go towards the other direction.
> > >
> > > > for a board support, we only need the board to have the full documentation
> > > > about how to setup and boot with upstream U-Boot. and I think the
> > > > most of people cares more about features in U-Boot proper. Everything
> > > > before U-Boot proper, you can use TPL/SPL or alternative to use binary
> > > > from vendor, as you can see all over the U-Boot mainline now, although
> > > > we encourage people to use full open source TPL/SPL.
> > > > Specifically for U-Boot Rockchip platform, I would like people to
> > > > support not only U-Boot
> > > > proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> > > > features)
> > > > support. And for DRAM init,
> > > > - if this belongs to SPL for this board, you must implement it or else
> > > > SPL won't work;
> > > > - if this does not belong to SPL for this board, you need implement full
> > > > function SPL;
> > > > and you can either to have full function TPL with DRAM init(which is
> > > > prefered)
> > > > or alternatively use binary loader from vendor.
> > > This is not really a technical argument here, more of a policy argument
> > > that ensures we have full free software support for the boards we
> > > support, and not only half-cooked support (that will most likely never
> > > be completed as soon as something that works gets merged). So it is a
> > > strategical decision, not a strictly pragmatic one.
> > While having full open source software support for boards is a noble
> > goal, I think there should be some room for pragmatism here. A
> > significant number of u_boot targets rely on closed source components.
> > In the particular case of RK3399 the situation is better than for
> > other boards since you can combine the binary loader from the vendor
> > with mainline U-Boot and mainline ATF to create a firmware where (as
> > far as we can tell) no closed soure component remains active after
> > U-Boot and ATF take over control.
> >
> > > I think reverting patches adding support for boards with no DRAM
> > > configuration at all would send a message in the right direction here.
> As a developer, I agree on this, but as a maintainer, I know too many
> developers not able to do it and what most of developers need is other
> features in U-Boot or SPL, and I would like the U-Boot mainline is more
> active with more and more developers. So I'm afraid I agree with Mark
> at this time for the policy.
Maybe we need to provide tools ot make that process easier for everyone
if it is really that hard. I don't really see what is so special about
DRAM timings that would imply that a regular developer doing a U-Boot
bringup couldn't figure things out, aside from the ability to dump said
timings.
> If all the other SoC platforms can have the same rule for DRAM init driver
> is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
> imx, aml, and all others, then I would very happy to follow the rule.
> Rockchip is open for open source the DRAM driver, you have to know this
> is the decision by the vendor, but not any of developers.
> On rockchip platform, developers no need to concern about the DRAM
> driver(which is pretty hard for most developers) because rockchip
> already contribute it.
Rockchip is indeed in a better position than other vendors where DRAM
init may not be available (or when it's impossible to run U-Boot right
after the bootrom and do the DRAM init itself because of e.g. abusive
signature verification or lack of documentation).
Since there is good DRAM support for Rockchip in place, we have an
opportunity to push developers to do the right thing and contribute
full support for the board. To me it is simply a matter of
acknowledging that bootloader support for a board without DRAM init is
not useful bootloader support. Since we have the code in place to
support that, we can take the extra step and require that each board
contribution be useful in that aspect.
> For the time now, I know there will be full DRAM driver for rockchip SoC,
> so the SoC/board support could be step by step:
> U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
>
> As you can see the rockchip LPDDR4 driver send by Jagan, has 99 patches
> in V2, you can't use static register configuration to do this, and maybe you
> can't have a workable version if rockchip don't release it, but I don't
> think it's
> correct to make all those boards with lpddr4 float outside the mainline
> support
> because many developers are using the boards, they can only use vendor
> branch
> if the board not support by mainline.
If mainline U-Boot can't support basic bootloader features such as DRAM
initialization for these boards, I don't see the point in accepting
support for them.
It would be like submitting support for a board in Linux with a new CPU
that is not supported and asking to boot Linux via a non-free shim
before Linux to put the CPU in a legacy state that Linux can support.
This would definitely not be okay and I don't see why the same
shouldn't apply to U-Boot.
> So I think merge those patches already make board work on mainline U-Boot
> is pretty important for open source community.
I don't think the patches make the boards work on mainline U-Boot since
building and installing the resulting U-Boot binaries will result in a
non-functional boot chain and brick the device. I don't think this is a
good or safe idea.
Cheers,
Paul
> Thanks,
> - Kever
> > Frankly, I don't think that would help. It would just drive more
> > people to the vendor U-Boot that has more bugs and includes a vendor
> > supplied ATF binary.
> >
> > > > I'm not sure if you have write a new dram driver for a board, but I know
> > > > even the board vendor may not have the capability to write the DRAM
> > > > driver, so this should not stop developers contribute to all other 99%
> > > > features on U-Boot.
> > > What they can do is run the non-free blob, dump the registers
> > > afterwards and then use that in the DRAM configuration dtsi. Perhaps
> > > one could write up a tool to ease the process if they think the process
> > > is too much for a regular bringup.
> > >
> > > Most of the time, the DRAM chips are soldered so the calibrated values
> > > have about no reason to change over time and can just be kept as-is.
> > >
> > > What do you think?
> > Hopefully the pending diff to add support for other DRAM types beyond
> > those that are already supported would make bring us a long way in
> > that direction. Maybe one of the existing timings will already work
> > for the boards that are being discussed here.
> >
>
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-19 16:54 ` Paul Kocialkowski
0 siblings, 0 replies; 43+ messages in thread
From: Paul Kocialkowski @ 2019-06-19 16:54 UTC (permalink / raw)
To: u-boot
Hi Kever,
Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
> Hi Paul,
>
>
> On 06/19/2019 12:12 AM, Mark Kettenis wrote:
> > > From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > > Date: Tue, 18 Jun 2019 14:47:33 +0200
> > >
> > > Hi Kever,
> > >
> > > On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> > > > Hi Paul,
> > > >
> > > >
> > > > On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > > > > Hi,
> > > > >
> > > > > On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > > > > On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Mon, 2019-06-17 at 15:24 +0800, xieqinick at gmail.com wrote:
> > > > > > > > From: Nick Xie <nick@khadas.com>
> > > > > > > Was this tested with SPL support? I don't see DRAM configuration here
> > > > > > > so it seems that it relies on the non-free rockchip loader.
> > > > > > >
> > > > > > > If that is the case, could you please indicate that in the commit
> > > > > > > message?
> > > > > > >
> > > > > > > To maintainers: please do not merge this series before DRAM init and
> > > > > > > SPL support is available for these boards.
> > > > > > >
> > > > > > > It seems that other RK3399 boards were merged without SPL support and
> > > > > > > sofar, I have the feeling that nobody cared to explain how we got into
> > > > > > > this broken situation. Please don't merge any more such board.
> > > > > > fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > > > > > with TPL-enabled (which was discussed on the threads, if you remember)
> > > > > > with below boot chain.
> > > > > >
> > > > > > rkbin (TPL) -> SPL -> U-Boot proper
> > > > > >
> > > > > > Same case for this board as well.
> > > > > Here is a quote from Philipp Tomsich on the thread we discussed this:
> > > > >
> > > > > " On some boards, there will be no TPL and only a SPL stage that will
> > > > > initialise DRAM (as the move to having TPL on the RK3399 is optional).
> > > > >
> > > > > I agree with Paul that the DRAM init should be part of U-Boot whenever
> > > > > we add new boards and make an open DRAM init a prerequisite. "
> > > > >
> > > > > So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > > > > that no board should be merged without proper DRAM init.
> > > > >
> > > > > Please stop pushing for merging these boards. I'm not sure what we
> > > > > should do about the boards that were merged already without DRAM init,
> > > > > but maybe they should be reverted.
> > > > I don't think we have to have full DRAM init source code for each
> > > > board before we can merge it, I believe most of the board on U-Boot
> > > > mainline need to removed due to this rule. There are so many boards
> > > > from different vendor need a binary loader before U-Boot, and I can
> > > > see only very few drivers for dram at driver/ram/, and I believe rockchip
> > > > is already the most open vendor on this area.
> > > Well, I am not talking about full DRAM init source code as in dynamic
> > > link training. I am talking about having at least static DRAM register
> > > configuration values,
>
> I can tell you that this is no work for all the boards, you can see how
> rockchip lpddr4(WIP, send by Jagan) driver works.
I thought that LPDDR4 works the same as other types of DRAM where we
have a dtsi array with timings configuration. Of course, some more
registers need to be set up, but we already have support for that or
it's quite close (for LPDDR4).
> > > which is present for a good number of rockchip
> > > boards.
>
> No, there is no rockchip board only have static DRAM register
> configuration values, that maybe happens in other vendor.
I was implying that, as far as I know, it is the case for DRAM timings
on Rockchip as well as most of the platforms that I know of. In the
end, any code handling DRAM will end up writing timings to the
controller's registers. If the DRAM is part of the PCB and doesn't
change/move, then the timings don't change in particular.
Is there something specific about Rockchip that makes it require
different DRAM timings at each boot?
> > > Of course, it would be best if Rockchip would consider releasing this
> > > source code,
>
> Rockchip already release all the DRAM init source code, including DDR3 ,
> LPDDR3,
> and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
> everything,
> which is not only static register configuration.
> As I have said, rockchip is already the most open vendor in this area
> till now, I don't know
> if you have working on rockchip SoC based boards.
You are quite right about that, but I was thinking about the code to
calculate DRAM timings (with link-training and such) which is often not
available as free software, and I am not aware of Rockchip having
released that code (but feel free to correct me if I'm wrong).
> > > which would be the easiest and friendliest solution
> > > towards the community here. Are there internal discussions ongoing
> > > about this? If not, it would be greatly appreciated to start such
> > > discussions and clearly identify what the blocking points are.
> > >
> > > > I won't use this rule to stop developers contribute there source code,
> > > This is really sad and I think that Philipp was, like me, inclined to
> > > go towards the other direction.
> > >
> > > > for a board support, we only need the board to have the full documentation
> > > > about how to setup and boot with upstream U-Boot. and I think the
> > > > most of people cares more about features in U-Boot proper. Everything
> > > > before U-Boot proper, you can use TPL/SPL or alternative to use binary
> > > > from vendor, as you can see all over the U-Boot mainline now, although
> > > > we encourage people to use full open source TPL/SPL.
> > > > Specifically for U-Boot Rockchip platform, I would like people to
> > > > support not only U-Boot
> > > > proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> > > > features)
> > > > support. And for DRAM init,
> > > > - if this belongs to SPL for this board, you must implement it or else
> > > > SPL won't work;
> > > > - if this does not belong to SPL for this board, you need implement full
> > > > function SPL;
> > > > and you can either to have full function TPL with DRAM init(which is
> > > > prefered)
> > > > or alternatively use binary loader from vendor.
> > > This is not really a technical argument here, more of a policy argument
> > > that ensures we have full free software support for the boards we
> > > support, and not only half-cooked support (that will most likely never
> > > be completed as soon as something that works gets merged). So it is a
> > > strategical decision, not a strictly pragmatic one.
> > While having full open source software support for boards is a noble
> > goal, I think there should be some room for pragmatism here. A
> > significant number of u_boot targets rely on closed source components.
> > In the particular case of RK3399 the situation is better than for
> > other boards since you can combine the binary loader from the vendor
> > with mainline U-Boot and mainline ATF to create a firmware where (as
> > far as we can tell) no closed soure component remains active after
> > U-Boot and ATF take over control.
> >
> > > I think reverting patches adding support for boards with no DRAM
> > > configuration at all would send a message in the right direction here.
> As a developer, I agree on this, but as a maintainer, I know too many
> developers not able to do it and what most of developers need is other
> features in U-Boot or SPL, and I would like the U-Boot mainline is more
> active with more and more developers. So I'm afraid I agree with Mark
> at this time for the policy.
Maybe we need to provide tools ot make that process easier for everyone
if it is really that hard. I don't really see what is so special about
DRAM timings that would imply that a regular developer doing a U-Boot
bringup couldn't figure things out, aside from the ability to dump said
timings.
> If all the other SoC platforms can have the same rule for DRAM init driver
> is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
> imx, aml, and all others, then I would very happy to follow the rule.
> Rockchip is open for open source the DRAM driver, you have to know this
> is the decision by the vendor, but not any of developers.
> On rockchip platform, developers no need to concern about the DRAM
> driver(which is pretty hard for most developers) because rockchip
> already contribute it.
Rockchip is indeed in a better position than other vendors where DRAM
init may not be available (or when it's impossible to run U-Boot right
after the bootrom and do the DRAM init itself because of e.g. abusive
signature verification or lack of documentation).
Since there is good DRAM support for Rockchip in place, we have an
opportunity to push developers to do the right thing and contribute
full support for the board. To me it is simply a matter of
acknowledging that bootloader support for a board without DRAM init is
not useful bootloader support. Since we have the code in place to
support that, we can take the extra step and require that each board
contribution be useful in that aspect.
> For the time now, I know there will be full DRAM driver for rockchip SoC,
> so the SoC/board support could be step by step:
> U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
>
> As you can see the rockchip LPDDR4 driver send by Jagan, has 99 patches
> in V2, you can't use static register configuration to do this, and maybe you
> can't have a workable version if rockchip don't release it, but I don't
> think it's
> correct to make all those boards with lpddr4 float outside the mainline
> support
> because many developers are using the boards, they can only use vendor
> branch
> if the board not support by mainline.
If mainline U-Boot can't support basic bootloader features such as DRAM
initialization for these boards, I don't see the point in accepting
support for them.
It would be like submitting support for a board in Linux with a new CPU
that is not supported and asking to boot Linux via a non-free shim
before Linux to put the CPU in a legacy state that Linux can support.
This would definitely not be okay and I don't see why the same
shouldn't apply to U-Boot.
> So I think merge those patches already make board work on mainline U-Boot
> is pretty important for open source community.
I don't think the patches make the boards work on mainline U-Boot since
building and installing the resulting U-Boot binaries will result in a
non-functional boot chain and brick the device. I don't think this is a
good or safe idea.
Cheers,
Paul
> Thanks,
> - Kever
> > Frankly, I don't think that would help. It would just drive more
> > people to the vendor U-Boot that has more bugs and includes a vendor
> > supplied ATF binary.
> >
> > > > I'm not sure if you have write a new dram driver for a board, but I know
> > > > even the board vendor may not have the capability to write the DRAM
> > > > driver, so this should not stop developers contribute to all other 99%
> > > > features on U-Boot.
> > > What they can do is run the non-free blob, dump the registers
> > > afterwards and then use that in the DRAM configuration dtsi. Perhaps
> > > one could write up a tool to ease the process if they think the process
> > > is too much for a regular bringup.
> > >
> > > Most of the time, the DRAM chips are soldered so the calibrated values
> > > have about no reason to change over time and can just be kept as-is.
> > >
> > > What do you think?
> > Hopefully the pending diff to add support for other DRAM types beyond
> > those that are already supported would make bring us a long way in
> > that direction. Maybe one of the existing timings will already work
> > for the boards that are being discussed here.
> >
>
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-19 16:54 ` [U-Boot] " Paul Kocialkowski
@ 2019-06-20 3:24 ` Kever Yang
-1 siblings, 0 replies; 43+ messages in thread
From: Kever Yang @ 2019-06-20 3:24 UTC (permalink / raw)
To: Paul Kocialkowski, Mark Kettenis
Cc: linux-rockchip, Maxime Ripard, u-boot, nick, linux-amarula, xieqinick
Hi Paul,
On 06/20/2019 12:54 AM, Paul Kocialkowski wrote:
> Hi Kever,
>
> Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
>> Hi Paul,
>>
>>
>> On 06/19/2019 12:12 AM, Mark Kettenis wrote:
>>>> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>>>> Date: Tue, 18 Jun 2019 14:47:33 +0200
>>>>
>>>> Hi Kever,
>>>>
>>>> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
>>>>> Hi Paul,
>>>>>
>>>>>
>>>>> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
>>>>>>> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
>>>>>>> <paul.kocialkowski@bootlin.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Mon, 2019-06-17 at 15:24 +0800, xieqinick@gmail.com wrote:
>>>>>>>>> From: Nick Xie <nick@khadas.com>
>>>>>>>> Was this tested with SPL support? I don't see DRAM configuration here
>>>>>>>> so it seems that it relies on the non-free rockchip loader.
>>>>>>>>
>>>>>>>> If that is the case, could you please indicate that in the commit
>>>>>>>> message?
>>>>>>>>
>>>>>>>> To maintainers: please do not merge this series before DRAM init and
>>>>>>>> SPL support is available for these boards.
>>>>>>>>
>>>>>>>> It seems that other RK3399 boards were merged without SPL support and
>>>>>>>> sofar, I have the feeling that nobody cared to explain how we got into
>>>>>>>> this broken situation. Please don't merge any more such board.
>>>>>>> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
>>>>>>> with TPL-enabled (which was discussed on the threads, if you remember)
>>>>>>> with below boot chain.
>>>>>>>
>>>>>>> rkbin (TPL) -> SPL -> U-Boot proper
>>>>>>>
>>>>>>> Same case for this board as well.
>>>>>> Here is a quote from Philipp Tomsich on the thread we discussed this:
>>>>>>
>>>>>> " On some boards, there will be no TPL and only a SPL stage that will
>>>>>> initialise DRAM (as the move to having TPL on the RK3399 is optional).
>>>>>>
>>>>>> I agree with Paul that the DRAM init should be part of U-Boot whenever
>>>>>> we add new boards and make an open DRAM init a prerequisite. "
>>>>>>
>>>>>> So even if I frequently confuse SPL and TPL, it doesn't change the fact
>>>>>> that no board should be merged without proper DRAM init.
>>>>>>
>>>>>> Please stop pushing for merging these boards. I'm not sure what we
>>>>>> should do about the boards that were merged already without DRAM init,
>>>>>> but maybe they should be reverted.
>>>>> I don't think we have to have full DRAM init source code for each
>>>>> board before we can merge it, I believe most of the board on U-Boot
>>>>> mainline need to removed due to this rule. There are so many boards
>>>>> from different vendor need a binary loader before U-Boot, and I can
>>>>> see only very few drivers for dram at driver/ram/, and I believe rockchip
>>>>> is already the most open vendor on this area.
>>>> Well, I am not talking about full DRAM init source code as in dynamic
>>>> link training. I am talking about having at least static DRAM register
>>>> configuration values,
>> I can tell you that this is no work for all the boards, you can see how
>> rockchip lpddr4(WIP, send by Jagan) driver works.
> I thought that LPDDR4 works the same as other types of DRAM where we
> have a dtsi array with timings configuration. Of course, some more
> registers need to be set up, but we already have support for that or
> it's quite close (for LPDDR4).
>
>>>> which is present for a good number of rockchip
>>>> boards.
>> No, there is no rockchip board only have static DRAM register
>> configuration values, that maybe happens in other vendor.
> I was implying that, as far as I know, it is the case for DRAM timings
> on Rockchip as well as most of the platforms that I know of. In the
> end, any code handling DRAM will end up writing timings to the
> controller's registers. If the DRAM is part of the PCB and doesn't
> change/move, then the timings don't change in particular.
>
> Is there something specific about Rockchip that makes it require
> different DRAM timings at each boot?
>
>>>> Of course, it would be best if Rockchip would consider releasing this
>>>> source code,
>> Rockchip already release all the DRAM init source code, including DDR3 ,
>> LPDDR3,
>> and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
>> everything,
>> which is not only static register configuration.
>> As I have said, rockchip is already the most open vendor in this area
>> till now, I don't know
>> if you have working on rockchip SoC based boards.
> You are quite right about that, but I was thinking about the code to
> calculate DRAM timings (with link-training and such) which is often not
> available as free software, and I am not aware of Rockchip having
> released that code (but feel free to correct me if I'm wrong).
>
>>>> which would be the easiest and friendliest solution
>>>> towards the community here. Are there internal discussions ongoing
>>>> about this? If not, it would be greatly appreciated to start such
>>>> discussions and clearly identify what the blocking points are.
>>>>
>>>>> I won't use this rule to stop developers contribute there source code,
>>>> This is really sad and I think that Philipp was, like me, inclined to
>>>> go towards the other direction.
>>>>
>>>>> for a board support, we only need the board to have the full documentation
>>>>> about how to setup and boot with upstream U-Boot. and I think the
>>>>> most of people cares more about features in U-Boot proper. Everything
>>>>> before U-Boot proper, you can use TPL/SPL or alternative to use binary
>>>>> from vendor, as you can see all over the U-Boot mainline now, although
>>>>> we encourage people to use full open source TPL/SPL.
>>>>> Specifically for U-Boot Rockchip platform, I would like people to
>>>>> support not only U-Boot
>>>>> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
>>>>> features)
>>>>> support. And for DRAM init,
>>>>> - if this belongs to SPL for this board, you must implement it or else
>>>>> SPL won't work;
>>>>> - if this does not belong to SPL for this board, you need implement full
>>>>> function SPL;
>>>>> and you can either to have full function TPL with DRAM init(which is
>>>>> prefered)
>>>>> or alternatively use binary loader from vendor.
>>>> This is not really a technical argument here, more of a policy argument
>>>> that ensures we have full free software support for the boards we
>>>> support, and not only half-cooked support (that will most likely never
>>>> be completed as soon as something that works gets merged). So it is a
>>>> strategical decision, not a strictly pragmatic one.
>>> While having full open source software support for boards is a noble
>>> goal, I think there should be some room for pragmatism here. A
>>> significant number of u_boot targets rely on closed source components.
>>> In the particular case of RK3399 the situation is better than for
>>> other boards since you can combine the binary loader from the vendor
>>> with mainline U-Boot and mainline ATF to create a firmware where (as
>>> far as we can tell) no closed soure component remains active after
>>> U-Boot and ATF take over control.
>>>
>>>> I think reverting patches adding support for boards with no DRAM
>>>> configuration at all would send a message in the right direction here.
>> As a developer, I agree on this, but as a maintainer, I know too many
>> developers not able to do it and what most of developers need is other
>> features in U-Boot or SPL, and I would like the U-Boot mainline is more
>> active with more and more developers. So I'm afraid I agree with Mark
>> at this time for the policy.
> Maybe we need to provide tools ot make that process easier for everyone
> if it is really that hard. I don't really see what is so special about
> DRAM timings that would imply that a regular developer doing a U-Boot
> bringup couldn't figure things out, aside from the ability to dump said
> timings.
>
>> If all the other SoC platforms can have the same rule for DRAM init driver
>> is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
>> imx, aml, and all others, then I would very happy to follow the rule.
>> Rockchip is open for open source the DRAM driver, you have to know this
>> is the decision by the vendor, but not any of developers.
>> On rockchip platform, developers no need to concern about the DRAM
>> driver(which is pretty hard for most developers) because rockchip
>> already contribute it.
> Rockchip is indeed in a better position than other vendors where DRAM
> init may not be available (or when it's impossible to run U-Boot right
> after the bootrom and do the DRAM init itself because of e.g. abusive
> signature verification or lack of documentation).
>
> Since there is good DRAM support for Rockchip in place, we have an
> opportunity to push developers to do the right thing and contribute
> full support for the board. To me it is simply a matter of
> acknowledging that bootloader support for a board without DRAM init is
> not useful bootloader support. Since we have the code in place to
> support that, we can take the extra step and require that each board
> contribution be useful in that aspect.
>
>> For the time now, I know there will be full DRAM driver for rockchip SoC,
>> so the SoC/board support could be step by step:
>> U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
>>
>> As you can see the rockchip LPDDR4 driver send by Jagan, has 99 patches
>> in V2, you can't use static register configuration to do this, and maybe you
>> can't have a workable version if rockchip don't release it, but I don't
>> think it's
>> correct to make all those boards with lpddr4 float outside the mainline
>> support
>> because many developers are using the boards, they can only use vendor
>> branch
>> if the board not support by mainline.
> If mainline U-Boot can't support basic bootloader features such as DRAM
> initialization for these boards, I don't see the point in accepting
> support for them.
>
> It would be like submitting support for a board in Linux with a new CPU
> that is not supported and asking to boot Linux via a non-free shim
> before Linux to put the CPU in a legacy state that Linux can support.
> This would definitely not be okay and I don't see why the same
> shouldn't apply to U-Boot.
Linux build target is Image/zImage, if this Image not work with the board,
eg. hang somewhere during boot, then we say the board support is broken
and result in non-functional boot. And there always some kernel features
depends on bootloader setting, including security setting, some clock init,
some power supply and etc.
>
>> So I think merge those patches already make board work on mainline U-Boot
>> is pretty important for open source community.
> I don't think the patches make the boards work on mainline U-Boot since
> building and installing the resulting U-Boot binaries will result in a
> non-functional boot chain and brick the device. I don't think this is a
> good or safe idea.
In U-Boot, there are 2 or 3 standalone subsystem: U-Boot proper,
SPL, and TPL, and build target is u-boot.bin, u-boot-spl.bin, and
u-boot-tpl.bin.
If the standalone u-boot.bin or u-boot-spl.bin works good with a board and
able to boot into next stage correctly, I don't think these patches can
be consider
as "non-functional boot chain and brick the device". And for example for
armv8,
U-Boot is always as part of the boot chain.
Thanks,
- Kever
>
> Cheers,
>
> Paul
>
>> Thanks,
>> - Kever
>>> Frankly, I don't think that would help. It would just drive more
>>> people to the vendor U-Boot that has more bugs and includes a vendor
>>> supplied ATF binary.
>>>
>>>>> I'm not sure if you have write a new dram driver for a board, but I know
>>>>> even the board vendor may not have the capability to write the DRAM
>>>>> driver, so this should not stop developers contribute to all other 99%
>>>>> features on U-Boot.
>>>> What they can do is run the non-free blob, dump the registers
>>>> afterwards and then use that in the DRAM configuration dtsi. Perhaps
>>>> one could write up a tool to ease the process if they think the process
>>>> is too much for a regular bringup.
>>>>
>>>> Most of the time, the DRAM chips are soldered so the calibrated values
>>>> have about no reason to change over time and can just be kept as-is.
>>>>
>>>> What do you think?
>>> Hopefully the pending diff to add support for other DRAM types beyond
>>> those that are already supported would make bring us a long way in
>>> that direction. Maybe one of the existing timings will already work
>>> for the boards that are being discussed here.
>>>
>>
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-20 3:24 ` Kever Yang
0 siblings, 0 replies; 43+ messages in thread
From: Kever Yang @ 2019-06-20 3:24 UTC (permalink / raw)
To: u-boot
Hi Paul,
On 06/20/2019 12:54 AM, Paul Kocialkowski wrote:
> Hi Kever,
>
> Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
>> Hi Paul,
>>
>>
>> On 06/19/2019 12:12 AM, Mark Kettenis wrote:
>>>> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>>>> Date: Tue, 18 Jun 2019 14:47:33 +0200
>>>>
>>>> Hi Kever,
>>>>
>>>> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
>>>>> Hi Paul,
>>>>>
>>>>>
>>>>> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
>>>>>>> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
>>>>>>> <paul.kocialkowski@bootlin.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Mon, 2019-06-17 at 15:24 +0800, xieqinick at gmail.com wrote:
>>>>>>>>> From: Nick Xie <nick@khadas.com>
>>>>>>>> Was this tested with SPL support? I don't see DRAM configuration here
>>>>>>>> so it seems that it relies on the non-free rockchip loader.
>>>>>>>>
>>>>>>>> If that is the case, could you please indicate that in the commit
>>>>>>>> message?
>>>>>>>>
>>>>>>>> To maintainers: please do not merge this series before DRAM init and
>>>>>>>> SPL support is available for these boards.
>>>>>>>>
>>>>>>>> It seems that other RK3399 boards were merged without SPL support and
>>>>>>>> sofar, I have the feeling that nobody cared to explain how we got into
>>>>>>>> this broken situation. Please don't merge any more such board.
>>>>>>> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
>>>>>>> with TPL-enabled (which was discussed on the threads, if you remember)
>>>>>>> with below boot chain.
>>>>>>>
>>>>>>> rkbin (TPL) -> SPL -> U-Boot proper
>>>>>>>
>>>>>>> Same case for this board as well.
>>>>>> Here is a quote from Philipp Tomsich on the thread we discussed this:
>>>>>>
>>>>>> " On some boards, there will be no TPL and only a SPL stage that will
>>>>>> initialise DRAM (as the move to having TPL on the RK3399 is optional).
>>>>>>
>>>>>> I agree with Paul that the DRAM init should be part of U-Boot whenever
>>>>>> we add new boards and make an open DRAM init a prerequisite. "
>>>>>>
>>>>>> So even if I frequently confuse SPL and TPL, it doesn't change the fact
>>>>>> that no board should be merged without proper DRAM init.
>>>>>>
>>>>>> Please stop pushing for merging these boards. I'm not sure what we
>>>>>> should do about the boards that were merged already without DRAM init,
>>>>>> but maybe they should be reverted.
>>>>> I don't think we have to have full DRAM init source code for each
>>>>> board before we can merge it, I believe most of the board on U-Boot
>>>>> mainline need to removed due to this rule. There are so many boards
>>>>> from different vendor need a binary loader before U-Boot, and I can
>>>>> see only very few drivers for dram at driver/ram/, and I believe rockchip
>>>>> is already the most open vendor on this area.
>>>> Well, I am not talking about full DRAM init source code as in dynamic
>>>> link training. I am talking about having at least static DRAM register
>>>> configuration values,
>> I can tell you that this is no work for all the boards, you can see how
>> rockchip lpddr4(WIP, send by Jagan) driver works.
> I thought that LPDDR4 works the same as other types of DRAM where we
> have a dtsi array with timings configuration. Of course, some more
> registers need to be set up, but we already have support for that or
> it's quite close (for LPDDR4).
>
>>>> which is present for a good number of rockchip
>>>> boards.
>> No, there is no rockchip board only have static DRAM register
>> configuration values, that maybe happens in other vendor.
> I was implying that, as far as I know, it is the case for DRAM timings
> on Rockchip as well as most of the platforms that I know of. In the
> end, any code handling DRAM will end up writing timings to the
> controller's registers. If the DRAM is part of the PCB and doesn't
> change/move, then the timings don't change in particular.
>
> Is there something specific about Rockchip that makes it require
> different DRAM timings at each boot?
>
>>>> Of course, it would be best if Rockchip would consider releasing this
>>>> source code,
>> Rockchip already release all the DRAM init source code, including DDR3 ,
>> LPDDR3,
>> and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
>> everything,
>> which is not only static register configuration.
>> As I have said, rockchip is already the most open vendor in this area
>> till now, I don't know
>> if you have working on rockchip SoC based boards.
> You are quite right about that, but I was thinking about the code to
> calculate DRAM timings (with link-training and such) which is often not
> available as free software, and I am not aware of Rockchip having
> released that code (but feel free to correct me if I'm wrong).
>
>>>> which would be the easiest and friendliest solution
>>>> towards the community here. Are there internal discussions ongoing
>>>> about this? If not, it would be greatly appreciated to start such
>>>> discussions and clearly identify what the blocking points are.
>>>>
>>>>> I won't use this rule to stop developers contribute there source code,
>>>> This is really sad and I think that Philipp was, like me, inclined to
>>>> go towards the other direction.
>>>>
>>>>> for a board support, we only need the board to have the full documentation
>>>>> about how to setup and boot with upstream U-Boot. and I think the
>>>>> most of people cares more about features in U-Boot proper. Everything
>>>>> before U-Boot proper, you can use TPL/SPL or alternative to use binary
>>>>> from vendor, as you can see all over the U-Boot mainline now, although
>>>>> we encourage people to use full open source TPL/SPL.
>>>>> Specifically for U-Boot Rockchip platform, I would like people to
>>>>> support not only U-Boot
>>>>> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
>>>>> features)
>>>>> support. And for DRAM init,
>>>>> - if this belongs to SPL for this board, you must implement it or else
>>>>> SPL won't work;
>>>>> - if this does not belong to SPL for this board, you need implement full
>>>>> function SPL;
>>>>> and you can either to have full function TPL with DRAM init(which is
>>>>> prefered)
>>>>> or alternatively use binary loader from vendor.
>>>> This is not really a technical argument here, more of a policy argument
>>>> that ensures we have full free software support for the boards we
>>>> support, and not only half-cooked support (that will most likely never
>>>> be completed as soon as something that works gets merged). So it is a
>>>> strategical decision, not a strictly pragmatic one.
>>> While having full open source software support for boards is a noble
>>> goal, I think there should be some room for pragmatism here. A
>>> significant number of u_boot targets rely on closed source components.
>>> In the particular case of RK3399 the situation is better than for
>>> other boards since you can combine the binary loader from the vendor
>>> with mainline U-Boot and mainline ATF to create a firmware where (as
>>> far as we can tell) no closed soure component remains active after
>>> U-Boot and ATF take over control.
>>>
>>>> I think reverting patches adding support for boards with no DRAM
>>>> configuration at all would send a message in the right direction here.
>> As a developer, I agree on this, but as a maintainer, I know too many
>> developers not able to do it and what most of developers need is other
>> features in U-Boot or SPL, and I would like the U-Boot mainline is more
>> active with more and more developers. So I'm afraid I agree with Mark
>> at this time for the policy.
> Maybe we need to provide tools ot make that process easier for everyone
> if it is really that hard. I don't really see what is so special about
> DRAM timings that would imply that a regular developer doing a U-Boot
> bringup couldn't figure things out, aside from the ability to dump said
> timings.
>
>> If all the other SoC platforms can have the same rule for DRAM init driver
>> is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
>> imx, aml, and all others, then I would very happy to follow the rule.
>> Rockchip is open for open source the DRAM driver, you have to know this
>> is the decision by the vendor, but not any of developers.
>> On rockchip platform, developers no need to concern about the DRAM
>> driver(which is pretty hard for most developers) because rockchip
>> already contribute it.
> Rockchip is indeed in a better position than other vendors where DRAM
> init may not be available (or when it's impossible to run U-Boot right
> after the bootrom and do the DRAM init itself because of e.g. abusive
> signature verification or lack of documentation).
>
> Since there is good DRAM support for Rockchip in place, we have an
> opportunity to push developers to do the right thing and contribute
> full support for the board. To me it is simply a matter of
> acknowledging that bootloader support for a board without DRAM init is
> not useful bootloader support. Since we have the code in place to
> support that, we can take the extra step and require that each board
> contribution be useful in that aspect.
>
>> For the time now, I know there will be full DRAM driver for rockchip SoC,
>> so the SoC/board support could be step by step:
>> U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
>>
>> As you can see the rockchip LPDDR4 driver send by Jagan, has 99 patches
>> in V2, you can't use static register configuration to do this, and maybe you
>> can't have a workable version if rockchip don't release it, but I don't
>> think it's
>> correct to make all those boards with lpddr4 float outside the mainline
>> support
>> because many developers are using the boards, they can only use vendor
>> branch
>> if the board not support by mainline.
> If mainline U-Boot can't support basic bootloader features such as DRAM
> initialization for these boards, I don't see the point in accepting
> support for them.
>
> It would be like submitting support for a board in Linux with a new CPU
> that is not supported and asking to boot Linux via a non-free shim
> before Linux to put the CPU in a legacy state that Linux can support.
> This would definitely not be okay and I don't see why the same
> shouldn't apply to U-Boot.
Linux build target is Image/zImage, if this Image not work with the board,
eg. hang somewhere during boot, then we say the board support is broken
and result in non-functional boot. And there always some kernel features
depends on bootloader setting, including security setting, some clock init,
some power supply and etc.
>
>> So I think merge those patches already make board work on mainline U-Boot
>> is pretty important for open source community.
> I don't think the patches make the boards work on mainline U-Boot since
> building and installing the resulting U-Boot binaries will result in a
> non-functional boot chain and brick the device. I don't think this is a
> good or safe idea.
In U-Boot, there are 2 or 3 standalone subsystem: U-Boot proper,
SPL, and TPL, and build target is u-boot.bin, u-boot-spl.bin, and
u-boot-tpl.bin.
If the standalone u-boot.bin or u-boot-spl.bin works good with a board and
able to boot into next stage correctly, I don't think these patches can
be consider
as "non-functional boot chain and brick the device". And for example for
armv8,
U-Boot is always as part of the boot chain.
Thanks,
- Kever
>
> Cheers,
>
> Paul
>
>> Thanks,
>> - Kever
>>> Frankly, I don't think that would help. It would just drive more
>>> people to the vendor U-Boot that has more bugs and includes a vendor
>>> supplied ATF binary.
>>>
>>>>> I'm not sure if you have write a new dram driver for a board, but I know
>>>>> even the board vendor may not have the capability to write the DRAM
>>>>> driver, so this should not stop developers contribute to all other 99%
>>>>> features on U-Boot.
>>>> What they can do is run the non-free blob, dump the registers
>>>> afterwards and then use that in the DRAM configuration dtsi. Perhaps
>>>> one could write up a tool to ease the process if they think the process
>>>> is too much for a regular bringup.
>>>>
>>>> Most of the time, the DRAM chips are soldered so the calibrated values
>>>> have about no reason to change over time and can just be kept as-is.
>>>>
>>>> What do you think?
>>> Hopefully the pending diff to add support for other DRAM types beyond
>>> those that are already supported would make bring us a long way in
>>> that direction. Maybe one of the existing timings will already work
>>> for the boards that are being discussed here.
>>>
>>
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-20 3:24 ` [U-Boot] " Kever Yang
@ 2019-06-21 11:34 ` Heiko Stuebner
-1 siblings, 0 replies; 43+ messages in thread
From: Heiko Stuebner @ 2019-06-21 11:34 UTC (permalink / raw)
To: u-boot-0aAXYlwwYIKGBzrmiIFOJg
Cc: Maxime Ripard, Kever Yang, Paul Kocialkowski,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nick-XW3xCAIBE2TQT0dZR+AlfA,
philipp.tomsich-SN7IsUiht6C/RdPyistoZJqQE7yCjDx5,
linux-amarula-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/,
xieqinick-Re5JQEeQqe8AvxtiuMwx3w, Mark Kettenis
Hi,
Am Donnerstag, 20. Juni 2019, 05:24:32 CEST schrieb Kever Yang:
> On 06/20/2019 12:54 AM, Paul Kocialkowski wrote:
> > Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
> >> On 06/19/2019 12:12 AM, Mark Kettenis wrote:
> >>>> From: Paul Kocialkowski <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
> >>>> Date: Tue, 18 Jun 2019 14:47:33 +0200
> >>>> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> >>>>> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> >>>>>> On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> >>>>>>> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> >>>>>>> <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org> wrote:
> >>>>>>>> On Mon, 2019-06-17 at 15:24 +0800, xieqinick-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
> >>>>>>>>> From: Nick Xie <nick-XW3xCAIBE2TQT0dZR+AlfA@public.gmane.org>
> >>>>>>>> Was this tested with SPL support? I don't see DRAM configuration here
> >>>>>>>> so it seems that it relies on the non-free rockchip loader.
> >>>>>>>>
> >>>>>>>> If that is the case, could you please indicate that in the commit
> >>>>>>>> message?
> >>>>>>>>
> >>>>>>>> To maintainers: please do not merge this series before DRAM init and
> >>>>>>>> SPL support is available for these boards.
> >>>>>>>>
> >>>>>>>> It seems that other RK3399 boards were merged without SPL support and
> >>>>>>>> sofar, I have the feeling that nobody cared to explain how we got into
> >>>>>>>> this broken situation. Please don't merge any more such board.
> >>>>>>> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> >>>>>>> with TPL-enabled (which was discussed on the threads, if you remember)
> >>>>>>> with below boot chain.
> >>>>>>>
> >>>>>>> rkbin (TPL) -> SPL -> U-Boot proper
> >>>>>>>
> >>>>>>> Same case for this board as well.
> >>>>>> Here is a quote from Philipp Tomsich on the thread we discussed this:
> >>>>>>
> >>>>>> " On some boards, there will be no TPL and only a SPL stage that will
> >>>>>> initialise DRAM (as the move to having TPL on the RK3399 is optional).
> >>>>>>
> >>>>>> I agree with Paul that the DRAM init should be part of U-Boot whenever
> >>>>>> we add new boards and make an open DRAM init a prerequisite. "
> >>>>>>
> >>>>>> So even if I frequently confuse SPL and TPL, it doesn't change the fact
> >>>>>> that no board should be merged without proper DRAM init.
> >>>>>>
> >>>>>> Please stop pushing for merging these boards. I'm not sure what we
> >>>>>> should do about the boards that were merged already without DRAM init,
> >>>>>> but maybe they should be reverted.
> >>>>> I don't think we have to have full DRAM init source code for each
> >>>>> board before we can merge it, I believe most of the board on U-Boot
> >>>>> mainline need to removed due to this rule. There are so many boards
> >>>>> from different vendor need a binary loader before U-Boot, and I can
> >>>>> see only very few drivers for dram at driver/ram/, and I believe rockchip
> >>>>> is already the most open vendor on this area.
> >>>> Well, I am not talking about full DRAM init source code as in dynamic
> >>>> link training. I am talking about having at least static DRAM register
> >>>> configuration values,
> >> I can tell you that this is no work for all the boards, you can see how
> >> rockchip lpddr4(WIP, send by Jagan) driver works.
> > I thought that LPDDR4 works the same as other types of DRAM where we
> > have a dtsi array with timings configuration. Of course, some more
> > registers need to be set up, but we already have support for that or
> > it's quite close (for LPDDR4).
>
> >>>> which is present for a good number of rockchip
> >>>> boards.
> >> No, there is no rockchip board only have static DRAM register
> >> configuration values, that maybe happens in other vendor.
>
> > I was implying that, as far as I know, it is the case for DRAM timings
> > on Rockchip as well as most of the platforms that I know of. In the
> > end, any code handling DRAM will end up writing timings to the
> > controller's registers. If the DRAM is part of the PCB and doesn't
> > change/move, then the timings don't change in particular.
> >
> > Is there something specific about Rockchip that makes it require
> > different DRAM timings at each boot?
>
> >>>> Of course, it would be best if Rockchip would consider releasing this
> >>>> source code,
> >> Rockchip already release all the DRAM init source code, including DDR3 ,
> >> LPDDR3,
> >> and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
> >> everything,
> >> which is not only static register configuration.
> >> As I have said, rockchip is already the most open vendor in this area
> >> till now, I don't know
> >> if you have working on rockchip SoC based boards.
> > You are quite right about that, but I was thinking about the code to
> > calculate DRAM timings (with link-training and such) which is often not
> > available as free software, and I am not aware of Rockchip having
> > released that code (but feel free to correct me if I'm wrong).
> >
> >>>> which would be the easiest and friendliest solution
> >>>> towards the community here. Are there internal discussions ongoing
> >>>> about this? If not, it would be greatly appreciated to start such
> >>>> discussions and clearly identify what the blocking points are.
> >>>>
> >>>>> I won't use this rule to stop developers contribute there source code,
> >>>> This is really sad and I think that Philipp was, like me, inclined to
> >>>> go towards the other direction.
> >>>>
> >>>>> for a board support, we only need the board to have the full documentation
> >>>>> about how to setup and boot with upstream U-Boot. and I think the
> >>>>> most of people cares more about features in U-Boot proper. Everything
> >>>>> before U-Boot proper, you can use TPL/SPL or alternative to use binary
> >>>>> from vendor, as you can see all over the U-Boot mainline now, although
> >>>>> we encourage people to use full open source TPL/SPL.
> >>>>> Specifically for U-Boot Rockchip platform, I would like people to
> >>>>> support not only U-Boot
> >>>>> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> >>>>> features)
> >>>>> support. And for DRAM init,
> >>>>> - if this belongs to SPL for this board, you must implement it or else
> >>>>> SPL won't work;
> >>>>> - if this does not belong to SPL for this board, you need implement full
> >>>>> function SPL;
> >>>>> and you can either to have full function TPL with DRAM init(which is
> >>>>> prefered)
> >>>>> or alternatively use binary loader from vendor.
> >>>> This is not really a technical argument here, more of a policy argument
> >>>> that ensures we have full free software support for the boards we
> >>>> support, and not only half-cooked support (that will most likely never
> >>>> be completed as soon as something that works gets merged). So it is a
> >>>> strategical decision, not a strictly pragmatic one.
> >>> While having full open source software support for boards is a noble
> >>> goal, I think there should be some room for pragmatism here. A
> >>> significant number of u_boot targets rely on closed source components.
> >>> In the particular case of RK3399 the situation is better than for
> >>> other boards since you can combine the binary loader from the vendor
> >>> with mainline U-Boot and mainline ATF to create a firmware where (as
> >>> far as we can tell) no closed soure component remains active after
> >>> U-Boot and ATF take over control.
> >>>
> >>>> I think reverting patches adding support for boards with no DRAM
> >>>> configuration at all would send a message in the right direction here.
> >> As a developer, I agree on this, but as a maintainer, I know too many
> >> developers not able to do it and what most of developers need is other
> >> features in U-Boot or SPL, and I would like the U-Boot mainline is more
> >> active with more and more developers. So I'm afraid I agree with Mark
> >> at this time for the policy.
> > Maybe we need to provide tools ot make that process easier for everyone
> > if it is really that hard. I don't really see what is so special about
> > DRAM timings that would imply that a regular developer doing a U-Boot
> > bringup couldn't figure things out, aside from the ability to dump said
> > timings.
> >
> >> If all the other SoC platforms can have the same rule for DRAM init driver
> >> is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
> >> imx, aml, and all others, then I would very happy to follow the rule.
> >> Rockchip is open for open source the DRAM driver, you have to know this
> >> is the decision by the vendor, but not any of developers.
> >> On rockchip platform, developers no need to concern about the DRAM
> >> driver(which is pretty hard for most developers) because rockchip
> >> already contribute it.
> > Rockchip is indeed in a better position than other vendors where DRAM
> > init may not be available (or when it's impossible to run U-Boot right
> > after the bootrom and do the DRAM init itself because of e.g. abusive
> > signature verification or lack of documentation).
> >
> > Since there is good DRAM support for Rockchip in place, we have an
> > opportunity to push developers to do the right thing and contribute
> > full support for the board. To me it is simply a matter of
> > acknowledging that bootloader support for a board without DRAM init is
> > not useful bootloader support. Since we have the code in place to
> > support that, we can take the extra step and require that each board
> > contribution be useful in that aspect.
> >
> >> For the time now, I know there will be full DRAM driver for rockchip SoC,
> >> so the SoC/board support could be step by step:
> >> U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
Keeping allowing a step-by-step approach could be beneficial I think,
in the kernel we also don't require full support for all peripherals on
initial submission ;-) .
And also for people starting out on a specific board having at least partial
support is way easier than trying to figure out for example the vendor
u-boot.
Maybe we could give this some sort of time limitation like
"binary ddr-init allowed till 2019-10-31" in Kconfig or somewhere
to give people the chance to do things piece by piece but still force them
to actually work on improving the situation.
As driver-side changes will generally benefit more socs/boards potential
removal after the time limit would only affect the board+dts itself.
So somewhat similar to what the kernel does with "staging", if you
keep working on improving it, it is allowed to stay.
This could be also applied to already included boards, like
"give it a working ddr-init till 2019-12-31 or it gets removed", similarly
to how Tom handles devicemanager conversions currently
> >> As you can see the rockchip LPDDR4 driver send by Jagan, has 99 patches
> >> in V2, you can't use static register configuration to do this, and maybe you
> >> can't have a workable version if rockchip don't release it, but I don't
> >> think it's
> >> correct to make all those boards with lpddr4 float outside the mainline
> >> support
> >> because many developers are using the boards, they can only use vendor
> >> branch
> >> if the board not support by mainline.
> > If mainline U-Boot can't support basic bootloader features such as DRAM
> > initialization for these boards, I don't see the point in accepting
> > support for them.
Hmm, actually I see ddr-init as one of the more difficult parts to achieve
at least if you're not the soc-vendor, due to unavailable documentation
or sources.
> > It would be like submitting support for a board in Linux with a new CPU
> > that is not supported and asking to boot Linux via a non-free shim
> > before Linux to put the CPU in a legacy state that Linux can support.
> > This would definitely not be okay and I don't see why the same
> > shouldn't apply to U-Boot.
A less drastic example would be, submitting a basic devicetree to the
linux kernel without clocks and pinctrl and relying on the things the
bootloader set up for things like uart.
Heiko
> Linux build target is Image/zImage, if this Image not work with the board,
> eg. hang somewhere during boot, then we say the board support is broken
> and result in non-functional boot. And there always some kernel features
> depends on bootloader setting, including security setting, some clock init,
> some power supply and etc.
>
> >
> >> So I think merge those patches already make board work on mainline U-Boot
> >> is pretty important for open source community.
> > I don't think the patches make the boards work on mainline U-Boot since
> > building and installing the resulting U-Boot binaries will result in a
> > non-functional boot chain and brick the device. I don't think this is a
> > good or safe idea.
>
> In U-Boot, there are 2 or 3 standalone subsystem: U-Boot proper,
> SPL, and TPL, and build target is u-boot.bin, u-boot-spl.bin, and
> u-boot-tpl.bin.
> If the standalone u-boot.bin or u-boot-spl.bin works good with a board and
> able to boot into next stage correctly, I don't think these patches can
> be consider
> as "non-functional boot chain and brick the device". And for example for
> armv8,
> U-Boot is always as part of the boot chain.
>
> Thanks,
> - Kever
> >
> > Cheers,
> >
> > Paul
> >
> >> Thanks,
> >> - Kever
> >>> Frankly, I don't think that would help. It would just drive more
> >>> people to the vendor U-Boot that has more bugs and includes a vendor
> >>> supplied ATF binary.
> >>>
> >>>>> I'm not sure if you have write a new dram driver for a board, but I know
> >>>>> even the board vendor may not have the capability to write the DRAM
> >>>>> driver, so this should not stop developers contribute to all other 99%
> >>>>> features on U-Boot.
> >>>> What they can do is run the non-free blob, dump the registers
> >>>> afterwards and then use that in the DRAM configuration dtsi. Perhaps
> >>>> one could write up a tool to ease the process if they think the process
> >>>> is too much for a regular bringup.
> >>>>
> >>>> Most of the time, the DRAM chips are soldered so the calibrated values
> >>>> have about no reason to change over time and can just be kept as-is.
> >>>>
> >>>> What do you think?
> >>> Hopefully the pending diff to add support for other DRAM types beyond
> >>> those that are already supported would make bring us a long way in
> >>> that direction. Maybe one of the existing timings will already work
> >>> for the boards that are being discussed here.
> >>>
> >>
> >
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org
> https://lists.denx.de/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-21 11:34 ` Heiko Stuebner
0 siblings, 0 replies; 43+ messages in thread
From: Heiko Stuebner @ 2019-06-21 11:34 UTC (permalink / raw)
To: u-boot
Hi,
Am Donnerstag, 20. Juni 2019, 05:24:32 CEST schrieb Kever Yang:
> On 06/20/2019 12:54 AM, Paul Kocialkowski wrote:
> > Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
> >> On 06/19/2019 12:12 AM, Mark Kettenis wrote:
> >>>> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> >>>> Date: Tue, 18 Jun 2019 14:47:33 +0200
> >>>> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> >>>>> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> >>>>>> On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> >>>>>>> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> >>>>>>> <paul.kocialkowski@bootlin.com> wrote:
> >>>>>>>> On Mon, 2019-06-17 at 15:24 +0800, xieqinick at gmail.com wrote:
> >>>>>>>>> From: Nick Xie <nick@khadas.com>
> >>>>>>>> Was this tested with SPL support? I don't see DRAM configuration here
> >>>>>>>> so it seems that it relies on the non-free rockchip loader.
> >>>>>>>>
> >>>>>>>> If that is the case, could you please indicate that in the commit
> >>>>>>>> message?
> >>>>>>>>
> >>>>>>>> To maintainers: please do not merge this series before DRAM init and
> >>>>>>>> SPL support is available for these boards.
> >>>>>>>>
> >>>>>>>> It seems that other RK3399 boards were merged without SPL support and
> >>>>>>>> sofar, I have the feeling that nobody cared to explain how we got into
> >>>>>>>> this broken situation. Please don't merge any more such board.
> >>>>>>> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> >>>>>>> with TPL-enabled (which was discussed on the threads, if you remember)
> >>>>>>> with below boot chain.
> >>>>>>>
> >>>>>>> rkbin (TPL) -> SPL -> U-Boot proper
> >>>>>>>
> >>>>>>> Same case for this board as well.
> >>>>>> Here is a quote from Philipp Tomsich on the thread we discussed this:
> >>>>>>
> >>>>>> " On some boards, there will be no TPL and only a SPL stage that will
> >>>>>> initialise DRAM (as the move to having TPL on the RK3399 is optional).
> >>>>>>
> >>>>>> I agree with Paul that the DRAM init should be part of U-Boot whenever
> >>>>>> we add new boards and make an open DRAM init a prerequisite. "
> >>>>>>
> >>>>>> So even if I frequently confuse SPL and TPL, it doesn't change the fact
> >>>>>> that no board should be merged without proper DRAM init.
> >>>>>>
> >>>>>> Please stop pushing for merging these boards. I'm not sure what we
> >>>>>> should do about the boards that were merged already without DRAM init,
> >>>>>> but maybe they should be reverted.
> >>>>> I don't think we have to have full DRAM init source code for each
> >>>>> board before we can merge it, I believe most of the board on U-Boot
> >>>>> mainline need to removed due to this rule. There are so many boards
> >>>>> from different vendor need a binary loader before U-Boot, and I can
> >>>>> see only very few drivers for dram at driver/ram/, and I believe rockchip
> >>>>> is already the most open vendor on this area.
> >>>> Well, I am not talking about full DRAM init source code as in dynamic
> >>>> link training. I am talking about having at least static DRAM register
> >>>> configuration values,
> >> I can tell you that this is no work for all the boards, you can see how
> >> rockchip lpddr4(WIP, send by Jagan) driver works.
> > I thought that LPDDR4 works the same as other types of DRAM where we
> > have a dtsi array with timings configuration. Of course, some more
> > registers need to be set up, but we already have support for that or
> > it's quite close (for LPDDR4).
>
> >>>> which is present for a good number of rockchip
> >>>> boards.
> >> No, there is no rockchip board only have static DRAM register
> >> configuration values, that maybe happens in other vendor.
>
> > I was implying that, as far as I know, it is the case for DRAM timings
> > on Rockchip as well as most of the platforms that I know of. In the
> > end, any code handling DRAM will end up writing timings to the
> > controller's registers. If the DRAM is part of the PCB and doesn't
> > change/move, then the timings don't change in particular.
> >
> > Is there something specific about Rockchip that makes it require
> > different DRAM timings at each boot?
>
> >>>> Of course, it would be best if Rockchip would consider releasing this
> >>>> source code,
> >> Rockchip already release all the DRAM init source code, including DDR3 ,
> >> LPDDR3,
> >> and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
> >> everything,
> >> which is not only static register configuration.
> >> As I have said, rockchip is already the most open vendor in this area
> >> till now, I don't know
> >> if you have working on rockchip SoC based boards.
> > You are quite right about that, but I was thinking about the code to
> > calculate DRAM timings (with link-training and such) which is often not
> > available as free software, and I am not aware of Rockchip having
> > released that code (but feel free to correct me if I'm wrong).
> >
> >>>> which would be the easiest and friendliest solution
> >>>> towards the community here. Are there internal discussions ongoing
> >>>> about this? If not, it would be greatly appreciated to start such
> >>>> discussions and clearly identify what the blocking points are.
> >>>>
> >>>>> I won't use this rule to stop developers contribute there source code,
> >>>> This is really sad and I think that Philipp was, like me, inclined to
> >>>> go towards the other direction.
> >>>>
> >>>>> for a board support, we only need the board to have the full documentation
> >>>>> about how to setup and boot with upstream U-Boot. and I think the
> >>>>> most of people cares more about features in U-Boot proper. Everything
> >>>>> before U-Boot proper, you can use TPL/SPL or alternative to use binary
> >>>>> from vendor, as you can see all over the U-Boot mainline now, although
> >>>>> we encourage people to use full open source TPL/SPL.
> >>>>> Specifically for U-Boot Rockchip platform, I would like people to
> >>>>> support not only U-Boot
> >>>>> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> >>>>> features)
> >>>>> support. And for DRAM init,
> >>>>> - if this belongs to SPL for this board, you must implement it or else
> >>>>> SPL won't work;
> >>>>> - if this does not belong to SPL for this board, you need implement full
> >>>>> function SPL;
> >>>>> and you can either to have full function TPL with DRAM init(which is
> >>>>> prefered)
> >>>>> or alternatively use binary loader from vendor.
> >>>> This is not really a technical argument here, more of a policy argument
> >>>> that ensures we have full free software support for the boards we
> >>>> support, and not only half-cooked support (that will most likely never
> >>>> be completed as soon as something that works gets merged). So it is a
> >>>> strategical decision, not a strictly pragmatic one.
> >>> While having full open source software support for boards is a noble
> >>> goal, I think there should be some room for pragmatism here. A
> >>> significant number of u_boot targets rely on closed source components.
> >>> In the particular case of RK3399 the situation is better than for
> >>> other boards since you can combine the binary loader from the vendor
> >>> with mainline U-Boot and mainline ATF to create a firmware where (as
> >>> far as we can tell) no closed soure component remains active after
> >>> U-Boot and ATF take over control.
> >>>
> >>>> I think reverting patches adding support for boards with no DRAM
> >>>> configuration at all would send a message in the right direction here.
> >> As a developer, I agree on this, but as a maintainer, I know too many
> >> developers not able to do it and what most of developers need is other
> >> features in U-Boot or SPL, and I would like the U-Boot mainline is more
> >> active with more and more developers. So I'm afraid I agree with Mark
> >> at this time for the policy.
> > Maybe we need to provide tools ot make that process easier for everyone
> > if it is really that hard. I don't really see what is so special about
> > DRAM timings that would imply that a regular developer doing a U-Boot
> > bringup couldn't figure things out, aside from the ability to dump said
> > timings.
> >
> >> If all the other SoC platforms can have the same rule for DRAM init driver
> >> is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
> >> imx, aml, and all others, then I would very happy to follow the rule.
> >> Rockchip is open for open source the DRAM driver, you have to know this
> >> is the decision by the vendor, but not any of developers.
> >> On rockchip platform, developers no need to concern about the DRAM
> >> driver(which is pretty hard for most developers) because rockchip
> >> already contribute it.
> > Rockchip is indeed in a better position than other vendors where DRAM
> > init may not be available (or when it's impossible to run U-Boot right
> > after the bootrom and do the DRAM init itself because of e.g. abusive
> > signature verification or lack of documentation).
> >
> > Since there is good DRAM support for Rockchip in place, we have an
> > opportunity to push developers to do the right thing and contribute
> > full support for the board. To me it is simply a matter of
> > acknowledging that bootloader support for a board without DRAM init is
> > not useful bootloader support. Since we have the code in place to
> > support that, we can take the extra step and require that each board
> > contribution be useful in that aspect.
> >
> >> For the time now, I know there will be full DRAM driver for rockchip SoC,
> >> so the SoC/board support could be step by step:
> >> U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
Keeping allowing a step-by-step approach could be beneficial I think,
in the kernel we also don't require full support for all peripherals on
initial submission ;-) .
And also for people starting out on a specific board having at least partial
support is way easier than trying to figure out for example the vendor
u-boot.
Maybe we could give this some sort of time limitation like
"binary ddr-init allowed till 2019-10-31" in Kconfig or somewhere
to give people the chance to do things piece by piece but still force them
to actually work on improving the situation.
As driver-side changes will generally benefit more socs/boards potential
removal after the time limit would only affect the board+dts itself.
So somewhat similar to what the kernel does with "staging", if you
keep working on improving it, it is allowed to stay.
This could be also applied to already included boards, like
"give it a working ddr-init till 2019-12-31 or it gets removed", similarly
to how Tom handles devicemanager conversions currently
> >> As you can see the rockchip LPDDR4 driver send by Jagan, has 99 patches
> >> in V2, you can't use static register configuration to do this, and maybe you
> >> can't have a workable version if rockchip don't release it, but I don't
> >> think it's
> >> correct to make all those boards with lpddr4 float outside the mainline
> >> support
> >> because many developers are using the boards, they can only use vendor
> >> branch
> >> if the board not support by mainline.
> > If mainline U-Boot can't support basic bootloader features such as DRAM
> > initialization for these boards, I don't see the point in accepting
> > support for them.
Hmm, actually I see ddr-init as one of the more difficult parts to achieve
at least if you're not the soc-vendor, due to unavailable documentation
or sources.
> > It would be like submitting support for a board in Linux with a new CPU
> > that is not supported and asking to boot Linux via a non-free shim
> > before Linux to put the CPU in a legacy state that Linux can support.
> > This would definitely not be okay and I don't see why the same
> > shouldn't apply to U-Boot.
A less drastic example would be, submitting a basic devicetree to the
linux kernel without clocks and pinctrl and relying on the things the
bootloader set up for things like uart.
Heiko
> Linux build target is Image/zImage, if this Image not work with the board,
> eg. hang somewhere during boot, then we say the board support is broken
> and result in non-functional boot. And there always some kernel features
> depends on bootloader setting, including security setting, some clock init,
> some power supply and etc.
>
> >
> >> So I think merge those patches already make board work on mainline U-Boot
> >> is pretty important for open source community.
> > I don't think the patches make the boards work on mainline U-Boot since
> > building and installing the resulting U-Boot binaries will result in a
> > non-functional boot chain and brick the device. I don't think this is a
> > good or safe idea.
>
> In U-Boot, there are 2 or 3 standalone subsystem: U-Boot proper,
> SPL, and TPL, and build target is u-boot.bin, u-boot-spl.bin, and
> u-boot-tpl.bin.
> If the standalone u-boot.bin or u-boot-spl.bin works good with a board and
> able to boot into next stage correctly, I don't think these patches can
> be consider
> as "non-functional boot chain and brick the device". And for example for
> armv8,
> U-Boot is always as part of the boot chain.
>
> Thanks,
> - Kever
> >
> > Cheers,
> >
> > Paul
> >
> >> Thanks,
> >> - Kever
> >>> Frankly, I don't think that would help. It would just drive more
> >>> people to the vendor U-Boot that has more bugs and includes a vendor
> >>> supplied ATF binary.
> >>>
> >>>>> I'm not sure if you have write a new dram driver for a board, but I know
> >>>>> even the board vendor may not have the capability to write the DRAM
> >>>>> driver, so this should not stop developers contribute to all other 99%
> >>>>> features on U-Boot.
> >>>> What they can do is run the non-free blob, dump the registers
> >>>> afterwards and then use that in the DRAM configuration dtsi. Perhaps
> >>>> one could write up a tool to ease the process if they think the process
> >>>> is too much for a regular bringup.
> >>>>
> >>>> Most of the time, the DRAM chips are soldered so the calibrated values
> >>>> have about no reason to change over time and can just be kept as-is.
> >>>>
> >>>> What do you think?
> >>> Hopefully the pending diff to add support for other DRAM types beyond
> >>> those that are already supported would make bring us a long way in
> >>> that direction. Maybe one of the existing timings will already work
> >>> for the boards that are being discussed here.
> >>>
> >>
> >
>
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-21 11:34 ` Heiko Stuebner
@ 2019-06-21 11:58 ` Paul Kocialkowski
-1 siblings, 0 replies; 43+ messages in thread
From: Paul Kocialkowski @ 2019-06-21 11:58 UTC (permalink / raw)
To: Heiko Stuebner, u-boot
Cc: Maxime Ripard, linux-rockchip, nick, linux-amarula, xieqinick
Hi,
On Fri, 2019-06-21 at 13:34 +0200, Heiko Stuebner wrote:
> Hi,
>
> Am Donnerstag, 20. Juni 2019, 05:24:32 CEST schrieb Kever Yang:
> > On 06/20/2019 12:54 AM, Paul Kocialkowski wrote:
> > > Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
> > > > On 06/19/2019 12:12 AM, Mark Kettenis wrote:
> > > > > > From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > > > > > Date: Tue, 18 Jun 2019 14:47:33 +0200
> > > > > > On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> > > > > > > On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > > > > > > > On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > > > > > > > On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > On Mon, 2019-06-17 at 15:24 +0800, xieqinick@gmail.com wrote:
> > > > > > > > > > > From: Nick Xie <nick@khadas.com>
> > > > > > > > > > Was this tested with SPL support? I don't see DRAM configuration here
> > > > > > > > > > so it seems that it relies on the non-free rockchip loader.
> > > > > > > > > >
> > > > > > > > > > If that is the case, could you please indicate that in the commit
> > > > > > > > > > message?
> > > > > > > > > >
> > > > > > > > > > To maintainers: please do not merge this series before DRAM init and
> > > > > > > > > > SPL support is available for these boards.
> > > > > > > > > >
> > > > > > > > > > It seems that other RK3399 boards were merged without SPL support and
> > > > > > > > > > sofar, I have the feeling that nobody cared to explain how we got into
> > > > > > > > > > this broken situation. Please don't merge any more such board.
> > > > > > > > > fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > > > > > > > > with TPL-enabled (which was discussed on the threads, if you remember)
> > > > > > > > > with below boot chain.
> > > > > > > > >
> > > > > > > > > rkbin (TPL) -> SPL -> U-Boot proper
> > > > > > > > >
> > > > > > > > > Same case for this board as well.
> > > > > > > > Here is a quote from Philipp Tomsich on the thread we discussed this:
> > > > > > > >
> > > > > > > > " On some boards, there will be no TPL and only a SPL stage that will
> > > > > > > > initialise DRAM (as the move to having TPL on the RK3399 is optional).
> > > > > > > >
> > > > > > > > I agree with Paul that the DRAM init should be part of U-Boot whenever
> > > > > > > > we add new boards and make an open DRAM init a prerequisite. "
> > > > > > > >
> > > > > > > > So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > > > > > > > that no board should be merged without proper DRAM init.
> > > > > > > >
> > > > > > > > Please stop pushing for merging these boards. I'm not sure what we
> > > > > > > > should do about the boards that were merged already without DRAM init,
> > > > > > > > but maybe they should be reverted.
> > > > > > > I don't think we have to have full DRAM init source code for each
> > > > > > > board before we can merge it, I believe most of the board on U-Boot
> > > > > > > mainline need to removed due to this rule. There are so many boards
> > > > > > > from different vendor need a binary loader before U-Boot, and I can
> > > > > > > see only very few drivers for dram at driver/ram/, and I believe rockchip
> > > > > > > is already the most open vendor on this area.
> > > > > > Well, I am not talking about full DRAM init source code as in dynamic
> > > > > > link training. I am talking about having at least static DRAM register
> > > > > > configuration values,
> > > > I can tell you that this is no work for all the boards, you can see how
> > > > rockchip lpddr4(WIP, send by Jagan) driver works.
> > > I thought that LPDDR4 works the same as other types of DRAM where we
> > > have a dtsi array with timings configuration. Of course, some more
> > > registers need to be set up, but we already have support for that or
> > > it's quite close (for LPDDR4).
> > > > > > which is present for a good number of rockchip
> > > > > > boards.
> > > > No, there is no rockchip board only have static DRAM register
> > > > configuration values, that maybe happens in other vendor.
> > > I was implying that, as far as I know, it is the case for DRAM timings
> > > on Rockchip as well as most of the platforms that I know of. In the
> > > end, any code handling DRAM will end up writing timings to the
> > > controller's registers. If the DRAM is part of the PCB and doesn't
> > > change/move, then the timings don't change in particular.
> > >
> > > Is there something specific about Rockchip that makes it require
> > > different DRAM timings at each boot?
> > > > > > Of course, it would be best if Rockchip would consider releasing this
> > > > > > source code,
> > > > Rockchip already release all the DRAM init source code, including DDR3 ,
> > > > LPDDR3,
> > > > and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
> > > > everything,
> > > > which is not only static register configuration.
> > > > As I have said, rockchip is already the most open vendor in this area
> > > > till now, I don't know
> > > > if you have working on rockchip SoC based boards.
> > > You are quite right about that, but I was thinking about the code to
> > > calculate DRAM timings (with link-training and such) which is often not
> > > available as free software, and I am not aware of Rockchip having
> > > released that code (but feel free to correct me if I'm wrong).
> > >
> > > > > > which would be the easiest and friendliest solution
> > > > > > towards the community here. Are there internal discussions ongoing
> > > > > > about this? If not, it would be greatly appreciated to start such
> > > > > > discussions and clearly identify what the blocking points are.
> > > > > >
> > > > > > > I won't use this rule to stop developers contribute there source code,
> > > > > > This is really sad and I think that Philipp was, like me, inclined to
> > > > > > go towards the other direction.
> > > > > >
> > > > > > > for a board support, we only need the board to have the full documentation
> > > > > > > about how to setup and boot with upstream U-Boot. and I think the
> > > > > > > most of people cares more about features in U-Boot proper. Everything
> > > > > > > before U-Boot proper, you can use TPL/SPL or alternative to use binary
> > > > > > > from vendor, as you can see all over the U-Boot mainline now, although
> > > > > > > we encourage people to use full open source TPL/SPL.
> > > > > > > Specifically for U-Boot Rockchip platform, I would like people to
> > > > > > > support not only U-Boot
> > > > > > > proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> > > > > > > features)
> > > > > > > support. And for DRAM init,
> > > > > > > - if this belongs to SPL for this board, you must implement it or else
> > > > > > > SPL won't work;
> > > > > > > - if this does not belong to SPL for this board, you need implement full
> > > > > > > function SPL;
> > > > > > > and you can either to have full function TPL with DRAM init(which is
> > > > > > > prefered)
> > > > > > > or alternatively use binary loader from vendor.
> > > > > > This is not really a technical argument here, more of a policy argument
> > > > > > that ensures we have full free software support for the boards we
> > > > > > support, and not only half-cooked support (that will most likely never
> > > > > > be completed as soon as something that works gets merged). So it is a
> > > > > > strategical decision, not a strictly pragmatic one.
> > > > > While having full open source software support for boards is a noble
> > > > > goal, I think there should be some room for pragmatism here. A
> > > > > significant number of u_boot targets rely on closed source components.
> > > > > In the particular case of RK3399 the situation is better than for
> > > > > other boards since you can combine the binary loader from the vendor
> > > > > with mainline U-Boot and mainline ATF to create a firmware where (as
> > > > > far as we can tell) no closed soure component remains active after
> > > > > U-Boot and ATF take over control.
> > > > >
> > > > > > I think reverting patches adding support for boards with no DRAM
> > > > > > configuration at all would send a message in the right direction here.
> > > > As a developer, I agree on this, but as a maintainer, I know too many
> > > > developers not able to do it and what most of developers need is other
> > > > features in U-Boot or SPL, and I would like the U-Boot mainline is more
> > > > active with more and more developers. So I'm afraid I agree with Mark
> > > > at this time for the policy.
> > > Maybe we need to provide tools ot make that process easier for everyone
> > > if it is really that hard. I don't really see what is so special about
> > > DRAM timings that would imply that a regular developer doing a U-Boot
> > > bringup couldn't figure things out, aside from the ability to dump said
> > > timings.
> > >
> > > > If all the other SoC platforms can have the same rule for DRAM init driver
> > > > is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
> > > > imx, aml, and all others, then I would very happy to follow the rule.
> > > > Rockchip is open for open source the DRAM driver, you have to know this
> > > > is the decision by the vendor, but not any of developers.
> > > > On rockchip platform, developers no need to concern about the DRAM
> > > > driver(which is pretty hard for most developers) because rockchip
> > > > already contribute it.
> > > Rockchip is indeed in a better position than other vendors where DRAM
> > > init may not be available (or when it's impossible to run U-Boot right
> > > after the bootrom and do the DRAM init itself because of e.g. abusive
> > > signature verification or lack of documentation).
> > >
> > > Since there is good DRAM support for Rockchip in place, we have an
> > > opportunity to push developers to do the right thing and contribute
> > > full support for the board. To me it is simply a matter of
> > > acknowledging that bootloader support for a board without DRAM init is
> > > not useful bootloader support. Since we have the code in place to
> > > support that, we can take the extra step and require that each board
> > > contribution be useful in that aspect.
> > >
> > > > For the time now, I know there will be full DRAM driver for rockchip SoC,
> > > > so the SoC/board support could be step by step:
> > > > U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
>
> Keeping allowing a step-by-step approach could be beneficial I think,
> in the kernel we also don't require full support for all peripherals on
> initial submission ;-) .
To be fair, I'm not suggesting that either, I'm only concerned about
DRAM init which I wouldn't put under "any feature/controller" but one
of the basic things that are required to make bootloader support
useful.
> And also for people starting out on a specific board having at least partial
> support is way easier than trying to figure out for example the vendor
> u-boot.
Fair enough, but it can also bring some confusion if support is not
clearly identified as being partial. Hence my point about inadvertently
bricking devices if U-Boot alone is sufficient to boot on some rk3399
devices but if it's not on some other ones.
> Maybe we could give this some sort of time limitation like
> "binary ddr-init allowed till 2019-10-31" in Kconfig or somewhere
> to give people the chance to do things piece by piece but still force them
> to actually work on improving the situation.
This sounds like a prefectly reasonable compromise to me :)
> As driver-side changes will generally benefit more socs/boards potential
> removal after the time limit would only affect the board+dts itself.
And it's also a good thing to keep that support around in the history.
> So somewhat similar to what the kernel does with "staging", if you
> keep working on improving it, it is allowed to stay.
>
> This could be also applied to already included boards, like
> "give it a working ddr-init till 2019-12-31 or it gets removed", similarly
> to how Tom handles devicemanager conversions currently
Agreed and I would like to suggest some clear way of marking the boards
as partially supported, for instance a warning message (like we show on
numerous other topics) that warn the user that the resulting binaries
are unusable as-is.
> > > > As you can see the rockchip LPDDR4 driver send by Jagan, has 99 patches
> > > > in V2, you can't use static register configuration to do this, and maybe you
> > > > can't have a workable version if rockchip don't release it, but I don't
> > > > think it's
> > > > correct to make all those boards with lpddr4 float outside the mainline
> > > > support
> > > > because many developers are using the boards, they can only use vendor
> > > > branch
> > > > if the board not support by mainline.
> > > If mainline U-Boot can't support basic bootloader features such as DRAM
> > > initialization for these boards, I don't see the point in accepting
> > > support for them.
>
> Hmm, actually I see ddr-init as one of the more difficult parts to achieve
> at least if you're not the soc-vendor, due to unavailable documentation
> or sources.
That is true, but I don't see this as a good reason to lower our
standards. Instead, I believe we should push for vendors to release
said source code and documentation, or for the community to reverse-
engineer DDR init.
Again, this is a less pragmatic approach but a more strategic and
political one. To me it's all about whether U-Boot as a project wants
to focus on technical aspects only and follow along on the political
side (which is not to say that it is politically neutral, the status
quo is very much a political stance) or if U-Boot wants to take a stand
here and use the power it has accumulated over the years to do things
right and push in the right direction.
> > > It would be like submitting support for a board in Linux with a new CPU
> > > that is not supported and asking to boot Linux via a non-free shim
> > > before Linux to put the CPU in a legacy state that Linux can support.
> > > This would definitely not be okay and I don't see why the same
> > > shouldn't apply to U-Boot.
>
> A less drastic example would be, submitting a basic devicetree to the
> linux kernel without clocks and pinctrl and relying on the things the
> bootloader set up for things like uart.
Agreed.
Cheers,
Paul
>
> Heiko
>
> > Linux build target is Image/zImage, if this Image not work with the board,
> > eg. hang somewhere during boot, then we say the board support is broken
> > and result in non-functional boot. And there always some kernel features
> > depends on bootloader setting, including security setting, some clock init,
> > some power supply and etc.
> >
> > > > So I think merge those patches already make board work on mainline U-Boot
> > > > is pretty important for open source community.
> > > I don't think the patches make the boards work on mainline U-Boot since
> > > building and installing the resulting U-Boot binaries will result in a
> > > non-functional boot chain and brick the device. I don't think this is a
> > > good or safe idea.
> >
> > In U-Boot, there are 2 or 3 standalone subsystem: U-Boot proper,
> > SPL, and TPL, and build target is u-boot.bin, u-boot-spl.bin, and
> > u-boot-tpl.bin.
> > If the standalone u-boot.bin or u-boot-spl.bin works good with a board and
> > able to boot into next stage correctly, I don't think these patches can
> > be consider
> > as "non-functional boot chain and brick the device". And for example for
> > armv8,
> > U-Boot is always as part of the boot chain.
> >
> > Thanks,
> > - Kever
> > > Cheers,
> > >
> > > Paul
> > >
> > > > Thanks,
> > > > - Kever
> > > > > Frankly, I don't think that would help. It would just drive more
> > > > > people to the vendor U-Boot that has more bugs and includes a vendor
> > > > > supplied ATF binary.
> > > > >
> > > > > > > I'm not sure if you have write a new dram driver for a board, but I know
> > > > > > > even the board vendor may not have the capability to write the DRAM
> > > > > > > driver, so this should not stop developers contribute to all other 99%
> > > > > > > features on U-Boot.
> > > > > > What they can do is run the non-free blob, dump the registers
> > > > > > afterwards and then use that in the DRAM configuration dtsi. Perhaps
> > > > > > one could write up a tool to ease the process if they think the process
> > > > > > is too much for a regular bringup.
> > > > > >
> > > > > > Most of the time, the DRAM chips are soldered so the calibrated values
> > > > > > have about no reason to change over time and can just be kept as-is.
> > > > > >
> > > > > > What do you think?
> > > > > Hopefully the pending diff to add support for other DRAM types beyond
> > > > > those that are already supported would make bring us a long way in
> > > > > that direction. Maybe one of the existing timings will already work
> > > > > for the boards that are being discussed here.
> > > > >
> >
> >
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> >
>
>
>
--
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] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-21 11:58 ` Paul Kocialkowski
0 siblings, 0 replies; 43+ messages in thread
From: Paul Kocialkowski @ 2019-06-21 11:58 UTC (permalink / raw)
To: u-boot
Hi,
On Fri, 2019-06-21 at 13:34 +0200, Heiko Stuebner wrote:
> Hi,
>
> Am Donnerstag, 20. Juni 2019, 05:24:32 CEST schrieb Kever Yang:
> > On 06/20/2019 12:54 AM, Paul Kocialkowski wrote:
> > > Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
> > > > On 06/19/2019 12:12 AM, Mark Kettenis wrote:
> > > > > > From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > > > > > Date: Tue, 18 Jun 2019 14:47:33 +0200
> > > > > > On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> > > > > > > On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > > > > > > > On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > > > > > > > On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > > > > > > > > <paul.kocialkowski@bootlin.com> wrote:
> > > > > > > > > > On Mon, 2019-06-17 at 15:24 +0800, xieqinick at gmail.com wrote:
> > > > > > > > > > > From: Nick Xie <nick@khadas.com>
> > > > > > > > > > Was this tested with SPL support? I don't see DRAM configuration here
> > > > > > > > > > so it seems that it relies on the non-free rockchip loader.
> > > > > > > > > >
> > > > > > > > > > If that is the case, could you please indicate that in the commit
> > > > > > > > > > message?
> > > > > > > > > >
> > > > > > > > > > To maintainers: please do not merge this series before DRAM init and
> > > > > > > > > > SPL support is available for these boards.
> > > > > > > > > >
> > > > > > > > > > It seems that other RK3399 boards were merged without SPL support and
> > > > > > > > > > sofar, I have the feeling that nobody cared to explain how we got into
> > > > > > > > > > this broken situation. Please don't merge any more such board.
> > > > > > > > > fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > > > > > > > > with TPL-enabled (which was discussed on the threads, if you remember)
> > > > > > > > > with below boot chain.
> > > > > > > > >
> > > > > > > > > rkbin (TPL) -> SPL -> U-Boot proper
> > > > > > > > >
> > > > > > > > > Same case for this board as well.
> > > > > > > > Here is a quote from Philipp Tomsich on the thread we discussed this:
> > > > > > > >
> > > > > > > > " On some boards, there will be no TPL and only a SPL stage that will
> > > > > > > > initialise DRAM (as the move to having TPL on the RK3399 is optional).
> > > > > > > >
> > > > > > > > I agree with Paul that the DRAM init should be part of U-Boot whenever
> > > > > > > > we add new boards and make an open DRAM init a prerequisite. "
> > > > > > > >
> > > > > > > > So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > > > > > > > that no board should be merged without proper DRAM init.
> > > > > > > >
> > > > > > > > Please stop pushing for merging these boards. I'm not sure what we
> > > > > > > > should do about the boards that were merged already without DRAM init,
> > > > > > > > but maybe they should be reverted.
> > > > > > > I don't think we have to have full DRAM init source code for each
> > > > > > > board before we can merge it, I believe most of the board on U-Boot
> > > > > > > mainline need to removed due to this rule. There are so many boards
> > > > > > > from different vendor need a binary loader before U-Boot, and I can
> > > > > > > see only very few drivers for dram at driver/ram/, and I believe rockchip
> > > > > > > is already the most open vendor on this area.
> > > > > > Well, I am not talking about full DRAM init source code as in dynamic
> > > > > > link training. I am talking about having at least static DRAM register
> > > > > > configuration values,
> > > > I can tell you that this is no work for all the boards, you can see how
> > > > rockchip lpddr4(WIP, send by Jagan) driver works.
> > > I thought that LPDDR4 works the same as other types of DRAM where we
> > > have a dtsi array with timings configuration. Of course, some more
> > > registers need to be set up, but we already have support for that or
> > > it's quite close (for LPDDR4).
> > > > > > which is present for a good number of rockchip
> > > > > > boards.
> > > > No, there is no rockchip board only have static DRAM register
> > > > configuration values, that maybe happens in other vendor.
> > > I was implying that, as far as I know, it is the case for DRAM timings
> > > on Rockchip as well as most of the platforms that I know of. In the
> > > end, any code handling DRAM will end up writing timings to the
> > > controller's registers. If the DRAM is part of the PCB and doesn't
> > > change/move, then the timings don't change in particular.
> > >
> > > Is there something specific about Rockchip that makes it require
> > > different DRAM timings at each boot?
> > > > > > Of course, it would be best if Rockchip would consider releasing this
> > > > > > source code,
> > > > Rockchip already release all the DRAM init source code, including DDR3 ,
> > > > LPDDR3,
> > > > and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
> > > > everything,
> > > > which is not only static register configuration.
> > > > As I have said, rockchip is already the most open vendor in this area
> > > > till now, I don't know
> > > > if you have working on rockchip SoC based boards.
> > > You are quite right about that, but I was thinking about the code to
> > > calculate DRAM timings (with link-training and such) which is often not
> > > available as free software, and I am not aware of Rockchip having
> > > released that code (but feel free to correct me if I'm wrong).
> > >
> > > > > > which would be the easiest and friendliest solution
> > > > > > towards the community here. Are there internal discussions ongoing
> > > > > > about this? If not, it would be greatly appreciated to start such
> > > > > > discussions and clearly identify what the blocking points are.
> > > > > >
> > > > > > > I won't use this rule to stop developers contribute there source code,
> > > > > > This is really sad and I think that Philipp was, like me, inclined to
> > > > > > go towards the other direction.
> > > > > >
> > > > > > > for a board support, we only need the board to have the full documentation
> > > > > > > about how to setup and boot with upstream U-Boot. and I think the
> > > > > > > most of people cares more about features in U-Boot proper. Everything
> > > > > > > before U-Boot proper, you can use TPL/SPL or alternative to use binary
> > > > > > > from vendor, as you can see all over the U-Boot mainline now, although
> > > > > > > we encourage people to use full open source TPL/SPL.
> > > > > > > Specifically for U-Boot Rockchip platform, I would like people to
> > > > > > > support not only U-Boot
> > > > > > > proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> > > > > > > features)
> > > > > > > support. And for DRAM init,
> > > > > > > - if this belongs to SPL for this board, you must implement it or else
> > > > > > > SPL won't work;
> > > > > > > - if this does not belong to SPL for this board, you need implement full
> > > > > > > function SPL;
> > > > > > > and you can either to have full function TPL with DRAM init(which is
> > > > > > > prefered)
> > > > > > > or alternatively use binary loader from vendor.
> > > > > > This is not really a technical argument here, more of a policy argument
> > > > > > that ensures we have full free software support for the boards we
> > > > > > support, and not only half-cooked support (that will most likely never
> > > > > > be completed as soon as something that works gets merged). So it is a
> > > > > > strategical decision, not a strictly pragmatic one.
> > > > > While having full open source software support for boards is a noble
> > > > > goal, I think there should be some room for pragmatism here. A
> > > > > significant number of u_boot targets rely on closed source components.
> > > > > In the particular case of RK3399 the situation is better than for
> > > > > other boards since you can combine the binary loader from the vendor
> > > > > with mainline U-Boot and mainline ATF to create a firmware where (as
> > > > > far as we can tell) no closed soure component remains active after
> > > > > U-Boot and ATF take over control.
> > > > >
> > > > > > I think reverting patches adding support for boards with no DRAM
> > > > > > configuration at all would send a message in the right direction here.
> > > > As a developer, I agree on this, but as a maintainer, I know too many
> > > > developers not able to do it and what most of developers need is other
> > > > features in U-Boot or SPL, and I would like the U-Boot mainline is more
> > > > active with more and more developers. So I'm afraid I agree with Mark
> > > > at this time for the policy.
> > > Maybe we need to provide tools ot make that process easier for everyone
> > > if it is really that hard. I don't really see what is so special about
> > > DRAM timings that would imply that a regular developer doing a U-Boot
> > > bringup couldn't figure things out, aside from the ability to dump said
> > > timings.
> > >
> > > > If all the other SoC platforms can have the same rule for DRAM init driver
> > > > is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
> > > > imx, aml, and all others, then I would very happy to follow the rule.
> > > > Rockchip is open for open source the DRAM driver, you have to know this
> > > > is the decision by the vendor, but not any of developers.
> > > > On rockchip platform, developers no need to concern about the DRAM
> > > > driver(which is pretty hard for most developers) because rockchip
> > > > already contribute it.
> > > Rockchip is indeed in a better position than other vendors where DRAM
> > > init may not be available (or when it's impossible to run U-Boot right
> > > after the bootrom and do the DRAM init itself because of e.g. abusive
> > > signature verification or lack of documentation).
> > >
> > > Since there is good DRAM support for Rockchip in place, we have an
> > > opportunity to push developers to do the right thing and contribute
> > > full support for the board. To me it is simply a matter of
> > > acknowledging that bootloader support for a board without DRAM init is
> > > not useful bootloader support. Since we have the code in place to
> > > support that, we can take the extra step and require that each board
> > > contribution be useful in that aspect.
> > >
> > > > For the time now, I know there will be full DRAM driver for rockchip SoC,
> > > > so the SoC/board support could be step by step:
> > > > U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
>
> Keeping allowing a step-by-step approach could be beneficial I think,
> in the kernel we also don't require full support for all peripherals on
> initial submission ;-) .
To be fair, I'm not suggesting that either, I'm only concerned about
DRAM init which I wouldn't put under "any feature/controller" but one
of the basic things that are required to make bootloader support
useful.
> And also for people starting out on a specific board having at least partial
> support is way easier than trying to figure out for example the vendor
> u-boot.
Fair enough, but it can also bring some confusion if support is not
clearly identified as being partial. Hence my point about inadvertently
bricking devices if U-Boot alone is sufficient to boot on some rk3399
devices but if it's not on some other ones.
> Maybe we could give this some sort of time limitation like
> "binary ddr-init allowed till 2019-10-31" in Kconfig or somewhere
> to give people the chance to do things piece by piece but still force them
> to actually work on improving the situation.
This sounds like a prefectly reasonable compromise to me :)
> As driver-side changes will generally benefit more socs/boards potential
> removal after the time limit would only affect the board+dts itself.
And it's also a good thing to keep that support around in the history.
> So somewhat similar to what the kernel does with "staging", if you
> keep working on improving it, it is allowed to stay.
>
> This could be also applied to already included boards, like
> "give it a working ddr-init till 2019-12-31 or it gets removed", similarly
> to how Tom handles devicemanager conversions currently
Agreed and I would like to suggest some clear way of marking the boards
as partially supported, for instance a warning message (like we show on
numerous other topics) that warn the user that the resulting binaries
are unusable as-is.
> > > > As you can see the rockchip LPDDR4 driver send by Jagan, has 99 patches
> > > > in V2, you can't use static register configuration to do this, and maybe you
> > > > can't have a workable version if rockchip don't release it, but I don't
> > > > think it's
> > > > correct to make all those boards with lpddr4 float outside the mainline
> > > > support
> > > > because many developers are using the boards, they can only use vendor
> > > > branch
> > > > if the board not support by mainline.
> > > If mainline U-Boot can't support basic bootloader features such as DRAM
> > > initialization for these boards, I don't see the point in accepting
> > > support for them.
>
> Hmm, actually I see ddr-init as one of the more difficult parts to achieve
> at least if you're not the soc-vendor, due to unavailable documentation
> or sources.
That is true, but I don't see this as a good reason to lower our
standards. Instead, I believe we should push for vendors to release
said source code and documentation, or for the community to reverse-
engineer DDR init.
Again, this is a less pragmatic approach but a more strategic and
political one. To me it's all about whether U-Boot as a project wants
to focus on technical aspects only and follow along on the political
side (which is not to say that it is politically neutral, the status
quo is very much a political stance) or if U-Boot wants to take a stand
here and use the power it has accumulated over the years to do things
right and push in the right direction.
> > > It would be like submitting support for a board in Linux with a new CPU
> > > that is not supported and asking to boot Linux via a non-free shim
> > > before Linux to put the CPU in a legacy state that Linux can support.
> > > This would definitely not be okay and I don't see why the same
> > > shouldn't apply to U-Boot.
>
> A less drastic example would be, submitting a basic devicetree to the
> linux kernel without clocks and pinctrl and relying on the things the
> bootloader set up for things like uart.
Agreed.
Cheers,
Paul
>
> Heiko
>
> > Linux build target is Image/zImage, if this Image not work with the board,
> > eg. hang somewhere during boot, then we say the board support is broken
> > and result in non-functional boot. And there always some kernel features
> > depends on bootloader setting, including security setting, some clock init,
> > some power supply and etc.
> >
> > > > So I think merge those patches already make board work on mainline U-Boot
> > > > is pretty important for open source community.
> > > I don't think the patches make the boards work on mainline U-Boot since
> > > building and installing the resulting U-Boot binaries will result in a
> > > non-functional boot chain and brick the device. I don't think this is a
> > > good or safe idea.
> >
> > In U-Boot, there are 2 or 3 standalone subsystem: U-Boot proper,
> > SPL, and TPL, and build target is u-boot.bin, u-boot-spl.bin, and
> > u-boot-tpl.bin.
> > If the standalone u-boot.bin or u-boot-spl.bin works good with a board and
> > able to boot into next stage correctly, I don't think these patches can
> > be consider
> > as "non-functional boot chain and brick the device". And for example for
> > armv8,
> > U-Boot is always as part of the boot chain.
> >
> > Thanks,
> > - Kever
> > > Cheers,
> > >
> > > Paul
> > >
> > > > Thanks,
> > > > - Kever
> > > > > Frankly, I don't think that would help. It would just drive more
> > > > > people to the vendor U-Boot that has more bugs and includes a vendor
> > > > > supplied ATF binary.
> > > > >
> > > > > > > I'm not sure if you have write a new dram driver for a board, but I know
> > > > > > > even the board vendor may not have the capability to write the DRAM
> > > > > > > driver, so this should not stop developers contribute to all other 99%
> > > > > > > features on U-Boot.
> > > > > > What they can do is run the non-free blob, dump the registers
> > > > > > afterwards and then use that in the DRAM configuration dtsi. Perhaps
> > > > > > one could write up a tool to ease the process if they think the process
> > > > > > is too much for a regular bringup.
> > > > > >
> > > > > > Most of the time, the DRAM chips are soldered so the calibrated values
> > > > > > have about no reason to change over time and can just be kept as-is.
> > > > > >
> > > > > > What do you think?
> > > > > Hopefully the pending diff to add support for other DRAM types beyond
> > > > > those that are already supported would make bring us a long way in
> > > > > that direction. Maybe one of the existing timings will already work
> > > > > for the boards that are being discussed here.
> > > > >
> >
> >
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
> >
>
>
>
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-21 11:34 ` Heiko Stuebner
@ 2019-06-21 12:52 ` Mark Kettenis
-1 siblings, 0 replies; 43+ messages in thread
From: Mark Kettenis @ 2019-06-21 12:52 UTC (permalink / raw)
To: Heiko Stuebner
Cc: linux-rockchip, maxime.ripard, u-boot, nick, linux-amarula, xieqinick
> From: Heiko Stuebner <heiko@sntech.de>
> Date: Fri, 21 Jun 2019 13:34:16 +0200
>
> Hi,
>
> Am Donnerstag, 20. Juni 2019, 05:24:32 CEST schrieb Kever Yang:
> > On 06/20/2019 12:54 AM, Paul Kocialkowski wrote:
> > > Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
> > >> On 06/19/2019 12:12 AM, Mark Kettenis wrote:
> > >>>> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > >>>> Date: Tue, 18 Jun 2019 14:47:33 +0200
> > >>>> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> > >>>>> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > >>>>>> On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > >>>>>>> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > >>>>>>> <paul.kocialkowski@bootlin.com> wrote:
> > >>>>>>>> On Mon, 2019-06-17 at 15:24 +0800, xieqinick@gmail.com wrote:
> > >>>>>>>>> From: Nick Xie <nick@khadas.com>
> > >>>>>>>> Was this tested with SPL support? I don't see DRAM configuration here
> > >>>>>>>> so it seems that it relies on the non-free rockchip loader.
> > >>>>>>>>
> > >>>>>>>> If that is the case, could you please indicate that in the commit
> > >>>>>>>> message?
> > >>>>>>>>
> > >>>>>>>> To maintainers: please do not merge this series before DRAM init and
> > >>>>>>>> SPL support is available for these boards.
> > >>>>>>>>
> > >>>>>>>> It seems that other RK3399 boards were merged without SPL support and
> > >>>>>>>> sofar, I have the feeling that nobody cared to explain how we got into
> > >>>>>>>> this broken situation. Please don't merge any more such board.
> > >>>>>>> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > >>>>>>> with TPL-enabled (which was discussed on the threads, if you remember)
> > >>>>>>> with below boot chain.
> > >>>>>>>
> > >>>>>>> rkbin (TPL) -> SPL -> U-Boot proper
> > >>>>>>>
> > >>>>>>> Same case for this board as well.
> > >>>>>> Here is a quote from Philipp Tomsich on the thread we discussed this:
> > >>>>>>
> > >>>>>> " On some boards, there will be no TPL and only a SPL stage that will
> > >>>>>> initialise DRAM (as the move to having TPL on the RK3399 is optional).
> > >>>>>>
> > >>>>>> I agree with Paul that the DRAM init should be part of U-Boot whenever
> > >>>>>> we add new boards and make an open DRAM init a prerequisite. "
> > >>>>>>
> > >>>>>> So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > >>>>>> that no board should be merged without proper DRAM init.
> > >>>>>>
> > >>>>>> Please stop pushing for merging these boards. I'm not sure what we
> > >>>>>> should do about the boards that were merged already without DRAM init,
> > >>>>>> but maybe they should be reverted.
>
> > >>>>> I don't think we have to have full DRAM init source code for each
> > >>>>> board before we can merge it, I believe most of the board on U-Boot
> > >>>>> mainline need to removed due to this rule. There are so many boards
> > >>>>> from different vendor need a binary loader before U-Boot, and I can
> > >>>>> see only very few drivers for dram at driver/ram/, and I believe rockchip
> > >>>>> is already the most open vendor on this area.
>
> > >>>> Well, I am not talking about full DRAM init source code as in dynamic
> > >>>> link training. I am talking about having at least static DRAM register
> > >>>> configuration values,
>
> > >> I can tell you that this is no work for all the boards, you can see how
> > >> rockchip lpddr4(WIP, send by Jagan) driver works.
>
> > > I thought that LPDDR4 works the same as other types of DRAM where we
> > > have a dtsi array with timings configuration. Of course, some more
> > > registers need to be set up, but we already have support for that or
> > > it's quite close (for LPDDR4).
> >
> > >>>> which is present for a good number of rockchip
> > >>>> boards.
> > >> No, there is no rockchip board only have static DRAM register
> > >> configuration values, that maybe happens in other vendor.
> >
> > > I was implying that, as far as I know, it is the case for DRAM timings
> > > on Rockchip as well as most of the platforms that I know of. In the
> > > end, any code handling DRAM will end up writing timings to the
> > > controller's registers. If the DRAM is part of the PCB and doesn't
> > > change/move, then the timings don't change in particular.
> > >
> > > Is there something specific about Rockchip that makes it require
> > > different DRAM timings at each boot?
> >
> > >>>> Of course, it would be best if Rockchip would consider releasing this
> > >>>> source code,
> > >> Rockchip already release all the DRAM init source code, including DDR3 ,
> > >> LPDDR3,
> > >> and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
> > >> everything,
> > >> which is not only static register configuration.
> > >> As I have said, rockchip is already the most open vendor in this area
> > >> till now, I don't know
> > >> if you have working on rockchip SoC based boards.
> > > You are quite right about that, but I was thinking about the code to
> > > calculate DRAM timings (with link-training and such) which is often not
> > > available as free software, and I am not aware of Rockchip having
> > > released that code (but feel free to correct me if I'm wrong).
> > >
> > >>>> which would be the easiest and friendliest solution
> > >>>> towards the community here. Are there internal discussions ongoing
> > >>>> about this? If not, it would be greatly appreciated to start such
> > >>>> discussions and clearly identify what the blocking points are.
> > >>>>
> > >>>>> I won't use this rule to stop developers contribute there source code,
> > >>>> This is really sad and I think that Philipp was, like me, inclined to
> > >>>> go towards the other direction.
> > >>>>
> > >>>>> for a board support, we only need the board to have the full documentation
> > >>>>> about how to setup and boot with upstream U-Boot. and I think the
> > >>>>> most of people cares more about features in U-Boot proper. Everything
> > >>>>> before U-Boot proper, you can use TPL/SPL or alternative to use binary
> > >>>>> from vendor, as you can see all over the U-Boot mainline now, although
> > >>>>> we encourage people to use full open source TPL/SPL.
> > >>>>> Specifically for U-Boot Rockchip platform, I would like people to
> > >>>>> support not only U-Boot
> > >>>>> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> > >>>>> features)
> > >>>>> support. And for DRAM init,
> > >>>>> - if this belongs to SPL for this board, you must implement it or else
> > >>>>> SPL won't work;
> > >>>>> - if this does not belong to SPL for this board, you need implement full
> > >>>>> function SPL;
> > >>>>> and you can either to have full function TPL with DRAM init(which is
> > >>>>> prefered)
> > >>>>> or alternatively use binary loader from vendor.
> > >>>> This is not really a technical argument here, more of a policy argument
> > >>>> that ensures we have full free software support for the boards we
> > >>>> support, and not only half-cooked support (that will most likely never
> > >>>> be completed as soon as something that works gets merged). So it is a
> > >>>> strategical decision, not a strictly pragmatic one.
>
> > >>> While having full open source software support for boards is a noble
> > >>> goal, I think there should be some room for pragmatism here. A
> > >>> significant number of u_boot targets rely on closed source components.
> > >>> In the particular case of RK3399 the situation is better than for
> > >>> other boards since you can combine the binary loader from the vendor
> > >>> with mainline U-Boot and mainline ATF to create a firmware where (as
> > >>> far as we can tell) no closed soure component remains active after
> > >>> U-Boot and ATF take over control.
> > >>>
> > >>>> I think reverting patches adding support for boards with no DRAM
> > >>>> configuration at all would send a message in the right direction here.
> > >> As a developer, I agree on this, but as a maintainer, I know too many
> > >> developers not able to do it and what most of developers need is other
> > >> features in U-Boot or SPL, and I would like the U-Boot mainline is more
> > >> active with more and more developers. So I'm afraid I agree with Mark
> > >> at this time for the policy.
> > > Maybe we need to provide tools ot make that process easier for everyone
> > > if it is really that hard. I don't really see what is so special about
> > > DRAM timings that would imply that a regular developer doing a U-Boot
> > > bringup couldn't figure things out, aside from the ability to dump said
> > > timings.
> > >
> > >> If all the other SoC platforms can have the same rule for DRAM init driver
> > >> is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
> > >> imx, aml, and all others, then I would very happy to follow the rule.
> > >> Rockchip is open for open source the DRAM driver, you have to know this
> > >> is the decision by the vendor, but not any of developers.
> > >> On rockchip platform, developers no need to concern about the DRAM
> > >> driver(which is pretty hard for most developers) because rockchip
> > >> already contribute it.
> > > Rockchip is indeed in a better position than other vendors where DRAM
> > > init may not be available (or when it's impossible to run U-Boot right
> > > after the bootrom and do the DRAM init itself because of e.g. abusive
> > > signature verification or lack of documentation).
> > >
> > > Since there is good DRAM support for Rockchip in place, we have an
> > > opportunity to push developers to do the right thing and contribute
> > > full support for the board. To me it is simply a matter of
> > > acknowledging that bootloader support for a board without DRAM init is
> > > not useful bootloader support. Since we have the code in place to
> > > support that, we can take the extra step and require that each board
> > > contribution be useful in that aspect.
> > >
> > >> For the time now, I know there will be full DRAM driver for rockchip SoC,
> > >> so the SoC/board support could be step by step:
> > >> U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
>
> Keeping allowing a step-by-step approach could be beneficial I think,
> in the kernel we also don't require full support for all peripherals on
> initial submission ;-) .
>
> And also for people starting out on a specific board having at least partial
> support is way easier than trying to figure out for example the vendor
> u-boot.
>
> Maybe we could give this some sort of time limitation like
> "binary ddr-init allowed till 2019-10-31" in Kconfig or somewhere
> to give people the chance to do things piece by piece but still force them
> to actually work on improving the situation.
>
> As driver-side changes will generally benefit more socs/boards potential
> removal after the time limit would only affect the board+dts itself.
>
> So somewhat similar to what the kernel does with "staging", if you
> keep working on improving it, it is allowed to stay.
>
> This could be also applied to already included boards, like
> "give it a working ddr-init till 2019-12-31 or it gets removed", similarly
> to how Tom handles devicemanager conversions currently
Still doesn't make sense to me unless you're going to enforce such a
rule for all included boards that lack usable open-source DRAM
initialization code. Otherwise you're just punishing Rockchip for
having a partial DRAM initialization code and are potentially sending
the message that it's better not to attempt create open source DRAM
drivers.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-21 12:52 ` Mark Kettenis
0 siblings, 0 replies; 43+ messages in thread
From: Mark Kettenis @ 2019-06-21 12:52 UTC (permalink / raw)
To: u-boot
> From: Heiko Stuebner <heiko@sntech.de>
> Date: Fri, 21 Jun 2019 13:34:16 +0200
>
> Hi,
>
> Am Donnerstag, 20. Juni 2019, 05:24:32 CEST schrieb Kever Yang:
> > On 06/20/2019 12:54 AM, Paul Kocialkowski wrote:
> > > Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
> > >> On 06/19/2019 12:12 AM, Mark Kettenis wrote:
> > >>>> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > >>>> Date: Tue, 18 Jun 2019 14:47:33 +0200
> > >>>> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> > >>>>> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > >>>>>> On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > >>>>>>> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > >>>>>>> <paul.kocialkowski@bootlin.com> wrote:
> > >>>>>>>> On Mon, 2019-06-17 at 15:24 +0800, xieqinick at gmail.com wrote:
> > >>>>>>>>> From: Nick Xie <nick@khadas.com>
> > >>>>>>>> Was this tested with SPL support? I don't see DRAM configuration here
> > >>>>>>>> so it seems that it relies on the non-free rockchip loader.
> > >>>>>>>>
> > >>>>>>>> If that is the case, could you please indicate that in the commit
> > >>>>>>>> message?
> > >>>>>>>>
> > >>>>>>>> To maintainers: please do not merge this series before DRAM init and
> > >>>>>>>> SPL support is available for these boards.
> > >>>>>>>>
> > >>>>>>>> It seems that other RK3399 boards were merged without SPL support and
> > >>>>>>>> sofar, I have the feeling that nobody cared to explain how we got into
> > >>>>>>>> this broken situation. Please don't merge any more such board.
> > >>>>>>> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > >>>>>>> with TPL-enabled (which was discussed on the threads, if you remember)
> > >>>>>>> with below boot chain.
> > >>>>>>>
> > >>>>>>> rkbin (TPL) -> SPL -> U-Boot proper
> > >>>>>>>
> > >>>>>>> Same case for this board as well.
> > >>>>>> Here is a quote from Philipp Tomsich on the thread we discussed this:
> > >>>>>>
> > >>>>>> " On some boards, there will be no TPL and only a SPL stage that will
> > >>>>>> initialise DRAM (as the move to having TPL on the RK3399 is optional).
> > >>>>>>
> > >>>>>> I agree with Paul that the DRAM init should be part of U-Boot whenever
> > >>>>>> we add new boards and make an open DRAM init a prerequisite. "
> > >>>>>>
> > >>>>>> So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > >>>>>> that no board should be merged without proper DRAM init.
> > >>>>>>
> > >>>>>> Please stop pushing for merging these boards. I'm not sure what we
> > >>>>>> should do about the boards that were merged already without DRAM init,
> > >>>>>> but maybe they should be reverted.
>
> > >>>>> I don't think we have to have full DRAM init source code for each
> > >>>>> board before we can merge it, I believe most of the board on U-Boot
> > >>>>> mainline need to removed due to this rule. There are so many boards
> > >>>>> from different vendor need a binary loader before U-Boot, and I can
> > >>>>> see only very few drivers for dram at driver/ram/, and I believe rockchip
> > >>>>> is already the most open vendor on this area.
>
> > >>>> Well, I am not talking about full DRAM init source code as in dynamic
> > >>>> link training. I am talking about having at least static DRAM register
> > >>>> configuration values,
>
> > >> I can tell you that this is no work for all the boards, you can see how
> > >> rockchip lpddr4(WIP, send by Jagan) driver works.
>
> > > I thought that LPDDR4 works the same as other types of DRAM where we
> > > have a dtsi array with timings configuration. Of course, some more
> > > registers need to be set up, but we already have support for that or
> > > it's quite close (for LPDDR4).
> >
> > >>>> which is present for a good number of rockchip
> > >>>> boards.
> > >> No, there is no rockchip board only have static DRAM register
> > >> configuration values, that maybe happens in other vendor.
> >
> > > I was implying that, as far as I know, it is the case for DRAM timings
> > > on Rockchip as well as most of the platforms that I know of. In the
> > > end, any code handling DRAM will end up writing timings to the
> > > controller's registers. If the DRAM is part of the PCB and doesn't
> > > change/move, then the timings don't change in particular.
> > >
> > > Is there something specific about Rockchip that makes it require
> > > different DRAM timings at each boot?
> >
> > >>>> Of course, it would be best if Rockchip would consider releasing this
> > >>>> source code,
> > >> Rockchip already release all the DRAM init source code, including DDR3 ,
> > >> LPDDR3,
> > >> and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
> > >> everything,
> > >> which is not only static register configuration.
> > >> As I have said, rockchip is already the most open vendor in this area
> > >> till now, I don't know
> > >> if you have working on rockchip SoC based boards.
> > > You are quite right about that, but I was thinking about the code to
> > > calculate DRAM timings (with link-training and such) which is often not
> > > available as free software, and I am not aware of Rockchip having
> > > released that code (but feel free to correct me if I'm wrong).
> > >
> > >>>> which would be the easiest and friendliest solution
> > >>>> towards the community here. Are there internal discussions ongoing
> > >>>> about this? If not, it would be greatly appreciated to start such
> > >>>> discussions and clearly identify what the blocking points are.
> > >>>>
> > >>>>> I won't use this rule to stop developers contribute there source code,
> > >>>> This is really sad and I think that Philipp was, like me, inclined to
> > >>>> go towards the other direction.
> > >>>>
> > >>>>> for a board support, we only need the board to have the full documentation
> > >>>>> about how to setup and boot with upstream U-Boot. and I think the
> > >>>>> most of people cares more about features in U-Boot proper. Everything
> > >>>>> before U-Boot proper, you can use TPL/SPL or alternative to use binary
> > >>>>> from vendor, as you can see all over the U-Boot mainline now, although
> > >>>>> we encourage people to use full open source TPL/SPL.
> > >>>>> Specifically for U-Boot Rockchip platform, I would like people to
> > >>>>> support not only U-Boot
> > >>>>> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> > >>>>> features)
> > >>>>> support. And for DRAM init,
> > >>>>> - if this belongs to SPL for this board, you must implement it or else
> > >>>>> SPL won't work;
> > >>>>> - if this does not belong to SPL for this board, you need implement full
> > >>>>> function SPL;
> > >>>>> and you can either to have full function TPL with DRAM init(which is
> > >>>>> prefered)
> > >>>>> or alternatively use binary loader from vendor.
> > >>>> This is not really a technical argument here, more of a policy argument
> > >>>> that ensures we have full free software support for the boards we
> > >>>> support, and not only half-cooked support (that will most likely never
> > >>>> be completed as soon as something that works gets merged). So it is a
> > >>>> strategical decision, not a strictly pragmatic one.
>
> > >>> While having full open source software support for boards is a noble
> > >>> goal, I think there should be some room for pragmatism here. A
> > >>> significant number of u_boot targets rely on closed source components.
> > >>> In the particular case of RK3399 the situation is better than for
> > >>> other boards since you can combine the binary loader from the vendor
> > >>> with mainline U-Boot and mainline ATF to create a firmware where (as
> > >>> far as we can tell) no closed soure component remains active after
> > >>> U-Boot and ATF take over control.
> > >>>
> > >>>> I think reverting patches adding support for boards with no DRAM
> > >>>> configuration at all would send a message in the right direction here.
> > >> As a developer, I agree on this, but as a maintainer, I know too many
> > >> developers not able to do it and what most of developers need is other
> > >> features in U-Boot or SPL, and I would like the U-Boot mainline is more
> > >> active with more and more developers. So I'm afraid I agree with Mark
> > >> at this time for the policy.
> > > Maybe we need to provide tools ot make that process easier for everyone
> > > if it is really that hard. I don't really see what is so special about
> > > DRAM timings that would imply that a regular developer doing a U-Boot
> > > bringup couldn't figure things out, aside from the ability to dump said
> > > timings.
> > >
> > >> If all the other SoC platforms can have the same rule for DRAM init driver
> > >> is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
> > >> imx, aml, and all others, then I would very happy to follow the rule.
> > >> Rockchip is open for open source the DRAM driver, you have to know this
> > >> is the decision by the vendor, but not any of developers.
> > >> On rockchip platform, developers no need to concern about the DRAM
> > >> driver(which is pretty hard for most developers) because rockchip
> > >> already contribute it.
> > > Rockchip is indeed in a better position than other vendors where DRAM
> > > init may not be available (or when it's impossible to run U-Boot right
> > > after the bootrom and do the DRAM init itself because of e.g. abusive
> > > signature verification or lack of documentation).
> > >
> > > Since there is good DRAM support for Rockchip in place, we have an
> > > opportunity to push developers to do the right thing and contribute
> > > full support for the board. To me it is simply a matter of
> > > acknowledging that bootloader support for a board without DRAM init is
> > > not useful bootloader support. Since we have the code in place to
> > > support that, we can take the extra step and require that each board
> > > contribution be useful in that aspect.
> > >
> > >> For the time now, I know there will be full DRAM driver for rockchip SoC,
> > >> so the SoC/board support could be step by step:
> > >> U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
>
> Keeping allowing a step-by-step approach could be beneficial I think,
> in the kernel we also don't require full support for all peripherals on
> initial submission ;-) .
>
> And also for people starting out on a specific board having at least partial
> support is way easier than trying to figure out for example the vendor
> u-boot.
>
> Maybe we could give this some sort of time limitation like
> "binary ddr-init allowed till 2019-10-31" in Kconfig or somewhere
> to give people the chance to do things piece by piece but still force them
> to actually work on improving the situation.
>
> As driver-side changes will generally benefit more socs/boards potential
> removal after the time limit would only affect the board+dts itself.
>
> So somewhat similar to what the kernel does with "staging", if you
> keep working on improving it, it is allowed to stay.
>
> This could be also applied to already included boards, like
> "give it a working ddr-init till 2019-12-31 or it gets removed", similarly
> to how Tom handles devicemanager conversions currently
Still doesn't make sense to me unless you're going to enforce such a
rule for all included boards that lack usable open-source DRAM
initialization code. Otherwise you're just punishing Rockchip for
having a partial DRAM initialization code and are potentially sending
the message that it's better not to attempt create open source DRAM
drivers.
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-21 12:52 ` [U-Boot] " Mark Kettenis
@ 2019-06-21 13:05 ` Paul Kocialkowski
-1 siblings, 0 replies; 43+ messages in thread
From: Paul Kocialkowski @ 2019-06-21 13:05 UTC (permalink / raw)
To: Mark Kettenis, Heiko Stuebner
Cc: linux-rockchip, maxime.ripard, u-boot, nick, linux-amarula, xieqinick
Hi,
On Fri, 2019-06-21 at 14:52 +0200, Mark Kettenis wrote:
> > From: Heiko Stuebner <heiko@sntech.de>
> > Maybe we could give this some sort of time limitation like
> > "binary ddr-init allowed till 2019-10-31" in Kconfig or somewhere
> > to give people the chance to do things piece by piece but still force them
> > to actually work on improving the situation.
> >
> > As driver-side changes will generally benefit more socs/boards potential
> > removal after the time limit would only affect the board+dts itself.
> >
> > So somewhat similar to what the kernel does with "staging", if you
> > keep working on improving it, it is allowed to stay.
> >
> > This could be also applied to already included boards, like
> > "give it a working ddr-init till 2019-12-31 or it gets removed", similarly
> > to how Tom handles devicemanager conversions currently
>
> Still doesn't make sense to me unless you're going to enforce such a
> rule for all included boards that lack usable open-source DRAM
> initialization code. Otherwise you're just punishing Rockchip for
> having a partial DRAM initialization code and are potentially sending
> the message that it's better not to attempt create open source DRAM
> drivers.
I'm not following this at all. Rockchip has a particular situation
where almost all the boards have free DRAM init, which is not the case
on every platform. I don't see why this decision has to be harmonized
on the whole project since I believe it only makes sense for the
specific case of Rockchip.
Seeing this as some sort of punishment feels like a gross
misinterpretation of our intent. If we are clear and communicate about
the motivations why we think this is important and why this rule is
applied, then there is nothing we can do about mis-judgments. I don't
think it's fair or rational to not take action because of that.
Whatever we do, there is always a chance that people will mis-interpret
things and throw shit at us for taking political decisions. That's too
bad, but there is only so much we can do about that. And rest asured
that people (including myself) can also throw shit at the project for
maintaining a weak status-quo and not contribute to moving things
forward on political aspects when it is in a power position to do so.
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] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-21 13:05 ` Paul Kocialkowski
0 siblings, 0 replies; 43+ messages in thread
From: Paul Kocialkowski @ 2019-06-21 13:05 UTC (permalink / raw)
To: u-boot
Hi,
On Fri, 2019-06-21 at 14:52 +0200, Mark Kettenis wrote:
> > From: Heiko Stuebner <heiko@sntech.de>
> > Maybe we could give this some sort of time limitation like
> > "binary ddr-init allowed till 2019-10-31" in Kconfig or somewhere
> > to give people the chance to do things piece by piece but still force them
> > to actually work on improving the situation.
> >
> > As driver-side changes will generally benefit more socs/boards potential
> > removal after the time limit would only affect the board+dts itself.
> >
> > So somewhat similar to what the kernel does with "staging", if you
> > keep working on improving it, it is allowed to stay.
> >
> > This could be also applied to already included boards, like
> > "give it a working ddr-init till 2019-12-31 or it gets removed", similarly
> > to how Tom handles devicemanager conversions currently
>
> Still doesn't make sense to me unless you're going to enforce such a
> rule for all included boards that lack usable open-source DRAM
> initialization code. Otherwise you're just punishing Rockchip for
> having a partial DRAM initialization code and are potentially sending
> the message that it's better not to attempt create open source DRAM
> drivers.
I'm not following this at all. Rockchip has a particular situation
where almost all the boards have free DRAM init, which is not the case
on every platform. I don't see why this decision has to be harmonized
on the whole project since I believe it only makes sense for the
specific case of Rockchip.
Seeing this as some sort of punishment feels like a gross
misinterpretation of our intent. If we are clear and communicate about
the motivations why we think this is important and why this rule is
applied, then there is nothing we can do about mis-judgments. I don't
think it's fair or rational to not take action because of that.
Whatever we do, there is always a chance that people will mis-interpret
things and throw shit at us for taking political decisions. That's too
bad, but there is only so much we can do about that. And rest asured
that people (including myself) can also throw shit at the project for
maintaining a weak status-quo and not contribute to moving things
forward on political aspects when it is in a power position to do so.
Cheers,
Paul
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
2019-06-21 12:52 ` [U-Boot] " Mark Kettenis
@ 2019-06-21 13:08 ` Heiko Stuebner
-1 siblings, 0 replies; 43+ messages in thread
From: Heiko Stuebner @ 2019-06-21 13:08 UTC (permalink / raw)
To: Mark Kettenis
Cc: linux-rockchip, maxime.ripard, u-boot, nick, linux-amarula, xieqinick
Am Freitag, 21. Juni 2019, 14:52:17 CEST schrieb Mark Kettenis:
> > From: Heiko Stuebner <heiko@sntech.de>
> > Date: Fri, 21 Jun 2019 13:34:16 +0200
> >
> > Hi,
> >
> > Am Donnerstag, 20. Juni 2019, 05:24:32 CEST schrieb Kever Yang:
> > > On 06/20/2019 12:54 AM, Paul Kocialkowski wrote:
> > > > Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
> > > >> On 06/19/2019 12:12 AM, Mark Kettenis wrote:
> > > >>>> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > > >>>> Date: Tue, 18 Jun 2019 14:47:33 +0200
> > > >>>> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> > > >>>>> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > > >>>>>> On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > >>>>>>> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > > >>>>>>> <paul.kocialkowski@bootlin.com> wrote:
> > > >>>>>>>> On Mon, 2019-06-17 at 15:24 +0800, xieqinick@gmail.com wrote:
> > > >>>>>>>>> From: Nick Xie <nick@khadas.com>
> > > >>>>>>>> Was this tested with SPL support? I don't see DRAM configuration here
> > > >>>>>>>> so it seems that it relies on the non-free rockchip loader.
> > > >>>>>>>>
> > > >>>>>>>> If that is the case, could you please indicate that in the commit
> > > >>>>>>>> message?
> > > >>>>>>>>
> > > >>>>>>>> To maintainers: please do not merge this series before DRAM init and
> > > >>>>>>>> SPL support is available for these boards.
> > > >>>>>>>>
> > > >>>>>>>> It seems that other RK3399 boards were merged without SPL support and
> > > >>>>>>>> sofar, I have the feeling that nobody cared to explain how we got into
> > > >>>>>>>> this broken situation. Please don't merge any more such board.
> > > >>>>>>> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > > >>>>>>> with TPL-enabled (which was discussed on the threads, if you remember)
> > > >>>>>>> with below boot chain.
> > > >>>>>>>
> > > >>>>>>> rkbin (TPL) -> SPL -> U-Boot proper
> > > >>>>>>>
> > > >>>>>>> Same case for this board as well.
> > > >>>>>> Here is a quote from Philipp Tomsich on the thread we discussed this:
> > > >>>>>>
> > > >>>>>> " On some boards, there will be no TPL and only a SPL stage that will
> > > >>>>>> initialise DRAM (as the move to having TPL on the RK3399 is optional).
> > > >>>>>>
> > > >>>>>> I agree with Paul that the DRAM init should be part of U-Boot whenever
> > > >>>>>> we add new boards and make an open DRAM init a prerequisite. "
> > > >>>>>>
> > > >>>>>> So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > > >>>>>> that no board should be merged without proper DRAM init.
> > > >>>>>>
> > > >>>>>> Please stop pushing for merging these boards. I'm not sure what we
> > > >>>>>> should do about the boards that were merged already without DRAM init,
> > > >>>>>> but maybe they should be reverted.
> >
> > > >>>>> I don't think we have to have full DRAM init source code for each
> > > >>>>> board before we can merge it, I believe most of the board on U-Boot
> > > >>>>> mainline need to removed due to this rule. There are so many boards
> > > >>>>> from different vendor need a binary loader before U-Boot, and I can
> > > >>>>> see only very few drivers for dram at driver/ram/, and I believe rockchip
> > > >>>>> is already the most open vendor on this area.
> >
> > > >>>> Well, I am not talking about full DRAM init source code as in dynamic
> > > >>>> link training. I am talking about having at least static DRAM register
> > > >>>> configuration values,
> >
> > > >> I can tell you that this is no work for all the boards, you can see how
> > > >> rockchip lpddr4(WIP, send by Jagan) driver works.
> >
> > > > I thought that LPDDR4 works the same as other types of DRAM where we
> > > > have a dtsi array with timings configuration. Of course, some more
> > > > registers need to be set up, but we already have support for that or
> > > > it's quite close (for LPDDR4).
> > >
> > > >>>> which is present for a good number of rockchip
> > > >>>> boards.
> > > >> No, there is no rockchip board only have static DRAM register
> > > >> configuration values, that maybe happens in other vendor.
> > >
> > > > I was implying that, as far as I know, it is the case for DRAM timings
> > > > on Rockchip as well as most of the platforms that I know of. In the
> > > > end, any code handling DRAM will end up writing timings to the
> > > > controller's registers. If the DRAM is part of the PCB and doesn't
> > > > change/move, then the timings don't change in particular.
> > > >
> > > > Is there something specific about Rockchip that makes it require
> > > > different DRAM timings at each boot?
> > >
> > > >>>> Of course, it would be best if Rockchip would consider releasing this
> > > >>>> source code,
> > > >> Rockchip already release all the DRAM init source code, including DDR3 ,
> > > >> LPDDR3,
> > > >> and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
> > > >> everything,
> > > >> which is not only static register configuration.
> > > >> As I have said, rockchip is already the most open vendor in this area
> > > >> till now, I don't know
> > > >> if you have working on rockchip SoC based boards.
> > > > You are quite right about that, but I was thinking about the code to
> > > > calculate DRAM timings (with link-training and such) which is often not
> > > > available as free software, and I am not aware of Rockchip having
> > > > released that code (but feel free to correct me if I'm wrong).
> > > >
> > > >>>> which would be the easiest and friendliest solution
> > > >>>> towards the community here. Are there internal discussions ongoing
> > > >>>> about this? If not, it would be greatly appreciated to start such
> > > >>>> discussions and clearly identify what the blocking points are.
> > > >>>>
> > > >>>>> I won't use this rule to stop developers contribute there source code,
> > > >>>> This is really sad and I think that Philipp was, like me, inclined to
> > > >>>> go towards the other direction.
> > > >>>>
> > > >>>>> for a board support, we only need the board to have the full documentation
> > > >>>>> about how to setup and boot with upstream U-Boot. and I think the
> > > >>>>> most of people cares more about features in U-Boot proper. Everything
> > > >>>>> before U-Boot proper, you can use TPL/SPL or alternative to use binary
> > > >>>>> from vendor, as you can see all over the U-Boot mainline now, although
> > > >>>>> we encourage people to use full open source TPL/SPL.
> > > >>>>> Specifically for U-Boot Rockchip platform, I would like people to
> > > >>>>> support not only U-Boot
> > > >>>>> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> > > >>>>> features)
> > > >>>>> support. And for DRAM init,
> > > >>>>> - if this belongs to SPL for this board, you must implement it or else
> > > >>>>> SPL won't work;
> > > >>>>> - if this does not belong to SPL for this board, you need implement full
> > > >>>>> function SPL;
> > > >>>>> and you can either to have full function TPL with DRAM init(which is
> > > >>>>> prefered)
> > > >>>>> or alternatively use binary loader from vendor.
> > > >>>> This is not really a technical argument here, more of a policy argument
> > > >>>> that ensures we have full free software support for the boards we
> > > >>>> support, and not only half-cooked support (that will most likely never
> > > >>>> be completed as soon as something that works gets merged). So it is a
> > > >>>> strategical decision, not a strictly pragmatic one.
> >
> > > >>> While having full open source software support for boards is a noble
> > > >>> goal, I think there should be some room for pragmatism here. A
> > > >>> significant number of u_boot targets rely on closed source components.
> > > >>> In the particular case of RK3399 the situation is better than for
> > > >>> other boards since you can combine the binary loader from the vendor
> > > >>> with mainline U-Boot and mainline ATF to create a firmware where (as
> > > >>> far as we can tell) no closed soure component remains active after
> > > >>> U-Boot and ATF take over control.
> > > >>>
> > > >>>> I think reverting patches adding support for boards with no DRAM
> > > >>>> configuration at all would send a message in the right direction here.
> > > >> As a developer, I agree on this, but as a maintainer, I know too many
> > > >> developers not able to do it and what most of developers need is other
> > > >> features in U-Boot or SPL, and I would like the U-Boot mainline is more
> > > >> active with more and more developers. So I'm afraid I agree with Mark
> > > >> at this time for the policy.
> > > > Maybe we need to provide tools ot make that process easier for everyone
> > > > if it is really that hard. I don't really see what is so special about
> > > > DRAM timings that would imply that a regular developer doing a U-Boot
> > > > bringup couldn't figure things out, aside from the ability to dump said
> > > > timings.
> > > >
> > > >> If all the other SoC platforms can have the same rule for DRAM init driver
> > > >> is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
> > > >> imx, aml, and all others, then I would very happy to follow the rule.
> > > >> Rockchip is open for open source the DRAM driver, you have to know this
> > > >> is the decision by the vendor, but not any of developers.
> > > >> On rockchip platform, developers no need to concern about the DRAM
> > > >> driver(which is pretty hard for most developers) because rockchip
> > > >> already contribute it.
> > > > Rockchip is indeed in a better position than other vendors where DRAM
> > > > init may not be available (or when it's impossible to run U-Boot right
> > > > after the bootrom and do the DRAM init itself because of e.g. abusive
> > > > signature verification or lack of documentation).
> > > >
> > > > Since there is good DRAM support for Rockchip in place, we have an
> > > > opportunity to push developers to do the right thing and contribute
> > > > full support for the board. To me it is simply a matter of
> > > > acknowledging that bootloader support for a board without DRAM init is
> > > > not useful bootloader support. Since we have the code in place to
> > > > support that, we can take the extra step and require that each board
> > > > contribution be useful in that aspect.
> > > >
> > > >> For the time now, I know there will be full DRAM driver for rockchip SoC,
> > > >> so the SoC/board support could be step by step:
> > > >> U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
> >
> > Keeping allowing a step-by-step approach could be beneficial I think,
> > in the kernel we also don't require full support for all peripherals on
> > initial submission ;-) .
> >
> > And also for people starting out on a specific board having at least partial
> > support is way easier than trying to figure out for example the vendor
> > u-boot.
> >
> > Maybe we could give this some sort of time limitation like
> > "binary ddr-init allowed till 2019-10-31" in Kconfig or somewhere
> > to give people the chance to do things piece by piece but still force them
> > to actually work on improving the situation.
> >
> > As driver-side changes will generally benefit more socs/boards potential
> > removal after the time limit would only affect the board+dts itself.
> >
> > So somewhat similar to what the kernel does with "staging", if you
> > keep working on improving it, it is allowed to stay.
> >
> > This could be also applied to already included boards, like
> > "give it a working ddr-init till 2019-12-31 or it gets removed", similarly
> > to how Tom handles devicemanager conversions currently
>
> Still doesn't make sense to me unless you're going to enforce such a
> rule for all included boards that lack usable open-source DRAM
> initialization code. Otherwise you're just punishing Rockchip for
> having a partial DRAM initialization code and are potentially sending
> the message that it's better not to attempt create open source DRAM
> drivers.
hmm, I'm not sure if I worded my reply just poorly? I was talking about
time-limiting the use of the _binary_ loader (as TPL or whatever) from
Rockchip's rkbin repo [0]. Which would mean no sourceful ddr-driver at all.
That case (using the binary) is a nice stepping stone to iterative
development, as you can concentrate on other parts of the boot process,
but when it overstays its welcome things begin to rot.
An example could be the rk3128 included in u-boot, no ddr-init at all
(requiring the binary ddr-init) and also no plans at all to create u-boot-
based ddr-init in the future. And the soc is so niche, that it sees no real
development.
In turn I would welcome any approach for a sourceful ddr-init as valid.
Because once you have something that at least works, you can iterate
on improving it.
[0] https://github.com/rockchip-linux/rkbin/tree/master/bin/rk33
All the foobar_ddr_fooMHz.bin files
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards
@ 2019-06-21 13:08 ` Heiko Stuebner
0 siblings, 0 replies; 43+ messages in thread
From: Heiko Stuebner @ 2019-06-21 13:08 UTC (permalink / raw)
To: u-boot
Am Freitag, 21. Juni 2019, 14:52:17 CEST schrieb Mark Kettenis:
> > From: Heiko Stuebner <heiko@sntech.de>
> > Date: Fri, 21 Jun 2019 13:34:16 +0200
> >
> > Hi,
> >
> > Am Donnerstag, 20. Juni 2019, 05:24:32 CEST schrieb Kever Yang:
> > > On 06/20/2019 12:54 AM, Paul Kocialkowski wrote:
> > > > Le mercredi 19 juin 2019 à 09:42 +0800, Kever Yang a écrit :
> > > >> On 06/19/2019 12:12 AM, Mark Kettenis wrote:
> > > >>>> From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> > > >>>> Date: Tue, 18 Jun 2019 14:47:33 +0200
> > > >>>> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> > > >>>>> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > > >>>>>> On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > >>>>>>> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > > >>>>>>> <paul.kocialkowski@bootlin.com> wrote:
> > > >>>>>>>> On Mon, 2019-06-17 at 15:24 +0800, xieqinick at gmail.com wrote:
> > > >>>>>>>>> From: Nick Xie <nick@khadas.com>
> > > >>>>>>>> Was this tested with SPL support? I don't see DRAM configuration here
> > > >>>>>>>> so it seems that it relies on the non-free rockchip loader.
> > > >>>>>>>>
> > > >>>>>>>> If that is the case, could you please indicate that in the commit
> > > >>>>>>>> message?
> > > >>>>>>>>
> > > >>>>>>>> To maintainers: please do not merge this series before DRAM init and
> > > >>>>>>>> SPL support is available for these boards.
> > > >>>>>>>>
> > > >>>>>>>> It seems that other RK3399 boards were merged without SPL support and
> > > >>>>>>>> sofar, I have the feeling that nobody cared to explain how we got into
> > > >>>>>>>> this broken situation. Please don't merge any more such board.
> > > >>>>>>> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > > >>>>>>> with TPL-enabled (which was discussed on the threads, if you remember)
> > > >>>>>>> with below boot chain.
> > > >>>>>>>
> > > >>>>>>> rkbin (TPL) -> SPL -> U-Boot proper
> > > >>>>>>>
> > > >>>>>>> Same case for this board as well.
> > > >>>>>> Here is a quote from Philipp Tomsich on the thread we discussed this:
> > > >>>>>>
> > > >>>>>> " On some boards, there will be no TPL and only a SPL stage that will
> > > >>>>>> initialise DRAM (as the move to having TPL on the RK3399 is optional).
> > > >>>>>>
> > > >>>>>> I agree with Paul that the DRAM init should be part of U-Boot whenever
> > > >>>>>> we add new boards and make an open DRAM init a prerequisite. "
> > > >>>>>>
> > > >>>>>> So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > > >>>>>> that no board should be merged without proper DRAM init.
> > > >>>>>>
> > > >>>>>> Please stop pushing for merging these boards. I'm not sure what we
> > > >>>>>> should do about the boards that were merged already without DRAM init,
> > > >>>>>> but maybe they should be reverted.
> >
> > > >>>>> I don't think we have to have full DRAM init source code for each
> > > >>>>> board before we can merge it, I believe most of the board on U-Boot
> > > >>>>> mainline need to removed due to this rule. There are so many boards
> > > >>>>> from different vendor need a binary loader before U-Boot, and I can
> > > >>>>> see only very few drivers for dram at driver/ram/, and I believe rockchip
> > > >>>>> is already the most open vendor on this area.
> >
> > > >>>> Well, I am not talking about full DRAM init source code as in dynamic
> > > >>>> link training. I am talking about having at least static DRAM register
> > > >>>> configuration values,
> >
> > > >> I can tell you that this is no work for all the boards, you can see how
> > > >> rockchip lpddr4(WIP, send by Jagan) driver works.
> >
> > > > I thought that LPDDR4 works the same as other types of DRAM where we
> > > > have a dtsi array with timings configuration. Of course, some more
> > > > registers need to be set up, but we already have support for that or
> > > > it's quite close (for LPDDR4).
> > >
> > > >>>> which is present for a good number of rockchip
> > > >>>> boards.
> > > >> No, there is no rockchip board only have static DRAM register
> > > >> configuration values, that maybe happens in other vendor.
> > >
> > > > I was implying that, as far as I know, it is the case for DRAM timings
> > > > on Rockchip as well as most of the platforms that I know of. In the
> > > > end, any code handling DRAM will end up writing timings to the
> > > > controller's registers. If the DRAM is part of the PCB and doesn't
> > > > change/move, then the timings don't change in particular.
> > > >
> > > > Is there something specific about Rockchip that makes it require
> > > > different DRAM timings at each boot?
> > >
> > > >>>> Of course, it would be best if Rockchip would consider releasing this
> > > >>>> source code,
> > > >> Rockchip already release all the DRAM init source code, including DDR3 ,
> > > >> LPDDR3,
> > > >> and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
> > > >> everything,
> > > >> which is not only static register configuration.
> > > >> As I have said, rockchip is already the most open vendor in this area
> > > >> till now, I don't know
> > > >> if you have working on rockchip SoC based boards.
> > > > You are quite right about that, but I was thinking about the code to
> > > > calculate DRAM timings (with link-training and such) which is often not
> > > > available as free software, and I am not aware of Rockchip having
> > > > released that code (but feel free to correct me if I'm wrong).
> > > >
> > > >>>> which would be the easiest and friendliest solution
> > > >>>> towards the community here. Are there internal discussions ongoing
> > > >>>> about this? If not, it would be greatly appreciated to start such
> > > >>>> discussions and clearly identify what the blocking points are.
> > > >>>>
> > > >>>>> I won't use this rule to stop developers contribute there source code,
> > > >>>> This is really sad and I think that Philipp was, like me, inclined to
> > > >>>> go towards the other direction.
> > > >>>>
> > > >>>>> for a board support, we only need the board to have the full documentation
> > > >>>>> about how to setup and boot with upstream U-Boot. and I think the
> > > >>>>> most of people cares more about features in U-Boot proper. Everything
> > > >>>>> before U-Boot proper, you can use TPL/SPL or alternative to use binary
> > > >>>>> from vendor, as you can see all over the U-Boot mainline now, although
> > > >>>>> we encourage people to use full open source TPL/SPL.
> > > >>>>> Specifically for U-Boot Rockchip platform, I would like people to
> > > >>>>> support not only U-Boot
> > > >>>>> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> > > >>>>> features)
> > > >>>>> support. And for DRAM init,
> > > >>>>> - if this belongs to SPL for this board, you must implement it or else
> > > >>>>> SPL won't work;
> > > >>>>> - if this does not belong to SPL for this board, you need implement full
> > > >>>>> function SPL;
> > > >>>>> and you can either to have full function TPL with DRAM init(which is
> > > >>>>> prefered)
> > > >>>>> or alternatively use binary loader from vendor.
> > > >>>> This is not really a technical argument here, more of a policy argument
> > > >>>> that ensures we have full free software support for the boards we
> > > >>>> support, and not only half-cooked support (that will most likely never
> > > >>>> be completed as soon as something that works gets merged). So it is a
> > > >>>> strategical decision, not a strictly pragmatic one.
> >
> > > >>> While having full open source software support for boards is a noble
> > > >>> goal, I think there should be some room for pragmatism here. A
> > > >>> significant number of u_boot targets rely on closed source components.
> > > >>> In the particular case of RK3399 the situation is better than for
> > > >>> other boards since you can combine the binary loader from the vendor
> > > >>> with mainline U-Boot and mainline ATF to create a firmware where (as
> > > >>> far as we can tell) no closed soure component remains active after
> > > >>> U-Boot and ATF take over control.
> > > >>>
> > > >>>> I think reverting patches adding support for boards with no DRAM
> > > >>>> configuration at all would send a message in the right direction here.
> > > >> As a developer, I agree on this, but as a maintainer, I know too many
> > > >> developers not able to do it and what most of developers need is other
> > > >> features in U-Boot or SPL, and I would like the U-Boot mainline is more
> > > >> active with more and more developers. So I'm afraid I agree with Mark
> > > >> at this time for the policy.
> > > > Maybe we need to provide tools ot make that process easier for everyone
> > > > if it is really that hard. I don't really see what is so special about
> > > > DRAM timings that would imply that a regular developer doing a U-Boot
> > > > bringup couldn't figure things out, aside from the ability to dump said
> > > > timings.
> > > >
> > > >> If all the other SoC platforms can have the same rule for DRAM init driver
> > > >> is a mandatory instead of option, eg. brcom, qcom, mtk, omap, tegra, stm,
> > > >> imx, aml, and all others, then I would very happy to follow the rule.
> > > >> Rockchip is open for open source the DRAM driver, you have to know this
> > > >> is the decision by the vendor, but not any of developers.
> > > >> On rockchip platform, developers no need to concern about the DRAM
> > > >> driver(which is pretty hard for most developers) because rockchip
> > > >> already contribute it.
> > > > Rockchip is indeed in a better position than other vendors where DRAM
> > > > init may not be available (or when it's impossible to run U-Boot right
> > > > after the bootrom and do the DRAM init itself because of e.g. abusive
> > > > signature verification or lack of documentation).
> > > >
> > > > Since there is good DRAM support for Rockchip in place, we have an
> > > > opportunity to push developers to do the right thing and contribute
> > > > full support for the board. To me it is simply a matter of
> > > > acknowledging that bootloader support for a board without DRAM init is
> > > > not useful bootloader support. Since we have the code in place to
> > > > support that, we can take the extra step and require that each board
> > > > contribution be useful in that aspect.
> > > >
> > > >> For the time now, I know there will be full DRAM driver for rockchip SoC,
> > > >> so the SoC/board support could be step by step:
> > > >> U-Boot proper -> U-Boot + SPL(no DRAM init) ->U-Boot + SPL + TPL.
> >
> > Keeping allowing a step-by-step approach could be beneficial I think,
> > in the kernel we also don't require full support for all peripherals on
> > initial submission ;-) .
> >
> > And also for people starting out on a specific board having at least partial
> > support is way easier than trying to figure out for example the vendor
> > u-boot.
> >
> > Maybe we could give this some sort of time limitation like
> > "binary ddr-init allowed till 2019-10-31" in Kconfig or somewhere
> > to give people the chance to do things piece by piece but still force them
> > to actually work on improving the situation.
> >
> > As driver-side changes will generally benefit more socs/boards potential
> > removal after the time limit would only affect the board+dts itself.
> >
> > So somewhat similar to what the kernel does with "staging", if you
> > keep working on improving it, it is allowed to stay.
> >
> > This could be also applied to already included boards, like
> > "give it a working ddr-init till 2019-12-31 or it gets removed", similarly
> > to how Tom handles devicemanager conversions currently
>
> Still doesn't make sense to me unless you're going to enforce such a
> rule for all included boards that lack usable open-source DRAM
> initialization code. Otherwise you're just punishing Rockchip for
> having a partial DRAM initialization code and are potentially sending
> the message that it's better not to attempt create open source DRAM
> drivers.
hmm, I'm not sure if I worded my reply just poorly? I was talking about
time-limiting the use of the _binary_ loader (as TPL or whatever) from
Rockchip's rkbin repo [0]. Which would mean no sourceful ddr-driver at all.
That case (using the binary) is a nice stepping stone to iterative
development, as you can concentrate on other parts of the boot process,
but when it overstays its welcome things begin to rot.
An example could be the rk3128 included in u-boot, no ddr-init at all
(requiring the binary ddr-init) and also no plans at all to create u-boot-
based ddr-init in the future. And the soc is so niche, that it sees no real
development.
In turn I would welcome any approach for a sourceful ddr-init as valid.
Because once you have something that at least works, you can iterate
on improving it.
[0] https://github.com/rockchip-linux/rkbin/tree/master/bin/rk33
All the foobar_ddr_fooMHz.bin files
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support
2019-05-25 5:57 ` Jagan Teki
@ 2019-07-26 8:00 ` Kever Yang
2019-07-26 9:55 ` Nick
0 siblings, 1 reply; 43+ messages in thread
From: Kever Yang @ 2019-07-26 8:00 UTC (permalink / raw)
To: u-boot
Hi Nick,
Are you going to send a new patch set with the update of change request?
Thanks,
- Kever
Jagan Teki <jagan@amarulasolutions.com> 于2019年5月25日周六 下午1:57写道：
> On Sat, May 25, 2019 at 9:14 AM Nick Xie <xieqinick@gmail.com> wrote:
> >
> >
> > Hello Jagan,
> >
> > Thanks for your review.
> >
> >> > Hope you sync the dts from Linux, if not please submit it and aprove
> >> > first, if yes then add commit sha1. This would help to keep track of
> >> > syncing dts from Linux later and since dts files are more relatives
> >> > same from Linux it always better to approve Linux first interms of
> >> > binidngs and all.
> >
> >
> > As I haven't sent patches to linux upstream yet, my plan is to send
> patches to u-boot first, then send patches to linux.
> >
> > The dts of u-boot must sync from the mainline linux?
>
> We use dts from Linux and we don't have specific maintainer for these
> (atleast no need). DTS files coming from Linux means it's been
> reviewed by respective maintainer along with devicetree ML.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support
2019-07-26 8:00 ` Kever Yang
@ 2019-07-26 9:55 ` Nick
2019-07-26 13:52 ` Chris Webb
0 siblings, 1 reply; 43+ messages in thread
From: Nick @ 2019-07-26 9:55 UTC (permalink / raw)
To: u-boot
Hello Kever
Yes, I will do this when the DDR patches merged.
Nick
> 在 2019年7月26日，16:00，Kever Yang <kever.yang@rock-chips.com> 写道：
>
> Hi Nick,
>
> Are you going to send a new patch set with the update of change request?
>
> Thanks,
> - Kever
>
> Jagan Teki <jagan@amarulasolutions.com> 于2019年5月25日周六 下午1:57写道：
>> On Sat, May 25, 2019 at 9:14 AM Nick Xie <xieqinick@gmail.com> wrote:
>> >
>> >
>> > Hello Jagan,
>> >
>> > Thanks for your review.
>> >
>> >> > Hope you sync the dts from Linux, if not please submit it and aprove
>> >> > first, if yes then add commit sha1. This would help to keep track of
>> >> > syncing dts from Linux later and since dts files are more relatives
>> >> > same from Linux it always better to approve Linux first interms of
>> >> > binidngs and all.
>> >
>> >
>> > As I haven't sent patches to linux upstream yet, my plan is to send patches to u-boot first, then send patches to linux.
>> >
>> > The dts of u-boot must sync from the mainline linux?
>>
>> We use dts from Linux and we don't have specific maintainer for these
>> (atleast no need). DTS files coming from Linux means it's been
>> reviewed by respective maintainer along with devicetree ML.
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support
2019-07-26 9:55 ` Nick
@ 2019-07-26 13:52 ` Chris Webb
2019-07-27 1:09 ` Nick Xie
0 siblings, 1 reply; 43+ messages in thread
From: Chris Webb @ 2019-07-26 13:52 UTC (permalink / raw)
To: u-boot
Hi Nick. I think Kever has merged the LPDDR4 series, and it's already made
its way into the mainline u-boot master branch.
https://gitlab.denx.de/u-boot/u-boot/commit/852f6ddd76fad2d5adef3f7e3a75d0065c68db3b
and its ancestors are the v3 series Jagan posted to the list.
There have also been a number of other rk3399 cleanups since then, so the
defconfig might need updating to suit. (I just copied the rock-pi-4
defconfig and replaced the default device tree.)
Best wishes,
Chris.
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support
2019-07-26 13:52 ` Chris Webb
@ 2019-07-27 1:09 ` Nick Xie
2019-07-27 9:25 ` Chris Webb
0 siblings, 1 reply; 43+ messages in thread
From: Nick Xie @ 2019-07-27 1:09 UTC (permalink / raw)
To: u-boot
Hello Chris,
That's great! I'll update the patches and send them soon.
Chris Webb <chris@arachsys.com> 于2019年7月26日周五 下午9:52写道：
> Hi Nick. I think Kever has merged the LPDDR4 series, and it's already
> made
> its way into the mainline u-boot master branch.
>
>
> https://gitlab.denx.de/u-boot/u-boot/commit/852f6ddd76fad2d5adef3f7e3a75d0065c68db3b
>
> and its ancestors are the v3 series Jagan posted to the list.
>
> There have also been a number of other rk3399 cleanups since then, so the
> defconfig might need updating to suit. (I just copied the rock-pi-4
> defconfig and replaced the default device tree.)
>
> Best wishes,
>
> Chris.
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support
2019-07-27 1:09 ` Nick Xie
@ 2019-07-27 9:25 ` Chris Webb
0 siblings, 0 replies; 43+ messages in thread
From: Chris Webb @ 2019-07-27 9:25 UTC (permalink / raw)
To: u-boot
Nick Xie <xieqinick@gmail.com> wrote:
> That's great! I'll update the patches and send them soon.
I'll make sure I test your specific patch when you post it, but I can
already confirm that u-boot.git master happily boots a Khadas Edge board.
I just added the unmodified Edge device tree from mainline Linux into
arch/arm/dts/, created the u-boot fixup .dtsi and\x05 defconfig with
sed 's/rock-pi-4/khadas-edge/g' configs/rock-pi-4-rk3399_defconfig \
>configs/khadas-edge-rk3399_defconfig
cp arch/arm/dts/rk3399-{rock-pi-4,khadas-edge}-u-boot.dtsi
make khadas-edge-rk3399_defconfig
then built u-boot with an rk3399 bl31.elf from master of
arm-trusted-firmware.git.
It boots TPL -> SPL -> U-Boot proper -> Linux just fine without any
external idbloader.bin or standalone trusted firmware - faster and much
less noisy!
Best wishes,
Chris.
^ permalink raw reply [flat|nested] 43+ messages in thread
* [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support
@ 2019-05-24 11:29 xieqinick at gmail.com
0 siblings, 0 replies; 43+ messages in thread
From: xieqinick at gmail.com @ 2019-05-24 11:29 UTC (permalink / raw)
To: u-boot
From: Nick <nick@khadas.com>
Khadas Edge is a board from Khadas, you can find the detail about it here:
https://www.khadas.com/edge
This patch add basic node for the board and make it able to bring up.
Specification
- Rockchip RK3399
- Dual-Channel 2GB/4GB LPDDR4
- SD card slot
- Onboard 16GB/32GB/128GB eMMC
- RTL8211FD 1Gbps
- AP6356S/AP6398S WiFI/BT
- HDMI Out, DP, MIPI DSI/CSI, eDP
- USB 3.0, 2.0
- USB Type C power and data
- GPIO expansion ports
- Full 4 Lane M.2 Socket
- 16MB SPI Flash
- IR
- Programmable MCU
Signed-off-by: Nick <nick@khadas.com>
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3399-kedge-u-boot.dtsi | 10 +
arch/arm/dts/rk3399-kedge.dts | 611 ++++++++++++++++++++++++++++++++++
board/rockchip/evb_rk3399/MAINTAINERS | 7 +
configs/khadas-edge-rk3399_defconfig | 63 ++++
5 files changed, 692 insertions(+)
create mode 100644 arch/arm/dts/rk3399-kedge-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-kedge.dts
create mode 100644 configs/khadas-edge-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 31ef2b6..d9adecf 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -113,6 +113,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399-puma-ddr1600.dtb \
rk3399-puma-ddr1866.dtb \
rk3399-rock960.dtb \
+ rk3399-kedge.dtb
dtb-$(CONFIG_ROCKCHIP_RV1108) += \
rv1108-elgin-r1.dtb \
diff --git a/arch/arm/dts/rk3399-kedge-u-boot.dtsi b/arch/arm/dts/rk3399-kedge-u-boot.dtsi
new file mode 100644
index 0000000..bf0d54c
--- /dev/null
+++ b/arch/arm/dts/rk3399-kedge-u-boot.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Nick <nick@khadas.com>
+ */
+
+#include "rk3399-u-boot.dtsi"
+
+&sdmmc {
+ pinctrl-0 = <&sdmmc_bus4 &sdmmc_clk &sdmmc_cmd &sdmmc_cd>;
+};
diff --git a/arch/arm/dts/rk3399-kedge.dts b/arch/arm/dts/rk3399-kedge.dts
new file mode 100644
index 0000000..e07e699
--- /dev/null
+++ b/arch/arm/dts/rk3399-kedge.dts
@@ -0,0 +1,611 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * RK3399-based Khadas boards device tree source
+ *
+ * Copyright (c) 2019 Shenzhen Wesion Technology Co., Ltd.
+ * (https://www.khadas.com/edge)
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ model = "Khadas Edge";
+ compatible = "khadas,edge", "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>;
+ };
+
+ 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_host: vcc5v0-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio4 RK_PD1 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&host_vbus_drv>;
+ regulator-name = "vcc5v0_host";
+ regulator-always-on;
+ };
+
+ 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>;
+ };
+
+ 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>;
+ };
+
+ 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_PA6 GPIO_ACTIVE_HIGH>;
+ label = "status_led";
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
+
+&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";
+};
+
+&i2c4 {
+ 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 = <22 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_apio2: LDO_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc1v8_apio2";
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_vldo2: LDO_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "vcc_vldo2";
+
+ 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>;
+ };
+ };
+
+ vccio_sd: LDO_REG4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-init-microvolt = <3000000>;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd";
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcc_vldo5: LDO_REG5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "vcc_vldo5";
+
+ 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;
+ };
+ };
+ };
+ };
+};
+
+&i2c8 {
+ clock-frequency = <400000>;
+ i2c-scl-rising-time-ns = <160>;
+ i2c-scl-falling-time-ns = <30>;
+ status = "okay";
+};
+
+&io_domains {
+ bt656-supply = <&vcc1v8_apio2>;
+ audio-supply = <&vcca1v8_codec>;
+ sdmmc-supply = <&vccio_sd>;
+ gpio1830-supply = <&vcc_3v0>;
+ status = "okay";
+};
+
+&pinctrl {
+ usb2 {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins = <4 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ gpio-leds {
+ leds_gpio: leds-gpio {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ cpu_b_sleep: cpu-b-sleep {
+ rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ gpu_sleep: gpu-sleep {
+ rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ pmic_int_l: pmic-int-l {
+ rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ rockchip-key {
+ power_key: power-key {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ 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_1v8>;
+ 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";
+};
+
+&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 = <&vccio_sd>;
+ 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";
+};
+
+&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";
+};
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index f55c92f..bcb058c 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
+
+KHADAS-EDGE
+M: Nick <nick@khadas.com>
+S: Maintained
+F: configs/khadas-edge-rk3399_defconfig
+F: arch/arm/dts/rk3399-kedge.dts
+F: arch/arm/dts/rk3399-kedge-u-boot.dtsi
diff --git a/configs/khadas-edge-rk3399_defconfig b/configs/khadas-edge-rk3399_defconfig
new file mode 100644
index 0000000..a9def59
--- /dev/null
+++ b/configs/khadas-edge-rk3399_defconfig
@@ -0,0 +1,63 @@
+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_NR_DRAM_BANKS=1
+CONFIG_SPL_STACK_R_ADDR=0x80000
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-kedge.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_TEXT_BASE=0xff8c2000
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_SYS_PROMPT="kedge# "
+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_CMD_FS_UUID=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-kedge"
+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_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_PHY_REALTEK=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.7.4
^ permalink raw reply related [flat|nested] 43+ messages in thread
end of thread, other threads:[~2019-07-27 9:25 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-24 11:19 [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support xieqinick at gmail.com
2019-05-24 18:23 ` Jagan Teki
2019-05-25 3:44 ` Nick Xie
2019-05-25 5:57 ` Jagan Teki
2019-07-26 8:00 ` Kever Yang
2019-07-26 9:55 ` Nick
2019-07-26 13:52 ` Chris Webb
2019-07-27 1:09 ` Nick Xie
2019-07-27 9:25 ` Chris Webb
[not found] ` <1558696796-10745-1-git-send-email-xieqinick-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-06-17 7:24 ` [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards xieqinick-Re5JQEeQqe8AvxtiuMwx3w
2019-06-17 7:24 ` [U-Boot] " xieqinick at gmail.com
2019-06-18 7:21 ` Kever Yang
[not found] ` <1560756277-5928-1-git-send-email-xieqinick-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2019-06-18 8:25 ` Paul Kocialkowski
2019-06-18 8:25 ` [U-Boot] " Paul Kocialkowski
[not found] ` <5ad4d842c462a19e6241fe620705381169d48318.camel-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
2019-06-18 8:57 ` Jagan Teki
2019-06-18 8:57 ` [U-Boot] " Jagan Teki
2019-06-18 9:03 ` Paul Kocialkowski
2019-06-18 9:03 ` [U-Boot] " Paul Kocialkowski
2019-06-18 10:08 ` Kever Yang
2019-06-18 10:08 ` [U-Boot] " Kever Yang
2019-06-18 12:47 ` Paul Kocialkowski
2019-06-18 12:47 ` [U-Boot] " Paul Kocialkowski
2019-06-18 16:12 ` Mark Kettenis
2019-06-18 16:12 ` [U-Boot] " Mark Kettenis
[not found] ` <54387600d5a68bf0-Sse5TxTiDWuxJFhkpKByzTXZidJgq2Oi@public.gmane.org>
2019-06-19 1:42 ` Kever Yang
2019-06-19 1:42 ` Kever Yang
2019-06-19 16:54 ` Paul Kocialkowski
2019-06-19 16:54 ` [U-Boot] " Paul Kocialkowski
2019-06-20 3:24 ` Kever Yang
2019-06-20 3:24 ` [U-Boot] " Kever Yang
[not found] ` <88b913b4-5bb7-58fb-650b-b3e4e74ff66a-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2019-06-21 11:34 ` Heiko Stuebner
2019-06-21 11:34 ` Heiko Stuebner
2019-06-21 11:58 ` Paul Kocialkowski
2019-06-21 11:58 ` [U-Boot] " Paul Kocialkowski
2019-06-21 12:52 ` Mark Kettenis
2019-06-21 12:52 ` [U-Boot] " Mark Kettenis
2019-06-21 13:05 ` Paul Kocialkowski
2019-06-21 13:05 ` [U-Boot] " Paul Kocialkowski
2019-06-21 13:08 ` Heiko Stuebner
2019-06-21 13:08 ` [U-Boot] " Heiko Stuebner
2019-06-17 8:56 ` xieqinick at gmail.com
2019-06-18 7:21 ` Jagan Teki
2019-05-24 11:29 [U-Boot] [PATCH] rockchip: rk3399: Add Khadas Edge board support xieqinick at gmail.com
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.