Re: [PATCH] sunxi: spl: h616: fix booting from high MMC offset

[Chen-Yu Tsai]

On Fri, May 10, 2024 at 7:13 AM Andre Przywara  wrote:
>
> The BootROM in the Allwinner H616 tries to load the initial boot code
> from sector 16 (8KB) of an SD card or eMMC device, but also looks at
> sector 512 (256KB). This helps with GPT formatted cards.
> A "high" boot offset is also used on previous SoCs, but it's sector 256
> (128KB) there instead.
>
> Extend the existing offset calculation code to consider the different
> sector offset when running on an H616 SoC. This allows to load U-Boot
> on any H616 device when the SPL is not located at 8KB.
>
> Signed-off-by: Andre Przywara 

Make sense.

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH v2 3/5] rockchip: rk3328: regenerate defconfigs

[Chen-Yu Tsai]

Hi,

On Wed, Mar 13, 2024 at 6:29 PM Kever Yang  wrote:
>
> Hi Chen-Yu,
>
> On 2024/2/12 21:51, Chen-Yu Tsai wrote:
>
> From: Chen-Yu Tsai 
>
> Regenerate RK3328 defconfigs after adding imply statements.
>
> Signed-off-by: Chen-Yu Tsai 
> Reviewed-by: Christopher Obbard 
> Reviewed-by: Dragan Simic 
> ---
>  configs/evb-rk3328_defconfig  | 3 ---
>  configs/nanopi-r2c-plus-rk3328_defconfig  | 3 ---
>  configs/nanopi-r2c-rk3328_defconfig   | 3 ---
>  configs/nanopi-r2s-rk3328_defconfig   | 3 ---
>  configs/orangepi-r1-plus-lts-rk3328_defconfig | 3 ---
>  configs/orangepi-r1-plus-rk3328_defconfig | 3 ---
>  configs/roc-cc-rk3328_defconfig   | 3 ---
>  configs/rock-pi-e-rk3328_defconfig| 3 ---
>  configs/rock64-rk3328_defconfig   | 3 ---
>  9 files changed, 27 deletions(-)
>
> diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
> index 995bfd0558b1..c3bde3e5c457 100644
> --- a/configs/evb-rk3328_defconfig
> +++ b/configs/evb-rk3328_defconfig
> @@ -30,7 +30,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-evb.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> -CONFIG_MISC_INIT_R=y
>  CONFIG_SPL_MAX_SIZE=0x4
>  CONFIG_SPL_PAD_TO=0x7f8000
>  CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
> @@ -70,8 +69,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
>  CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
>  CONFIG_ROCKCHIP_GPIO=y
>  CONFIG_SYS_I2C_ROCKCHIP=y
> -CONFIG_MISC=y
> -CONFIG_ROCKCHIP_EFUSE=y
>
> There is no this config in the all these boards when I check the code on next,
>
> which cause the conflict when apply this patch.

I can respin, but should I still base my patches on Jonas's series?
I don't see them in next.

ChenYu

>
> Thanks,
>
> - Kever
>
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_ROCKCHIP=y
>  CONFIG_PHY_MOTORCOMM=y
> diff --git a/configs/nanopi-r2c-plus-rk3328_defconfig 
> b/configs/nanopi-r2c-plus-rk3328_defconfig
> index 1cb0ed855398..1b0fa27ced16 100644
> --- a/configs/nanopi-r2c-plus-rk3328_defconfig
> +++ b/configs/nanopi-r2c-plus-rk3328_defconfig
> @@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2c-plus.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> -CONFIG_MISC_INIT_R=y
>  CONFIG_SPL_MAX_SIZE=0x4
>  CONFIG_SPL_PAD_TO=0x7f8000
>  CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
> @@ -72,8 +71,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
>  CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
>  CONFIG_ROCKCHIP_GPIO=y
>  CONFIG_SYS_I2C_ROCKCHIP=y
> -CONFIG_MISC=y
> -CONFIG_ROCKCHIP_EFUSE=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_ROCKCHIP=y
>  CONFIG_PHY_MOTORCOMM=y
> diff --git a/configs/nanopi-r2c-rk3328_defconfig 
> b/configs/nanopi-r2c-rk3328_defconfig
> index 59801328deda..edf24623da2a 100644
> --- a/configs/nanopi-r2c-rk3328_defconfig
> +++ b/configs/nanopi-r2c-rk3328_defconfig
> @@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2c.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> -CONFIG_MISC_INIT_R=y
>  CONFIG_SPL_MAX_SIZE=0x4
>  CONFIG_SPL_PAD_TO=0x7f8000
>  CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
> @@ -72,8 +71,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
>  CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
>  CONFIG_ROCKCHIP_GPIO=y
>  CONFIG_SYS_I2C_ROCKCHIP=y
> -CONFIG_MISC=y
> -CONFIG_ROCKCHIP_EFUSE=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_ROCKCHIP=y
>  CONFIG_PHY_MOTORCOMM=y
> diff --git a/configs/nanopi-r2s-rk3328_defconfig 
> b/configs/nanopi-r2s-rk3328_defconfig
> index 61914b1650d2..32c99dfecb86 100644
> --- a/configs/nanopi-r2s-rk3328_defconfig
> +++ b/configs/nanopi-r2s-rk3328_defconfig
> @@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2s.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> -CONFIG_MISC_INIT_R=y
>  CONFIG_SPL_MAX_SIZE=0x4
>  CONFIG_SPL_PAD_TO=0x7f8000
>  CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
> @@ -72,8 +71,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
>  CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
>  CONFIG_ROCKCHIP_GPIO=y
>  CONFIG_SYS_I2C_ROCKCHIP=y
> -CONFIG_MISC=y
> -CONFIG_ROCKCHIP_EFUSE=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_ROCKCHIP=y
>  CONFIG_PHY_MOTORCOMM=y
> diff --git a/configs/orangepi-r1-plus-lts-rk3328_defconfig 
> b/configs/orangepi-r1-plus-lts-rk3328_defconfig
> index 968110c8cd6f..f554a284d930 100644
> --- a/configs/orangepi-r1-plus-lts-rk3328_defconfig
> +++ b/configs/orangepi-r1-plus-lts-rk3328_defconfig
> @@ -34,7 +34,6 @@ CONFIG_LEGACY_IMAGE_FOR

Re: [PATCH 0/4] rockchip: Read cpuid and generate MAC address from efuse for RK3328 and RK3399

[Chen-Yu Tsai]

On Mon, Feb 12, 2024 at 9:57 PM Peter Robinson  wrote:
>
> On Sat, 10 Feb 2024 at 06:32, Chen-Yu Tsai  wrote:
> >
> > From: Chen-Yu Tsai 
> >
> > Hi folks,
> >
> > This series enables ROCKCHIP_EFUSE and MISC_INIT_R by default for RK3328
> > and RK3399 so that the cpuid is read from the efuse and used to generate
> > a serial number and MAC addresses for all boards.
>
> For the series:
> Reviewed-by: Peter Robinson 

Thanks. I just sent out v2. Could you reply there as well?

[PATCH v2 5/5] rockchip: nanopi-r4s: Drop ROCKCHIP_OTP

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The NanoPi R4S has an RK3399 SoC, which has efuse supported by
ROCKCHIP_EFUSE, not ROCKCHIP_OTP.

Signed-off-by: Chen-Yu Tsai 
---
 configs/nanopi-r4s-rk3399_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/nanopi-r4s-rk3399_defconfig 
b/configs/nanopi-r4s-rk3399_defconfig
index f97c06412f07..50dbd7a854d4 100644
--- a/configs/nanopi-r4s-rk3399_defconfig
+++ b/configs/nanopi-r4s-rk3399_defconfig
@@ -40,7 +40,6 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_ROCKCHIP_OTP=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SDHCI=y
-- 
2.39.2

[PATCH v2 4/5] rockchip: rk3399: regenerate defconfigs

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Regenerate RK3399 defconfigs after adding imply statements.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Christopher Obbard 
Reviewed-by: Dragan Simic 
Reviewed-by: Quentin Schulz 
---
 configs/chromebook_bob_defconfig | 3 ---
 configs/chromebook_kevin_defconfig   | 3 ---
 configs/eaidk-610-rk3399_defconfig   | 1 -
 configs/evb-rk3399_defconfig | 1 -
 configs/firefly-rk3399_defconfig | 3 ---
 configs/khadas-edge-captain-rk3399_defconfig | 1 -
 configs/khadas-edge-rk3399_defconfig | 1 -
 configs/khadas-edge-v-rk3399_defconfig   | 1 -
 configs/leez-rk3399_defconfig| 1 -
 configs/nanopc-t4-rk3399_defconfig   | 1 -
 configs/nanopi-m4-2gb-rk3399_defconfig   | 1 -
 configs/nanopi-m4-rk3399_defconfig   | 1 -
 configs/nanopi-m4b-rk3399_defconfig  | 1 -
 configs/nanopi-neo4-rk3399_defconfig | 1 -
 configs/nanopi-r4s-rk3399_defconfig  | 3 ---
 configs/orangepi-rk3399_defconfig| 1 -
 configs/pinebook-pro-rk3399_defconfig| 3 ---
 configs/pinephone-pro-rk3399_defconfig   | 3 ---
 configs/puma-rk3399_defconfig| 3 ---
 configs/roc-pc-mezzanine-rk3399_defconfig| 3 ---
 configs/roc-pc-rk3399_defconfig  | 3 ---
 configs/rock-4c-plus-rk3399_defconfig| 3 ---
 configs/rock-4se-rk3399_defconfig| 3 ---
 configs/rock-pi-4-rk3399_defconfig   | 3 ---
 configs/rock-pi-4c-rk3399_defconfig  | 3 ---
 configs/rock-pi-n10-rk3399pro_defconfig  | 2 --
 configs/rock960-rk3399_defconfig | 2 --
 configs/rockpro64-rk3399_defconfig   | 3 ---
 28 files changed, 58 deletions(-)

diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index b5a5ae737e52..989a8211f64d 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -27,7 +27,6 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_BOARD_EARLY_INIT_R=y
-CONFIG_MISC_INIT_R=y
 CONFIG_BLOBLIST=y
 CONFIG_BLOBLIST_ADDR=0x10
 CONFIG_BLOBLIST_SIZE=0x1000
@@ -67,8 +66,6 @@ CONFIG_I2C_CROS_EC_TUNNEL=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_I2C_MUX=y
 CONFIG_CROS_EC_KEYB=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_CROS_EC=y
 CONFIG_CROS_EC_SPI=y
 CONFIG_PWRSEQ=y
diff --git a/configs/chromebook_kevin_defconfig 
b/configs/chromebook_kevin_defconfig
index 20913d2cf0fe..07a96aa18989 100644
--- a/configs/chromebook_kevin_defconfig
+++ b/configs/chromebook_kevin_defconfig
@@ -28,7 +28,6 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-kevin.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_BOARD_EARLY_INIT_R=y
-CONFIG_MISC_INIT_R=y
 CONFIG_BLOBLIST=y
 CONFIG_BLOBLIST_ADDR=0x10
 CONFIG_BLOBLIST_SIZE=0x1000
@@ -68,8 +67,6 @@ CONFIG_I2C_CROS_EC_TUNNEL=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_I2C_MUX=y
 CONFIG_CROS_EC_KEYB=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_CROS_EC=y
 CONFIG_CROS_EC_SPI=y
 CONFIG_PWRSEQ=y
diff --git a/configs/eaidk-610-rk3399_defconfig 
b/configs/eaidk-610-rk3399_defconfig
index 22ad98b95ad3..0ca4cebc4d90 100644
--- a/configs/eaidk-610-rk3399_defconfig
+++ b/configs/eaidk-610-rk3399_defconfig
@@ -40,7 +40,6 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SDHCI=y
diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index d6140527b752..1d1e55162290 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -43,7 +43,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
 CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig
index b7c8e95b7b89..2fe38f81c50d 100644
--- a/configs/firefly-rk3399_defconfig
+++ b/configs/firefly-rk3399_defconfig
@@ -20,7 +20,6 @@ CONFIG_PCI=y
 CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-firefly.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x2e000
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -45,8 +44,6 @@ CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SDHCI=y
diff --git a/configs/khadas-edge-captain-rk3399_defconfig 
b/configs/khadas-edge-captain-rk3399_defconfig
index 7f4e48a4e750..28a59899e1cb 100644
--- a/configs/khadas-edge-captain-rk3399_defconfig
+++ b/configs/khadas-edge-captain-rk3399_defconfig
@@ -43,7 +43,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y

[PATCH v2 3/5] rockchip: rk3328: regenerate defconfigs

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Regenerate RK3328 defconfigs after adding imply statements.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Christopher Obbard 
Reviewed-by: Dragan Simic 
---
 configs/evb-rk3328_defconfig  | 3 ---
 configs/nanopi-r2c-plus-rk3328_defconfig  | 3 ---
 configs/nanopi-r2c-rk3328_defconfig   | 3 ---
 configs/nanopi-r2s-rk3328_defconfig   | 3 ---
 configs/orangepi-r1-plus-lts-rk3328_defconfig | 3 ---
 configs/orangepi-r1-plus-rk3328_defconfig | 3 ---
 configs/roc-cc-rk3328_defconfig   | 3 ---
 configs/rock-pi-e-rk3328_defconfig| 3 ---
 configs/rock64-rk3328_defconfig   | 3 ---
 9 files changed, 27 deletions(-)

diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
index 995bfd0558b1..c3bde3e5c457 100644
--- a/configs/evb-rk3328_defconfig
+++ b/configs/evb-rk3328_defconfig
@@ -30,7 +30,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -70,8 +69,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2c-plus-rk3328_defconfig 
b/configs/nanopi-r2c-plus-rk3328_defconfig
index 1cb0ed855398..1b0fa27ced16 100644
--- a/configs/nanopi-r2c-plus-rk3328_defconfig
+++ b/configs/nanopi-r2c-plus-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2c-plus.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -72,8 +71,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2c-rk3328_defconfig 
b/configs/nanopi-r2c-rk3328_defconfig
index 59801328deda..edf24623da2a 100644
--- a/configs/nanopi-r2c-rk3328_defconfig
+++ b/configs/nanopi-r2c-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2c.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -72,8 +71,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2s-rk3328_defconfig 
b/configs/nanopi-r2s-rk3328_defconfig
index 61914b1650d2..32c99dfecb86 100644
--- a/configs/nanopi-r2s-rk3328_defconfig
+++ b/configs/nanopi-r2s-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2s.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -72,8 +71,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/orangepi-r1-plus-lts-rk3328_defconfig 
b/configs/orangepi-r1-plus-lts-rk3328_defconfig
index 968110c8cd6f..f554a284d930 100644
--- a/configs/orangepi-r1-plus-lts-rk3328_defconfig
+++ b/configs/orangepi-r1-plus-lts-rk3328_defconfig
@@ -34,7 +34,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-orangepi-r1-plus-lts.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -77,8 +76,6 @@ CONFIG_FASTBOOT_BUF_ADDR=0x800800
 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
-CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_SPI_FLASH_SFDP_SUPPORT=y
diff --git a/configs/orangepi-r1-plus-rk3328_defconfig 
b/configs/orangepi-r1-plus-rk3328_defconfig
index 7038f09f202c..162032460fe0 100644
--- a/configs/orangepi-r1-plus-rk3328_defconfig
+++ b/configs/orangepi-r1-plus-rk3328_defconfig
@@ -34,7 +34,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-orangepi-r1-plus.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_

[PATCH v2 2/5] rockchip: rk3399: Read cpuid and generate MAC address from efuse

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The rockchip-efuse driver supports the efuse found on RK3399. This
hardware block is part of the SoC and contains the CPUID, which can
be used to generate stable serial numbers and MAC addresses.

Enable the driver and reading cpuid by default for RK3399.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Christopher Obbard 
Reviewed-by: Dragan Simic 
---
 arch/arm/mach-rockchip/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 0553967b947f..2c6b045c51c8 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -270,6 +270,9 @@ config ROCKCHIP_RK3399
imply SYS_BOOTCOUNT_SINGLEWORD if BOOTCOUNT_LIMIT
imply BOOTSTD_FULL
imply CMD_BOOTCOUNT if BOOTCOUNT_LIMIT
+   imply MISC
+   imply ROCKCHIP_EFUSE
+   imply MISC_INIT_R
help
  The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72
  and quad-core Cortex-A53.
-- 
2.39.2

[PATCH v2 1/5] rockchip: rk3328: Read cpuid and generate MAC address from efuse

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The rockchip-efuse driver supports the efuse found on RK3328. This
hardware block is part of the SoC and contains the CPUID, which can
be used to generate stable serial numbers and MAC addresses.

Enable the driver and reading cpuid by default for RK3328.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Christopher Obbard 
Reviewed-by: Dragan Simic 
---
 arch/arm/mach-rockchip/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 1bc7ee904275..0553967b947f 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -189,6 +189,9 @@ config ROCKCHIP_RK3328
select ENABLE_ARM_SOC_BOOT0_HOOK
select DEBUG_UART_BOARD_INIT
select SYS_NS16550
+   imply MISC
+   imply ROCKCHIP_EFUSE
+   imply MISC_INIT_R
help
  The Rockchip RK3328 is a ARM-based SoC with a quad-core Cortex-A53.
  including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
-- 
2.39.2

[PATCH v2 0/5] rockchip: Read cpuid and generate MAC address from efuse for RK3328 and RK3399

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi folks,

This is v2 of my "read cpuid and generate MAC address from efuse on
RK3328 and RK3399 by default" series.

Changes since v1:
- Also imply "CONFIG_MISC"
- Add back unintentionally removed CONFIG_OF_LIBFDT_OVERLAY=y
- Remove ROCKCHIP_OTP from nanopi-r4s-rk3399_defconfig as requested by
  Jonas

This series enables ROCKCHIP_EFUSE and MISC_INIT_R by default for RK3328
and RK3399 so that the cpuid is read from the efuse and used to generate
a serial number and MAC addresses for all boards.

This stacks on top of the recent defconfig update series [1] from Jonas.

[1] https://lore.kernel.org/u-boot/20240207000301.3270722-1-jo...@kwiboo.se/

Chen-Yu Tsai (5):
  rockchip: rk3328: Read cpuid and generate MAC address from efuse
  rockchip: rk3399: Read cpuid and generate MAC address from efuse
  rockchip: rk3328: regenerate defconfigs
  rockchip: rk3399: regenerate defconfigs
  rockchip: nanopi-r4s: Drop ROCKCHIP_OTP

 arch/arm/mach-rockchip/Kconfig| 6 ++
 configs/chromebook_bob_defconfig  | 3 ---
 configs/chromebook_kevin_defconfig| 3 ---
 configs/eaidk-610-rk3399_defconfig| 1 -
 configs/evb-rk3328_defconfig  | 3 ---
 configs/evb-rk3399_defconfig  | 1 -
 configs/firefly-rk3399_defconfig  | 3 ---
 configs/khadas-edge-captain-rk3399_defconfig  | 1 -
 configs/khadas-edge-rk3399_defconfig  | 1 -
 configs/khadas-edge-v-rk3399_defconfig| 1 -
 configs/leez-rk3399_defconfig | 1 -
 configs/nanopc-t4-rk3399_defconfig| 1 -
 configs/nanopi-m4-2gb-rk3399_defconfig| 1 -
 configs/nanopi-m4-rk3399_defconfig| 1 -
 configs/nanopi-m4b-rk3399_defconfig   | 1 -
 configs/nanopi-neo4-rk3399_defconfig  | 1 -
 configs/nanopi-r2c-plus-rk3328_defconfig  | 3 ---
 configs/nanopi-r2c-rk3328_defconfig   | 3 ---
 configs/nanopi-r2s-rk3328_defconfig   | 3 ---
 configs/nanopi-r4s-rk3399_defconfig   | 4 
 configs/orangepi-r1-plus-lts-rk3328_defconfig | 3 ---
 configs/orangepi-r1-plus-rk3328_defconfig | 3 ---
 configs/orangepi-rk3399_defconfig | 1 -
 configs/pinebook-pro-rk3399_defconfig | 3 ---
 configs/pinephone-pro-rk3399_defconfig| 3 ---
 configs/puma-rk3399_defconfig | 3 ---
 configs/roc-cc-rk3328_defconfig   | 3 ---
 configs/roc-pc-mezzanine-rk3399_defconfig | 3 ---
 configs/roc-pc-rk3399_defconfig   | 3 ---
 configs/rock-4c-plus-rk3399_defconfig | 3 ---
 configs/rock-4se-rk3399_defconfig | 3 ---
 configs/rock-pi-4-rk3399_defconfig| 3 ---
 configs/rock-pi-4c-rk3399_defconfig   | 3 ---
 configs/rock-pi-e-rk3328_defconfig| 3 ---
 configs/rock-pi-n10-rk3399pro_defconfig   | 2 --
 configs/rock64-rk3328_defconfig   | 3 ---
 configs/rock960-rk3399_defconfig  | 2 --
 configs/rockpro64-rk3399_defconfig| 3 ---
 38 files changed, 6 insertions(+), 86 deletions(-)

-- 
2.39.2

Re: [PATCH 4/4] rockchip: rk3399: regenerate defconfigs

[Chen-Yu Tsai]

On Sun, Feb 11, 2024 at 3:49 AM Jonas Karlman  wrote:
>
> Hi Chen-Yu,
>
> On 2024-02-10 07:32, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai 
> >
> > Regenerate RK3399 defconfigs after adding imply statements.
> >
> > Signed-off-by: Chen-Yu Tsai 
> > ---
> >  configs/chromebook_bob_defconfig  | 2 --
> >  configs/chromebook_kevin_defconfig| 2 --
> >  configs/firefly-rk3399_defconfig  | 2 --
> >  configs/nanopi-r4s-rk3399_defconfig   | 2 --
> >  configs/pinebook-pro-rk3399_defconfig | 2 --
> >  configs/pinephone-pro-rk3399_defconfig| 2 --
> >  configs/puma-rk3399_defconfig | 2 --
> >  configs/roc-pc-mezzanine-rk3399_defconfig | 2 --
> >  configs/roc-pc-rk3399_defconfig   | 2 --
> >  configs/rock-4c-plus-rk3399_defconfig | 3 ---
> >  configs/rock-4se-rk3399_defconfig | 3 ---
> >  configs/rock-pi-4-rk3399_defconfig| 3 ---
> >  configs/rock-pi-4c-rk3399_defconfig   | 3 ---
> >  configs/rock-pi-n10-rk3399pro_defconfig   | 1 -
> >  configs/rock960-rk3399_defconfig  | 1 -
> >  configs/rockpro64-rk3399_defconfig| 2 --
> >  16 files changed, 34 deletions(-)
> >
>
> [snip]
>
> > diff --git a/configs/rock-4c-plus-rk3399_defconfig 
> > b/configs/rock-4c-plus-rk3399_defconfig
> > index 18525c8bf504..12587b1eba10 100644
> > --- a/configs/rock-4c-plus-rk3399_defconfig
> > +++ b/configs/rock-4c-plus-rk3399_defconfig
> > @@ -8,7 +8,6 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> >  CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30
> >  CONFIG_ENV_OFFSET=0x3F8000
> >  CONFIG_DEFAULT_DEVICE_TREE="rk3399-rock-4c-plus"
> > -CONFIG_OF_LIBFDT_OVERLAY=y
>
> This patch seems to also remove a few OF_LIBFDT_OVERLAY, guessing this
> was unintentional?

Yeah, that was unintentional. I have a local patch that enables
OF_LIBFDT_OVERLAY for ARCH_ROCKCHIP by default.

> If you are re-spinning this series, please also include change to:
> - add CONFIG_MISC=y to ficus-rk3399_defconfig, its required for efuse

I suppose we should just also imply CONFIG_MISC.

> - drop CONFIG_ROCKCHIP_OTP=y from nanopi-r4s-rk3399_defconfig, soc have
>   efuse or otp and on rk3399 it is efuse

Will add a cleanup.

> And possible also drop CONFIG_NET_RANDOM_ETHADDR=y from:
> - evb-rk3399_defconfig
> - ficus-rk3399_defconfig
> - khadas-edge-captain-rk3399_defconfig
> - khadas-edge-v-rk3399_defconfig
> now that these boards will have proper ethaddr.

Will add a separate cleanup.


ChenYu

[PATCH 4/4] rockchip: rk3399: regenerate defconfigs

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Regenerate RK3399 defconfigs after adding imply statements.

Signed-off-by: Chen-Yu Tsai 
---
 configs/chromebook_bob_defconfig  | 2 --
 configs/chromebook_kevin_defconfig| 2 --
 configs/firefly-rk3399_defconfig  | 2 --
 configs/nanopi-r4s-rk3399_defconfig   | 2 --
 configs/pinebook-pro-rk3399_defconfig | 2 --
 configs/pinephone-pro-rk3399_defconfig| 2 --
 configs/puma-rk3399_defconfig | 2 --
 configs/roc-pc-mezzanine-rk3399_defconfig | 2 --
 configs/roc-pc-rk3399_defconfig   | 2 --
 configs/rock-4c-plus-rk3399_defconfig | 3 ---
 configs/rock-4se-rk3399_defconfig | 3 ---
 configs/rock-pi-4-rk3399_defconfig| 3 ---
 configs/rock-pi-4c-rk3399_defconfig   | 3 ---
 configs/rock-pi-n10-rk3399pro_defconfig   | 1 -
 configs/rock960-rk3399_defconfig  | 1 -
 configs/rockpro64-rk3399_defconfig| 2 --
 16 files changed, 34 deletions(-)

diff --git a/configs/chromebook_bob_defconfig b/configs/chromebook_bob_defconfig
index b5a5ae737e52..bffa0d33b75c 100644
--- a/configs/chromebook_bob_defconfig
+++ b/configs/chromebook_bob_defconfig
@@ -27,7 +27,6 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-bob.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_BOARD_EARLY_INIT_R=y
-CONFIG_MISC_INIT_R=y
 CONFIG_BLOBLIST=y
 CONFIG_BLOBLIST_ADDR=0x10
 CONFIG_BLOBLIST_SIZE=0x1000
@@ -68,7 +67,6 @@ CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_I2C_MUX=y
 CONFIG_CROS_EC_KEYB=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_CROS_EC=y
 CONFIG_CROS_EC_SPI=y
 CONFIG_PWRSEQ=y
diff --git a/configs/chromebook_kevin_defconfig 
b/configs/chromebook_kevin_defconfig
index 20913d2cf0fe..e14fc358c504 100644
--- a/configs/chromebook_kevin_defconfig
+++ b/configs/chromebook_kevin_defconfig
@@ -28,7 +28,6 @@ CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-gru-kevin.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_BOARD_EARLY_INIT_R=y
-CONFIG_MISC_INIT_R=y
 CONFIG_BLOBLIST=y
 CONFIG_BLOBLIST_ADDR=0x10
 CONFIG_BLOBLIST_SIZE=0x1000
@@ -69,7 +68,6 @@ CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_I2C_MUX=y
 CONFIG_CROS_EC_KEYB=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_CROS_EC=y
 CONFIG_CROS_EC_SPI=y
 CONFIG_PWRSEQ=y
diff --git a/configs/firefly-rk3399_defconfig b/configs/firefly-rk3399_defconfig
index b7c8e95b7b89..b01b1a327896 100644
--- a/configs/firefly-rk3399_defconfig
+++ b/configs/firefly-rk3399_defconfig
@@ -20,7 +20,6 @@ CONFIG_PCI=y
 CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-firefly.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x2e000
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -46,7 +45,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_MMC_SDHCI=y
diff --git a/configs/nanopi-r4s-rk3399_defconfig 
b/configs/nanopi-r4s-rk3399_defconfig
index cacaab14d21f..18a1e68aa049 100644
--- a/configs/nanopi-r4s-rk3399_defconfig
+++ b/configs/nanopi-r4s-rk3399_defconfig
@@ -17,7 +17,6 @@ CONFIG_SYS_LOAD_ADDR=0x800800
 CONFIG_DEBUG_UART=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopi-r4s.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x2e000
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -42,7 +41,6 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_ROCKCHIP_OTP=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
diff --git a/configs/pinebook-pro-rk3399_defconfig 
b/configs/pinebook-pro-rk3399_defconfig
index de357415fbe4..6b83daf07945 100644
--- a/configs/pinebook-pro-rk3399_defconfig
+++ b/configs/pinebook-pro-rk3399_defconfig
@@ -26,7 +26,6 @@ CONFIG_BOOTDELAY=3
 CONFIG_USE_PREBOOT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-pinebook-pro.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -61,7 +60,6 @@ CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_LED=y
 CONFIG_LED_GPIO=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_IO_VOLTAGE=y
 CONFIG_SPL_MMC_IO_VOLTAGE=y
 CONFIG_MMC_UHS_SUPPORT=y
diff --git a/configs/pinephone-pro-rk3399_defconfig 
b/configs/pinephone-pro-rk3399_defconfig
index d08224fe536b..96316c4b303f 100644
--- a/configs/pinephone-pro-rk3399_defconfig
+++ b/configs/pinephone-pro-rk3399_defconfig
@@ -25,7 +25,6 @@ CONFIG_BOOTDELAY=3
 CONFIG_USE_PREBOOT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-pinephone-pro.dtb"
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -60,7 +59,6 @@ CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_LED=y
 CONFIG_LED_GPIO=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_D

[PATCH 3/4] rockchip: rk3328: regenerate defconfigs

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Regenerate RK3328 defconfigs after adding imply statements.

Signed-off-by: Chen-Yu Tsai 
---
 configs/evb-rk3328_defconfig  | 2 --
 configs/nanopi-r2c-plus-rk3328_defconfig  | 2 --
 configs/nanopi-r2c-rk3328_defconfig   | 2 --
 configs/nanopi-r2s-rk3328_defconfig   | 2 --
 configs/orangepi-r1-plus-lts-rk3328_defconfig | 2 --
 configs/orangepi-r1-plus-rk3328_defconfig | 2 --
 configs/roc-cc-rk3328_defconfig   | 2 --
 configs/rock-pi-e-rk3328_defconfig| 2 --
 configs/rock64-rk3328_defconfig   | 2 --
 9 files changed, 18 deletions(-)

diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
index 995bfd0558b1..004cbd33e80a 100644
--- a/configs/evb-rk3328_defconfig
+++ b/configs/evb-rk3328_defconfig
@@ -30,7 +30,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-evb.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -71,7 +70,6 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2c-plus-rk3328_defconfig 
b/configs/nanopi-r2c-plus-rk3328_defconfig
index 1cb0ed855398..2f0d253b4b7c 100644
--- a/configs/nanopi-r2c-plus-rk3328_defconfig
+++ b/configs/nanopi-r2c-plus-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2c-plus.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -73,7 +72,6 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2c-rk3328_defconfig 
b/configs/nanopi-r2c-rk3328_defconfig
index 59801328deda..ca13eb873a72 100644
--- a/configs/nanopi-r2c-rk3328_defconfig
+++ b/configs/nanopi-r2c-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2c.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -73,7 +72,6 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/nanopi-r2s-rk3328_defconfig 
b/configs/nanopi-r2s-rk3328_defconfig
index 61914b1650d2..619707436130 100644
--- a/configs/nanopi-r2s-rk3328_defconfig
+++ b/configs/nanopi-r2s-rk3328_defconfig
@@ -31,7 +31,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-nanopi-r2s.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -73,7 +72,6 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_PHY_MOTORCOMM=y
diff --git a/configs/orangepi-r1-plus-lts-rk3328_defconfig 
b/configs/orangepi-r1-plus-lts-rk3328_defconfig
index 968110c8cd6f..8e9a9411a763 100644
--- a/configs/orangepi-r1-plus-lts-rk3328_defconfig
+++ b/configs/orangepi-r1-plus-lts-rk3328_defconfig
@@ -34,7 +34,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-orangepi-r1-plus-lts.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -78,7 +77,6 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=y
 CONFIG_MMC_DW_ROCKCHIP=y
 CONFIG_SPI_FLASH_SFDP_SUPPORT=y
diff --git a/configs/orangepi-r1-plus-rk3328_defconfig 
b/configs/orangepi-r1-plus-rk3328_defconfig
index 7038f09f202c..240fcdeb221f 100644
--- a/configs/orangepi-r1-plus-rk3328_defconfig
+++ b/configs/orangepi-r1-plus-rk3328_defconfig
@@ -34,7 +34,6 @@ CONFIG_LEGACY_IMAGE_FORMAT=y
 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-orangepi-r1-plus.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_MISC_INIT_R=y
 CONFIG_SPL_MAX_SIZE=0x4
 CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
@@ -78,7 +77,6 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
-CONFIG_ROCKCHIP_EFUSE=y
 CONFIG_MMC_DW=

[PATCH 2/4] rockchip: rk3399: Read cpuid and generate MAC address from efuse

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The rockchip-efuse driver supports the efuse found on RK3399. This
hardware block is part of the SoC and contains the CPUID, which can
be used to generate stable serial numbers and MAC addresses.

Enable the driver and reading cpuid by default for RK3399.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/mach-rockchip/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 20670fb57376..2558d956b8c6 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -269,6 +269,8 @@ config ROCKCHIP_RK3399
imply SYS_BOOTCOUNT_SINGLEWORD if BOOTCOUNT_LIMIT
imply BOOTSTD_FULL
imply CMD_BOOTCOUNT if BOOTCOUNT_LIMIT
+   imply ROCKCHIP_EFUSE
+   imply MISC_INIT_R
help
  The Rockchip RK3399 is a ARM-based SoC with a dual-core Cortex-A72
  and quad-core Cortex-A53.
-- 
2.39.2

[PATCH 1/4] rockchip: rk3328: Read cpuid and generate MAC address from efuse

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The rockchip-efuse driver supports the efuse found on RK3328. This
hardware block is part of the SoC and contains the CPUID, which can
be used to generate stable serial numbers and MAC addresses.

Enable the driver and reading cpuid by default for RK3328.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/mach-rockchip/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index 1bc7ee904275..20670fb57376 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -189,6 +189,8 @@ config ROCKCHIP_RK3328
select ENABLE_ARM_SOC_BOOT0_HOOK
select DEBUG_UART_BOARD_INIT
select SYS_NS16550
+   imply ROCKCHIP_EFUSE
+   imply MISC_INIT_R
help
  The Rockchip RK3328 is a ARM-based SoC with a quad-core Cortex-A53.
  including NEON and GPU, 1MB L2 cache, Mali-T7 graphics, two
-- 
2.39.2

[PATCH 0/4] rockchip: Read cpuid and generate MAC address from efuse for RK3328 and RK3399

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi folks,

This series enables ROCKCHIP_EFUSE and MISC_INIT_R by default for RK3328
and RK3399 so that the cpuid is read from the efuse and used to generate
a serial number and MAC addresses for all boards.

This stacks on top of the recent defconfig update series [1] from Jonas.

[1] https://lore.kernel.org/u-boot/20240207000301.3270722-1-jo...@kwiboo.se/


Chen-Yu Tsai (4):
  rockchip: rk3328: Read cpuid and generate MAC address from efuse
  rockchip: rk3399: Read cpuid and generate MAC address from efuse
  rockchip: rk3328: regenerate defconfigs
  rockchip: rk3399: regenerate defconfigs

 arch/arm/mach-rockchip/Kconfig| 4 
 configs/chromebook_bob_defconfig  | 2 --
 configs/chromebook_kevin_defconfig| 2 --
 configs/evb-rk3328_defconfig  | 2 --
 configs/firefly-rk3399_defconfig  | 2 --
 configs/nanopi-r2c-plus-rk3328_defconfig  | 2 --
 configs/nanopi-r2c-rk3328_defconfig   | 2 --
 configs/nanopi-r2s-rk3328_defconfig   | 2 --
 configs/nanopi-r4s-rk3399_defconfig   | 2 --
 configs/orangepi-r1-plus-lts-rk3328_defconfig | 2 --
 configs/orangepi-r1-plus-rk3328_defconfig | 2 --
 configs/pinebook-pro-rk3399_defconfig | 2 --
 configs/pinephone-pro-rk3399_defconfig| 2 --
 configs/puma-rk3399_defconfig | 2 --
 configs/roc-cc-rk3328_defconfig   | 2 --
 configs/roc-pc-mezzanine-rk3399_defconfig | 2 --
 configs/roc-pc-rk3399_defconfig   | 2 --
 configs/rock-4c-plus-rk3399_defconfig | 3 ---
 configs/rock-4se-rk3399_defconfig | 3 ---
 configs/rock-pi-4-rk3399_defconfig| 3 ---
 configs/rock-pi-4c-rk3399_defconfig   | 3 ---
 configs/rock-pi-e-rk3328_defconfig| 2 --
 configs/rock-pi-n10-rk3399pro_defconfig   | 1 -
 configs/rock64-rk3328_defconfig   | 2 --
 configs/rock960-rk3399_defconfig  | 1 -
 configs/rockpro64-rk3399_defconfig| 2 --
 26 files changed, 4 insertions(+), 52 deletions(-)

-- 
2.39.2

Re: [PATCH 04/15] rockchip: rk3328-roc-cc: Update defconfig

[Chen-Yu Tsai]

On Wed, Feb 7, 2024 at 8:04 AM Jonas Karlman  wrote:
>
> Update defconfig for rk3328-roc-cc with new defaults.
>
> Remove the SPL_DRIVERS_MISC=y option, no misc driver is used in SPL.
>
> Add CONFIG_SPL_FIT_SIGNATURE=y to let SPL verify an auto generated hash
> of FIT images. This help indicate if there is an issue loading any of
> the images to DRAM or SRAM. Also add LEGACY_IMAGE_FORMAT=y to keep
> support for scripts.
>
> Add ROCKCHIP_EFUSE=y and remove NET_RANDOM_ETHADDR=y, ethaddr and
> eth1addr is set based on cpuid read from eFUSE.

I wonder if it would make sense to enable ROCKCHIP_EFUSE or ROCKCHIP_OTP
for the respective SoCs by default, either with "imply" under the SoC
Kconfig options, or "default if XXX" under the driver Kconfig options?
Not sure which is preferred.

Same goes for CONFIG_MISC_INIT_R for actually generating the serial number
and MAC addresses from the efuse/OTP.

At least for RK3566 and RK3588 we are implying these options.


ChenYu

> Add SPL_DM_SEQ_ALIAS=y option to use alias sequence number in SPL.
>
> Add DM_ETH_PHY=y, PHY_MOTORCOMM=y and PHY_REALTEK=y to support common
> ethernet PHYs.
>
> Add RNG_ROCKCHIP=y and DM_RNG=y options to support the onboard random
> generator.
>
> Also add missing device tree file to MAINTAINERS and add myself as a
> reviewer for this board.
>
> Signed-off-by: Jonas Karlman 
> ---
>  board/rockchip/evb_rk3328/MAINTAINERS | 2 ++
>  configs/roc-cc-rk3328_defconfig   | 9 +++--
>  doc/board/rockchip/rockchip.rst   | 2 +-
>  3 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/board/rockchip/evb_rk3328/MAINTAINERS 
> b/board/rockchip/evb_rk3328/MAINTAINERS
> index 419bc8ded375..09488eaf083f 100644
> --- a/board/rockchip/evb_rk3328/MAINTAINERS
> +++ b/board/rockchip/evb_rk3328/MAINTAINERS
> @@ -41,8 +41,10 @@ F:  
> arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
>  ROC-RK3328-CC
>  M:  Loic Devulder 
>  M:  Chen-Yu Tsai 
> +R:  Jonas Karlman 
>  S:  Maintained
>  F:  configs/roc-cc-rk3328_defconfig
> +F:  arch/arm/dts/rk3328-roc-cc.dts
>  F:  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
>
>  ROCK64-RK3328
> diff --git a/configs/roc-cc-rk3328_defconfig b/configs/roc-cc-rk3328_defconfig
> index 4ac3c9403b02..7d81a715ef25 100644
> --- a/configs/roc-cc-rk3328_defconfig
> +++ b/configs/roc-cc-rk3328_defconfig
> @@ -15,7 +15,6 @@ CONFIG_ROCKCHIP_RK3328=y
>  CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
>  CONFIG_TPL_LIBCOMMON_SUPPORT=y
>  CONFIG_TPL_LIBGENERIC_SUPPORT=y
> -CONFIG_SPL_DRIVERS_MISC=y
>  CONFIG_SPL_STACK_R_ADDR=0x60
>  CONFIG_SPL_STACK=0x40
>  CONFIG_TPL_SYS_MALLOC_F_LEN=0x800
> @@ -26,7 +25,9 @@ CONFIG_DEBUG_UART=y
>  # CONFIG_ANDROID_BOOT_IMAGE is not set
>  CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
> +CONFIG_SPL_FIT_SIGNATURE=y
>  CONFIG_SPL_LOAD_FIT=y
> +CONFIG_LEGACY_IMAGE_FORMAT=y
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-roc-cc.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> @@ -58,8 +59,8 @@ CONFIG_TPL_OF_PLATDATA=y
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_SYS_MMC_ENV_DEV=1
> -CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_TPL_DM=y
> +CONFIG_SPL_DM_SEQ_ALIAS=y
>  CONFIG_REGMAP=y
>  CONFIG_SPL_REGMAP=y
>  CONFIG_TPL_REGMAP=y
> @@ -73,9 +74,11 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
>  CONFIG_ROCKCHIP_GPIO=y
>  CONFIG_SYS_I2C_ROCKCHIP=y
>  CONFIG_MISC=y
> +CONFIG_ROCKCHIP_EFUSE=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_ROCKCHIP=y
>  CONFIG_PHY_REALTEK=y
> +CONFIG_DM_ETH_PHY=y
>  CONFIG_PHY_GIGE=y
>  CONFIG_ETH_DESIGNWARE=y
>  CONFIG_GMAC_ROCKCHIP=y
> @@ -95,6 +98,8 @@ CONFIG_PWM_ROCKCHIP=y
>  CONFIG_RAM=y
>  CONFIG_SPL_RAM=y
>  CONFIG_TPL_RAM=y
> +CONFIG_DM_RNG=y
> +CONFIG_RNG_ROCKCHIP=y
>  CONFIG_BAUDRATE=150
>  CONFIG_DEBUG_UART_SHIFT=2
>  CONFIG_SYS_NS16550_MEM32=y
> diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
> index de2195deadca..99f48b6d6fa5 100644
> --- a/doc/board/rockchip/rockchip.rst
> +++ b/doc/board/rockchip/rockchip.rst
> @@ -60,8 +60,8 @@ List of mainline supported Rockchip boards:
>   - ODROID-GO Advance (odroid-go2)
>  * rk3328
>   - Rockchip Evb-RK3328 (evb-rk3328)
> + - Firefly ROC-RK3328-CC (roc-cc-rk3328)
>   - Pine64 Rock64 (rock64-rk3328)
> - - Firefly-RK3328 (roc-cc-rk3328)
>   - Radxa Rockpi E (rock-pi-e-rk3328)
>  * rk3368
>   - GeekBox (geekbox)
> --
> 2.43.0
>

Re: [PATCH 04/15] rockchip: rk3328-roc-cc: Update defconfig

[Chen-Yu Tsai]

(Resend from subscribed address.)

On Wed, Feb 7, 2024 at 8:04 AM Jonas Karlman  wrote:
>
> Update defconfig for rk3328-roc-cc with new defaults.
>
> Remove the SPL_DRIVERS_MISC=y option, no misc driver is used in SPL.
>
> Add CONFIG_SPL_FIT_SIGNATURE=y to let SPL verify an auto generated hash
> of FIT images. This help indicate if there is an issue loading any of
> the images to DRAM or SRAM. Also add LEGACY_IMAGE_FORMAT=y to keep
> support for scripts.
>
> Add ROCKCHIP_EFUSE=y and remove NET_RANDOM_ETHADDR=y, ethaddr and
> eth1addr is set based on cpuid read from eFUSE.

I wonder if it would make sense to enable ROCKCHIP_EFUSE or ROCKCHIP_OTP
for the respective SoCs by default, either with "imply" under the SoC
Kconfig options, or "default if XXX" under the driver Kconfig options?
Not sure which is preferred.

Same goes for CONFIG_MISC_INIT_R for actually generating the serial number
and MAC addresses from the efuse/OTP.

At least for RK3566 and RK3588 these options are implied.


ChenYu

> Add SPL_DM_SEQ_ALIAS=y option to use alias sequence number in SPL.
>
> Add DM_ETH_PHY=y, PHY_MOTORCOMM=y and PHY_REALTEK=y to support common
> ethernet PHYs.
>
> Add RNG_ROCKCHIP=y and DM_RNG=y options to support the onboard random
> generator.
>
> Also add missing device tree file to MAINTAINERS and add myself as a
> reviewer for this board.
>
> Signed-off-by: Jonas Karlman 
> ---
>  board/rockchip/evb_rk3328/MAINTAINERS | 2 ++
>  configs/roc-cc-rk3328_defconfig   | 9 +++--
>  doc/board/rockchip/rockchip.rst   | 2 +-
>  3 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/board/rockchip/evb_rk3328/MAINTAINERS 
> b/board/rockchip/evb_rk3328/MAINTAINERS
> index 419bc8ded375..09488eaf083f 100644
> --- a/board/rockchip/evb_rk3328/MAINTAINERS
> +++ b/board/rockchip/evb_rk3328/MAINTAINERS
> @@ -41,8 +41,10 @@ F:  
> arch/arm/dts/rk3328-orangepi-r1-plus-lts-u-boot.dtsi
>  ROC-RK3328-CC
>  M:  Loic Devulder 
>  M:  Chen-Yu Tsai 
> +R:  Jonas Karlman 
>  S:  Maintained
>  F:  configs/roc-cc-rk3328_defconfig
> +F:  arch/arm/dts/rk3328-roc-cc.dts
>  F:  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
>
>  ROCK64-RK3328
> diff --git a/configs/roc-cc-rk3328_defconfig b/configs/roc-cc-rk3328_defconfig
> index 4ac3c9403b02..7d81a715ef25 100644
> --- a/configs/roc-cc-rk3328_defconfig
> +++ b/configs/roc-cc-rk3328_defconfig
> @@ -15,7 +15,6 @@ CONFIG_ROCKCHIP_RK3328=y
>  CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y
>  CONFIG_TPL_LIBCOMMON_SUPPORT=y
>  CONFIG_TPL_LIBGENERIC_SUPPORT=y
> -CONFIG_SPL_DRIVERS_MISC=y
>  CONFIG_SPL_STACK_R_ADDR=0x60
>  CONFIG_SPL_STACK=0x40
>  CONFIG_TPL_SYS_MALLOC_F_LEN=0x800
> @@ -26,7 +25,9 @@ CONFIG_DEBUG_UART=y
>  # CONFIG_ANDROID_BOOT_IMAGE is not set
>  CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
> +CONFIG_SPL_FIT_SIGNATURE=y
>  CONFIG_SPL_LOAD_FIT=y
> +CONFIG_LEGACY_IMAGE_FORMAT=y
>  CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-roc-cc.dtb"
>  # CONFIG_DISPLAY_CPUINFO is not set
>  CONFIG_DISPLAY_BOARDINFO_LATE=y
> @@ -58,8 +59,8 @@ CONFIG_TPL_OF_PLATDATA=y
>  CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>  CONFIG_SYS_MMC_ENV_DEV=1
> -CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_TPL_DM=y
> +CONFIG_SPL_DM_SEQ_ALIAS=y
>  CONFIG_REGMAP=y
>  CONFIG_SPL_REGMAP=y
>  CONFIG_TPL_REGMAP=y
> @@ -73,9 +74,11 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
>  CONFIG_ROCKCHIP_GPIO=y
>  CONFIG_SYS_I2C_ROCKCHIP=y
>  CONFIG_MISC=y
> +CONFIG_ROCKCHIP_EFUSE=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_DW_ROCKCHIP=y
>  CONFIG_PHY_REALTEK=y
> +CONFIG_DM_ETH_PHY=y
>  CONFIG_PHY_GIGE=y
>  CONFIG_ETH_DESIGNWARE=y
>  CONFIG_GMAC_ROCKCHIP=y
> @@ -95,6 +98,8 @@ CONFIG_PWM_ROCKCHIP=y
>  CONFIG_RAM=y
>  CONFIG_SPL_RAM=y
>  CONFIG_TPL_RAM=y
> +CONFIG_DM_RNG=y
> +CONFIG_RNG_ROCKCHIP=y
>  CONFIG_BAUDRATE=150
>  CONFIG_DEBUG_UART_SHIFT=2
>  CONFIG_SYS_NS16550_MEM32=y
> diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
> index de2195deadca..99f48b6d6fa5 100644
> --- a/doc/board/rockchip/rockchip.rst
> +++ b/doc/board/rockchip/rockchip.rst
> @@ -60,8 +60,8 @@ List of mainline supported Rockchip boards:
>   - ODROID-GO Advance (odroid-go2)
>  * rk3328
>   - Rockchip Evb-RK3328 (evb-rk3328)
> + - Firefly ROC-RK3328-CC (roc-cc-rk3328)
>   - Pine64 Rock64 (rock64-rk3328)
> - - Firefly-RK3328 (roc-cc-rk3328)
>   - Radxa Rockpi E (rock-pi-e-rk3328)
>  * rk3368
>   - GeekBox (geekbox)
> --
> 2.43.0
>

Re: Proposal: FIT support for extension boards / overlays

[Chen-Yu Tsai]

On Thu, Dec 28, 2023 at 1:49 AM Simon Glass  wrote:
>
> Hi Heinrich,
>
> On Tue, Dec 12, 2023 at 3:43 PM Heinrich Schuchardt  
> wrote:
> >
> > On 12.12.23 15:05, Simon Glass wrote:
> > > Hi,
> > >
> > > The devicetree files for a board can be quite large, perhaps around
> > > 60KB. To boot on any supported board, many of them need to be
> > > provided, typically hundreds.
> > >
> > > All boards for a particular SoC share common parts.  It would be
> > > helpful to use overlays for common pieces, to reduce the overall size.
> > >
> > > Some boards have extension add-ons which have their own devicetree
> > > overlays. It would be helpful to know which ones should be applied for
> > > a particular extension.
> > >
> > > I propose implementing extensions in FIT. This has a new '/extensions'
> > > node, so you can specify what extensions are available for each FIT
> > > configuration.
> > >
> > > For example:
> > >
> > > / {
> > >images {
> > >  kernel {
> > >// common kernel
> > >  };
> > >
> > >  fdt-1 {
> > >// FDT for board1
> > >  };
> > >
> > >  fdto-1 {
> > >// FDT overlay
> > >  };
> > >
> > >  fdto-2 {
> > >// FDT overlay
> > >  };
> > >
> > >  fdto-3 {
> > >// FDT overlay
> > >  };
> > >};
> > >
> > >configurations {
> > >  conf-1 {
> > >  compatible = ...
> > >  fdt = "fdt-1";
> > >  extensions = "ext1", "ext-2";
> >
> > Shouldn't there be braces around the item list?
>
> I don't think so.
>
> >
> > How do you specify optional and required but otherwise unrelated
> > extensions for a configuration?
>
> Do we actually need to know which extensions are required or optional?
> Do you have an example?

If an extension is required for a device, then it wouldn't be an extension
per se. The referenced DT overlay should be directly tied to the device
compatible through the configuration node.

If say "ext-3" depends on "ext-1" (assuming that is one definition of
"required"), then based on the syntax I believe "ext-3" should only
be listed in the "extensions" property under "ext-1", and not the
base configuration?

> > >  };
> > >};
> > >
> > >extensions {
> > >  ext-1 {
> > >  fdto = "fdto-1";   // FDT overlay for this 'cape' or 'hat'
> > >  kernel = "kernel-1";
> > >  compatible = "vendor,combined-device1";
> > >  extensions = "ext-3";
> > >  };
> > >
> > >  ext-2 {
> > >  fdto = "fdto-2";   // fdt overlay for this 'cape'
> > >  compatible = "vendor,device2";
> > >  };
> > >
> > >  ext-3 {
> > >  fdto = "fdto-3";
> > >  compatible = "vendor,device3";
> > >  };
> > >};
> > > };
> > >
> > > So FIT configurations have a list of supported extensions. The
> > > extensions are hierarchical so that you can have ext-1 which can
> > > optionally have ext-2 as well. This allows boards to share a common
> >
> > ext2 seems not to be related to ext-3. Do you mean ext-3 optionally
> > extending ext-1? How would you specify that ext-n is required for ext-m
> > to work?
>
> Yes, I mean "optionally extending ext2". Again, I don't consider
> required extensions here.

See above for my take on extension dependencies.

ChenYu

> > The sequence of applying overlays may make a difference. I cannot see
> > that your current suggestion defines a sequence in which the overlays
> > are applied.
> >
> > > SoC to add in overlays as needed by their board. It also allows common
> > > 'capes' or 'hats' to be specified only once and used by a group of
> > > boards which share the same interface.
> > >
> > > Within U-Boot, extensions actually present are declared by a sysinfo
> > > driver for the board, with new methods:
> > >
> > > get_compat() - determine the compatible strings for the current platform
> > > get_ext() - get a list of compatible strings for extensions which are
> > > actually present
> >
> > Do you expect U-Boot to have code that injects device-tree fragments
> > with a compatible string into the control FDT after discovering add-ons?
>
> Yes, that's right, by applying overlays.
>
> >
> > Why can't we simply write the compatible constraint into the overlay
> > definition (fdto-#) and enumerate the overlays in the configuration?
>
> Yes, that is the example quoted below.
>
> >
> > On some busses detection is problematic. Two alternative add-ons may use
> > the same SPI address but need different FDT overlays.
>
> If there is no way to detect the extension, then it cannot work anyway, right?
>
> BTW I am not suggesting that the bus is used for detection, although I
> suppose this is possible. More likely there are GPIOs which can be
> decoded to indicate the extension, or perhaps an I2C EEPROM.
>
>
> >
> > Best regards
> >
> > Heinrich
> >
> >
> > >
> > > The extension compatible-strings are used to select the correct things
> > > from the FIT, apply the overlays and produce the final DT.
> > >
> > > 

Re: Proposal: FIT support for extension boards / overlays

[Chen-Yu Tsai]

On Tue, Dec 12, 2023 at 10:06 PM Simon Glass  wrote:
>
> Hi,
>
> The devicetree files for a board can be quite large, perhaps around
> 60KB. To boot on any supported board, many of them need to be
> provided, typically hundreds.
>
> All boards for a particular SoC share common parts.  It would be
> helpful to use overlays for common pieces, to reduce the overall size.
>
> Some boards have extension add-ons which have their own devicetree
> overlays. It would be helpful to know which ones should be applied for
> a particular extension.
>
> I propose implementing extensions in FIT. This has a new '/extensions'
> node, so you can specify what extensions are available for each FIT
> configuration.
>
> For example:
>
> / {
>   images {
> kernel {
>   // common kernel
> };
>
> fdt-1 {
>   // FDT for board1
> };
>
> fdto-1 {
>   // FDT overlay
> };
>
> fdto-2 {
>   // FDT overlay
> };
>
> fdto-3 {
>   // FDT overlay
> };
>   };
>
>   configurations {
> conf-1 {
> compatible = ...
> fdt = "fdt-1";
> extensions = "ext1", "ext-2";
> };
>   };
>
>   extensions {
> ext-1 {
> fdto = "fdto-1";   // FDT overlay for this 'cape' or 'hat'
> kernel = "kernel-1";
> compatible = "vendor,combined-device1";

I think the example would be a bit better if the extension compatibles
were something like "vendor,device-X-feature-Y", so as not to be confused
with device-specific compatibles for the configurations.

> extensions = "ext-3";

I assume this means "existence of ext-1 makes ext-3 a valid option"?

I think a valid example would come in the form of:
- ext-1 as a M.2 E-key hat, and
- ext-3 as a WiFi/BT combo adapter for the M.2 slot, with BT UART and/or
  GPIOs described

> };
>
> ext-2 {
> fdto = "fdto-2";   // fdt overlay for this 'cape'
> compatible = "vendor,device2";
> };
>
> ext-3 {
> fdto = "fdto-3";
> compatible = "vendor,device3";
> };
>   };
> };
>
> So FIT configurations have a list of supported extensions. The
> extensions are hierarchical so that you can have ext-1 which can
> optionally have ext-2 as well. This allows boards to share a common
> SoC to add in overlays as needed by their board. It also allows common
> 'capes' or 'hats' to be specified only once and used by a group of
> boards which share the same interface.
>
> Within U-Boot, extensions actually present are declared by a sysinfo
> driver for the board, with new methods:
>
> get_compat() - determine the compatible strings for the current platform
> get_ext() - get a list of compatible strings for extensions which are
> actually present
>
> The extension compatible-strings are used to select the correct things
> from the FIT, apply the overlays and produce the final DT.
>
> To make this simpler for the common case (without extensions), we can
> allow multiple FDT images for a configuration, with the first one
> being the base SoC .dtb and the others being the .dtbo overlay(s) for
> the board:
>
> confi-1 {
> compatible = ...
> fdt = "fdt-1", "fdto-1";
> };

I thought this was already supported? At least that is what the FIT image
spec says:

Unit name of the corresponding fdt blob (component image node of a
"fdt type"). Additional fdt overlay nodes can be supplied which
signify that the resulting device tree blob is generated by the
first base fdt blob with all subsequent overlays applied.

> Comments welcome.

Very happy to see this. This could help cut down the DT duplication for
some of the ARM Chromebooks.


Thanks
ChenYu

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Chen-Yu Tsai]

On Tue, Jan 9, 2024 at 9:47 PM Masahiro Yamada  wrote:
>
> On Fri, Dec 29, 2023 at 3:39 PM Simon Glass  wrote:
> >
> > Hi Masahiro,
> >
> > On Thu, Dec 14, 2023 at 7:34 AM Masahiro Yamada  
> > wrote:
> > >
> > > On Thu, Dec 14, 2023 at 3:12 PM Masahiro Yamada  
> > > wrote:
> > > >
> > > > On Thu, Dec 14, 2023 at 1:03 PM Chen-Yu Tsai  wrote:
> > > > >
> > > > > On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven 
> > > > >  wrote:
> > > > > >
> > > > > > Hi Laurent,
> > > > > >
> > > > > > On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
> > > > > >  wrote:
> > > > > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > > > > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > > > > > > >  wrote:
> > > > > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart 
> > > > > > > > > > wrote:
> > > > > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a 
> > > > > > > > > > > > single file
> > > > > > > > > > > > containing the built kernel and associated devicetree 
> > > > > > > > > > > > files.
> > > > > > > > > > > > Compression defaults to gzip which gives a good balance 
> > > > > > > > > > > > of size and
> > > > > > > > > > > > performance.
> > > > > > > > > > > >
> > > > > > > > > > > > The files compress from about 86MB to 24MB using this 
> > > > > > > > > > > > approach.
> > > > > > > > > > > >
> > > > > > > > > > > > The FIT can be used by bootloaders which support it, 
> > > > > > > > > > > > such as U-Boot
> > > > > > > > > > > > and Linuxboot. It permits automatic selection of the 
> > > > > > > > > > > > correct
> > > > > > > > > > > > devicetree, matching the compatible string of the 
> > > > > > > > > > > > running board with
> > > > > > > > > > > > the closest compatible string in the FIT. There is no 
> > > > > > > > > > > > need for
> > > > > > > > > > > > filenames or other workarounds.
> > > > > > > > > > > >
> > > > > > > > > > > > Add a 'make image.fit' build target for arm64, as well. 
> > > > > > > > > > > > Use
> > > > > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > > > > >
> > > > > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > > > > >
> > > > > > > > > > > > This features requires pylibfdt (use 'pip install 
> > > > > > > > > > > > libfdt'). It also
> > > > > > > > > > > > requires compression utilities for the algorithm being 
> > > > > > > > > > > > used. Supported
> > > > > > > > > > > > compression options are the same as the Image.xxx 
> > > > > > > > > > > > files. For now there
> > > > > > > > > > > > is no way to change the compression other than by 
> > > > > > > > > > > > editing the rule for
> > > > > > > > > > > > $(obj)/image.fit
> > > > > > > > > > > >
> > > > > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is 
> > > > > > > > > > > > made to support
> > > > > > > > > > > > this here, since it must be 

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Chen-Yu Tsai]

On Fri, Dec 29, 2023 at 2:39 PM Simon Glass  wrote:
>
> Hi Masahiro,
>
> On Thu, Dec 14, 2023 at 7:34 AM Masahiro Yamada  wrote:
> >
> > On Thu, Dec 14, 2023 at 3:12 PM Masahiro Yamada  
> > wrote:
> > >
> > > On Thu, Dec 14, 2023 at 1:03 PM Chen-Yu Tsai  wrote:
> > > >
> > > > On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven 
> > > >  wrote:
> > > > >
> > > > > Hi Laurent,
> > > > >
> > > > > On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
> > > > >  wrote:
> > > > > > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > > > > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > > > > > >  wrote:
> > > > > > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart 
> > > > > > > > > wrote:
> > > > > > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > > > > > Add a script which produces a Flat Image Tree (FIT), a 
> > > > > > > > > > > single file
> > > > > > > > > > > containing the built kernel and associated devicetree 
> > > > > > > > > > > files.
> > > > > > > > > > > Compression defaults to gzip which gives a good balance 
> > > > > > > > > > > of size and
> > > > > > > > > > > performance.
> > > > > > > > > > >
> > > > > > > > > > > The files compress from about 86MB to 24MB using this 
> > > > > > > > > > > approach.
> > > > > > > > > > >
> > > > > > > > > > > The FIT can be used by bootloaders which support it, such 
> > > > > > > > > > > as U-Boot
> > > > > > > > > > > and Linuxboot. It permits automatic selection of the 
> > > > > > > > > > > correct
> > > > > > > > > > > devicetree, matching the compatible string of the running 
> > > > > > > > > > > board with
> > > > > > > > > > > the closest compatible string in the FIT. There is no 
> > > > > > > > > > > need for
> > > > > > > > > > > filenames or other workarounds.
> > > > > > > > > > >
> > > > > > > > > > > Add a 'make image.fit' build target for arm64, as well. 
> > > > > > > > > > > Use
> > > > > > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > > > > > >
> > > > > > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > > > > > >
> > > > > > > > > > > This features requires pylibfdt (use 'pip install 
> > > > > > > > > > > libfdt'). It also
> > > > > > > > > > > requires compression utilities for the algorithm being 
> > > > > > > > > > > used. Supported
> > > > > > > > > > > compression options are the same as the Image.xxx files. 
> > > > > > > > > > > For now there
> > > > > > > > > > > is no way to change the compression other than by editing 
> > > > > > > > > > > the rule for
> > > > > > > > > > > $(obj)/image.fit
> > > > > > > > > > >
> > > > > > > > > > > While FIT supports a ramdisk / initrd, no attempt is made 
> > > > > > > > > > > to support
> > > > > > > > > > > this here, since it must be built separately from the 
> > > > > > > > > > > Linux build.
> > > > > > > > > >
> > > > > > > > > > FIT images are very useful, so I think this is a very 
> > > > > > > > > > welcome addition
> > > > > > > > > > to the kernel build system. It can get tricky though: given 
> >

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Chen-Yu Tsai]

On Sun, Dec 10, 2023 at 1:31 AM Geert Uytterhoeven  wrote:
>
> Hi Laurent,
>
> On Sat, Dec 9, 2023 at 4:29 PM Laurent Pinchart
>  wrote:
> > On Sat, Dec 09, 2023 at 10:13:59PM +0900, Chen-Yu Tsai wrote:
> > > On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
> > >  wrote:
> > > > On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > > > > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > > > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > > > > containing the built kernel and associated devicetree files.
> > > > > > > Compression defaults to gzip which gives a good balance of size 
> > > > > > > and
> > > > > > > performance.
> > > > > > >
> > > > > > > The files compress from about 86MB to 24MB using this approach.
> > > > > > >
> > > > > > > The FIT can be used by bootloaders which support it, such as 
> > > > > > > U-Boot
> > > > > > > and Linuxboot. It permits automatic selection of the correct
> > > > > > > devicetree, matching the compatible string of the running board 
> > > > > > > with
> > > > > > > the closest compatible string in the FIT. There is no need for
> > > > > > > filenames or other workarounds.
> > > > > > >
> > > > > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > > > > FIT_COMPRESSION to select a different algorithm.
> > > > > > >
> > > > > > > The FIT can be examined using 'dumpimage -l'.
> > > > > > >
> > > > > > > This features requires pylibfdt (use 'pip install libfdt'). It 
> > > > > > > also
> > > > > > > requires compression utilities for the algorithm being used. 
> > > > > > > Supported
> > > > > > > compression options are the same as the Image.xxx files. For now 
> > > > > > > there
> > > > > > > is no way to change the compression other than by editing the 
> > > > > > > rule for
> > > > > > > $(obj)/image.fit
> > > > > > >
> > > > > > > While FIT supports a ramdisk / initrd, no attempt is made to 
> > > > > > > support
> > > > > > > this here, since it must be built separately from the Linux build.
> > > > > >
> > > > > > FIT images are very useful, so I think this is a very welcome 
> > > > > > addition
> > > > > > to the kernel build system. It can get tricky though: given the
> > > > > > versatile nature of FIT images, there can't be any
> > > > > > one-size-fits-them-all solution to build them, and striking the 
> > > > > > right
> > > > > > balance between what makes sense for the kernel and the features 
> > > > > > that
> > > > > > users may request will probably lead to bikeshedding. As we all love
> > > > > > bikeshedding, I thought I would start selfishly, with a personal use
> > > > > > case :-) This isn't a yak-shaving request though, I don't see any 
> > > > > > reason
> > > > > > to delay merging this series.
> > > > > >
> > > > > > Have you envisioned building FIT images with a subset of DTBs, or 
> > > > > > adding
> > > > > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > > > > extending the supported command line arguments. It would perhaps be 
> > > > > > more
> > > > > > difficult to integrate in the kernel build system though. This 
> > > > > > leads me
> > > > > > to a second question: would you consider merging extensions to this
> > > > > > script if they are not used by the kernel build system, but meant 
> > > > > > for
> > > > > > users who manually invoke the script ? More generally, is the script
> > > > >
> > > > > We'd also be interested in some customization, though in a different 
> > > > > way.
> > > > > We imagine having a rule file that says X 

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Chen-Yu Tsai]

On Thu, Dec 7, 2023 at 11:38 PM Laurent Pinchart
 wrote:
>
> On Thu, Dec 07, 2023 at 10:27:23PM +0800, Chen-Yu Tsai wrote:
> > On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> > > Hi Simon,
> > >
> > > Thank you for the patch.
> > >
> > > On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > > > Add a script which produces a Flat Image Tree (FIT), a single file
> > > > containing the built kernel and associated devicetree files.
> > > > Compression defaults to gzip which gives a good balance of size and
> > > > performance.
> > > >
> > > > The files compress from about 86MB to 24MB using this approach.
> > > >
> > > > The FIT can be used by bootloaders which support it, such as U-Boot
> > > > and Linuxboot. It permits automatic selection of the correct
> > > > devicetree, matching the compatible string of the running board with
> > > > the closest compatible string in the FIT. There is no need for
> > > > filenames or other workarounds.
> > > >
> > > > Add a 'make image.fit' build target for arm64, as well. Use
> > > > FIT_COMPRESSION to select a different algorithm.
> > > >
> > > > The FIT can be examined using 'dumpimage -l'.
> > > >
> > > > This features requires pylibfdt (use 'pip install libfdt'). It also
> > > > requires compression utilities for the algorithm being used. Supported
> > > > compression options are the same as the Image.xxx files. For now there
> > > > is no way to change the compression other than by editing the rule for
> > > > $(obj)/image.fit
> > > >
> > > > While FIT supports a ramdisk / initrd, no attempt is made to support
> > > > this here, since it must be built separately from the Linux build.
> > >
> > > FIT images are very useful, so I think this is a very welcome addition
> > > to the kernel build system. It can get tricky though: given the
> > > versatile nature of FIT images, there can't be any
> > > one-size-fits-them-all solution to build them, and striking the right
> > > balance between what makes sense for the kernel and the features that
> > > users may request will probably lead to bikeshedding. As we all love
> > > bikeshedding, I thought I would start selfishly, with a personal use
> > > case :-) This isn't a yak-shaving request though, I don't see any reason
> > > to delay merging this series.
> > >
> > > Have you envisioned building FIT images with a subset of DTBs, or adding
> > > DTBOs ? Both would be fairly trivial extensions to this script by
> > > extending the supported command line arguments. It would perhaps be more
> > > difficult to integrate in the kernel build system though. This leads me
> > > to a second question: would you consider merging extensions to this
> > > script if they are not used by the kernel build system, but meant for
> > > users who manually invoke the script ? More generally, is the script
> >
> > We'd also be interested in some customization, though in a different way.
> > We imagine having a rule file that says X compatible string should map
> > to A base DTB, plus B and C DTBO for the configuration section. The base
> > DTB would carry all common elements of some device, while the DTBOs
> > carry all the possible second source components, like different display
> > panels or MIPI cameras for instance. This could drastically reduce the
> > size of FIT images in ChromeOS by deduplicating all the common stuff.
>
> Do you envision the "mapping" compatible string mapping to a config
> section in the FIT image, that would bundle the base DTB and the DTBOs ?

That's exactly the idea. The mapping compatible string could be untied
from the base board's compatible string if needed (which we probably do).

So something like:

config {
config-1 {
compatible = "google,krane-sku0";
fdt = "krane-baseboard", "krane-sku0-overlay";
};
};

With "krane-sku0-overlay" being an overlay that holds the differences
between the SKUs, in this case the display panel and MIPI camera (not
upstreamed) that applies to SKU0 in particular.

Sorry for not giving a more concrete idea.


ChenYu

> > > meant to be used stand-alone as well, in which case its command line
> > > arguments need to remain backward-compatible, or do you see it as being
> > > internal to the kernel ?
> >
> > [...]
> >
> > ChenYu
>
> --
> Regards,
>
> Laurent Pinchart

Re: [PATCH v9 2/2] arm64: boot: Support Flat Image Tree

[Chen-Yu Tsai]

On Sun, Dec 03, 2023 at 05:34:01PM +0200, Laurent Pinchart wrote:
> Hi Simon,
> 
> Thank you for the patch.
> 
> On Fri, Dec 01, 2023 at 08:54:42PM -0700, Simon Glass wrote:
> > Add a script which produces a Flat Image Tree (FIT), a single file
> > containing the built kernel and associated devicetree files.
> > Compression defaults to gzip which gives a good balance of size and
> > performance.
> > 
> > The files compress from about 86MB to 24MB using this approach.
> > 
> > The FIT can be used by bootloaders which support it, such as U-Boot
> > and Linuxboot. It permits automatic selection of the correct
> > devicetree, matching the compatible string of the running board with
> > the closest compatible string in the FIT. There is no need for
> > filenames or other workarounds.
> > 
> > Add a 'make image.fit' build target for arm64, as well. Use
> > FIT_COMPRESSION to select a different algorithm.
> > 
> > The FIT can be examined using 'dumpimage -l'.
> > 
> > This features requires pylibfdt (use 'pip install libfdt'). It also
> > requires compression utilities for the algorithm being used. Supported
> > compression options are the same as the Image.xxx files. For now there
> > is no way to change the compression other than by editing the rule for
> > $(obj)/image.fit
> > 
> > While FIT supports a ramdisk / initrd, no attempt is made to support
> > this here, since it must be built separately from the Linux build.
> 
> FIT images are very useful, so I think this is a very welcome addition
> to the kernel build system. It can get tricky though: given the
> versatile nature of FIT images, there can't be any
> one-size-fits-them-all solution to build them, and striking the right
> balance between what makes sense for the kernel and the features that
> users may request will probably lead to bikeshedding. As we all love
> bikeshedding, I thought I would start selfishly, with a personal use
> case :-) This isn't a yak-shaving request though, I don't see any reason
> to delay merging this series.
> 
> Have you envisioned building FIT images with a subset of DTBs, or adding
> DTBOs ? Both would be fairly trivial extensions to this script by
> extending the supported command line arguments. It would perhaps be more
> difficult to integrate in the kernel build system though. This leads me
> to a second question: would you consider merging extensions to this
> script if they are not used by the kernel build system, but meant for
> users who manually invoke the script ? More generally, is the script

We'd also be interested in some customization, though in a different way.
We imagine having a rule file that says X compatible string should map
to A base DTB, plus B and C DTBO for the configuration section. The base
DTB would carry all common elements of some device, while the DTBOs
carry all the possible second source components, like different display
panels or MIPI cameras for instance. This could drastically reduce the
size of FIT images in ChromeOS by deduplicating all the common stuff.

> meant to be used stand-alone as well, in which case its command line
> arguments need to remain backward-compatible, or do you see it as being
> internal to the kernel ?

[...]

ChenYu

Re: [PATCH] sunxi: psci: remove redundant initialization from psci_arch_init

[Chen-Yu Tsai]

On Tue, Aug 29, 2023 at 5:49 AM Sam Edwards  wrote:
>
> On 8/26/23 04:22, Marc Zyngier wrote:
>
> Hi Marc!
>
> > The GIC definitely has the NS bit routed to it. Otherwise, the secure
> > configuration would just be an utter joke. Just try it.
>
> Thank you for your response. I'd like to revisit my prior point about
> the distinction between the NS bit and AxPROT[1] bits in the context of
> monitor mode: in monitor mode, the NS bit does not determine the
> security state of the CPU core (monitor mode is always secure). But even
> then, the NS bit is still significant for other purposes, such as to
> bank accesses to certain CP15 registers -- and if I understand Chen-Yu
> correctly, some GIC registers also. That would require a special NS bit
> signal routed to the GIC so that it can distinguish between "secure,
> NS=0" and "secure, NS=1" accesses, which is why I asked if such a thing
> exists.
>
> I understand that the GIC is designed to be aware of the security state
> (using the existing AxPROT[1] signals) so that it can protect the
> sensitive registers. And unless I misunderstand, this seems to be the
> point that you made here (my interpretation -- correct me if I'm wrong
> -- is that you are using "NS bit" as a metonym for "security state").
> However I must clarify that my question was to seek further information
> from Chen-Yu about the possibility that NS is significant when accessing
> the GIC, even in monitor mode. Alternatively, his point might be merely
> highlighting that the GIC permits different types of access depending on
> the CPU's security state, which aligns with the viewpoint you've reiterated.
>
> I apologize if my previous message didn't convey this context clearly
> enough. My goal was to unravel this nuanced aspect of the NS bit when in
> monitor mode, and to determine if NS needs to be getting set/cleared
> during GIC setup to maneuver around the banking, or if the value of the
> NS bit when in psci_arch_init() is truly of no consequence due to
> monitor mode.

Sorry for my previous misleading comment. The banked registers refer to
the CP15 registers. From ARM's documentation [1]:

When the processor is in Monitor mode, the processor is in Secure state
regardless of the value of the SCR.NS bit. In Monitor mode, the SCR.NS
bit determines whether the Secure Banked CP15 registers or Non-secure
Banked CP15 registers are read or written using MRC or MCR instructions.

[1] 
https://developer.arm.com/documentation/ddi0406/b/System-Level-Architecture/Virtual-Memory-System-Architecture--VMSA-/CP15-registers-for-a-VMSA-implementation/Effect-of-the-Security-Extensions-on-the-CP15-registers?lang=en#Cbbdffad

> > Well, history is unfortunately against you on that front. Running on
> > the secure side definitely was a requirement when this code was
> > initially written, as the AW BSP *required* to run on the secure side.
> >
> > If that requirement is no more, great. But I don't think you can
> > decide that unilaterally.
>
> I have no idea when/if this requirement was changed. It might have never
> happened "formally": perhaps at some point, the SCR.NS=1 code got added
> after the call to psci_arch_init(), breaking (that version of) the AW
> BSP, and nobody ever complained or changed it back... so it stayed.

There was never any BSP code for PSCI before this. This code was written
by Marc in ARM assembly. I merely translated most of it to C code.
The snippet to clear SCR.NS is there in the first commit,

d5db7024aafc sunxi: HYP/non-sec: add sun7i PSCI backend

ChenYu

> But we're starting to digress from what _this_ patch does. The intent
> here is only to remove two lines of code that (we're discussing to
> confirm) have no effect. I'm not touching the code that *actually*
> determines the world into which monitor mode exits.
>
> Cheers,
> Sam

Re: [PATCH] sunxi: psci: remove redundant initialization from psci_arch_init

[Chen-Yu Tsai]

(resent from kernel.org address)

On Tue, Aug 29, 2023 at 5:49 AM Sam Edwards  wrote:
>
> On 8/26/23 04:22, Marc Zyngier wrote:
>
> Hi Marc!
>
> > The GIC definitely has the NS bit routed to it. Otherwise, the secure
> > configuration would just be an utter joke. Just try it.
>
> Thank you for your response. I'd like to revisit my prior point about
> the distinction between the NS bit and AxPROT[1] bits in the context of
> monitor mode: in monitor mode, the NS bit does not determine the
> security state of the CPU core (monitor mode is always secure). But even
> then, the NS bit is still significant for other purposes, such as to
> bank accesses to certain CP15 registers -- and if I understand Chen-Yu
> correctly, some GIC registers also. That would require a special NS bit
> signal routed to the GIC so that it can distinguish between "secure,
> NS=0" and "secure, NS=1" accesses, which is why I asked if such a thing
> exists.
>
> I understand that the GIC is designed to be aware of the security state
> (using the existing AxPROT[1] signals) so that it can protect the
> sensitive registers. And unless I misunderstand, this seems to be the
> point that you made here (my interpretation -- correct me if I'm wrong
> -- is that you are using "NS bit" as a metonym for "security state").
> However I must clarify that my question was to seek further information
> from Chen-Yu about the possibility that NS is significant when accessing
> the GIC, even in monitor mode. Alternatively, his point might be merely
> highlighting that the GIC permits different types of access depending on
> the CPU's security state, which aligns with the viewpoint you've reiterated.
>
> I apologize if my previous message didn't convey this context clearly
> enough. My goal was to unravel this nuanced aspect of the NS bit when in
> monitor mode, and to determine if NS needs to be getting set/cleared
> during GIC setup to maneuver around the banking, or if the value of the
> NS bit when in psci_arch_init() is truly of no consequence due to
> monitor mode.

Sorry for my previous misleading comment. The banked registers refer to
the CP15 registers. From ARM's documentation [1]:

When the processor is in Monitor mode, the processor is in Secure state
regardless of the value of the SCR.NS bit. In Monitor mode, the SCR.NS
bit determines whether the Secure Banked CP15 registers or Non-secure
Banked CP15 registers are read or written using MRC or MCR instructions.

[1] 
https://developer.arm.com/documentation/ddi0406/b/System-Level-Architecture/Virtual-Memory-System-Architecture--VMSA-/CP15-registers-for-a-VMSA-implementation/Effect-of-the-Security-Extensions-on-the-CP15-registers?lang=en#Cbbdffad

> > Well, history is unfortunately against you on that front. Running on
> > the secure side definitely was a requirement when this code was
> > initially written, as the AW BSP *required* to run on the secure side.
> >
> > If that requirement is no more, great. But I don't think you can
> > decide that unilaterally.
>
> I have no idea when/if this requirement was changed. It might have never
> happened "formally": perhaps at some point, the SCR.NS=1 code got added
> after the call to psci_arch_init(), breaking (that version of) the AW
> BSP, and nobody ever complained or changed it back... so it stayed.

There was never any BSP code for PSCI before this. This code was written
by Marc in ARM assembly. I merely translated most of it to C code.
The snippet to clear SCR.NS is there in the first commit,

d5db7024aafc sunxi: HYP/non-sec: add sun7i PSCI backend

ChenYu

> But we're starting to digress from what _this_ patch does. The intent
> here is only to remove two lines of code that (we're discussing to
> confirm) have no effect. I'm not touching the code that *actually*
> determines the world into which monitor mode exits.
>
> Cheers,
> Sam

Re: [PATCH] sunxi: psci: remove redundant initialization from psci_arch_init

[Chen-Yu Tsai]

On Tue, Aug 15, 2023 at 4:40 AM Andre Przywara  wrote:
>
> On Wed, 31 May 2023 14:15:20 -0600
> Sam Edwards  wrote:
>
> Hi,
>
> (CC:ing Marc and Chen-Yu as the original authors)
>
> sorry for the delay, found that mouldering in my Drafts folder.
>
> > The nonsec code overrides/handles these:
> > - Setting PMR to 0xFF happens earlier, in _nonsec_init, so this is
> >   redundant.
> > - The NS bit is not yet set: it gets set later in _secure_monitor.
> >   Trying to clear it here is pointless and misleading.
>
> So superficially this looks alright, but I am still somewhat reluctant
> to apply this, see below ...
>
> > Signed-off-by: Sam Edwards 
> > ---
> >  arch/arm/cpu/armv7/sunxi/psci.c | 4 
> >  1 file changed, 4 deletions(-)
> >
> > diff --git a/arch/arm/cpu/armv7/sunxi/psci.c 
> > b/arch/arm/cpu/armv7/sunxi/psci.c
> > index e1d3638b5c..f866025c37 100644
> > --- a/arch/arm/cpu/armv7/sunxi/psci.c
> > +++ b/arch/arm/cpu/armv7/sunxi/psci.c
> > @@ -300,14 +300,10 @@ void __secure psci_arch_init(void)
> >   /* Set SGI15 priority to 0 */
> >   writeb(0, GICD_BASE + GICD_IPRIORITYRn + 15);
> >
> > - /* Be cool with non-secure */
> > - writel(0xff, GICC_BASE + GICC_PMR);
> > -
> >   /* Switch FIQEn on */
> >   setbits_le32(GICC_BASE + GICC_CTLR, BIT(3));
> >
> >   reg = cp15_read_scr();
> >   reg |= BIT(2);  /* Enable FIQ in monitor mode */
> > - reg &= ~BIT(0); /* Secure mode */
>
> I am scratching my head on this one: I see it deliberately being done in
> the original patch by Marc[1], and wonder why. If I read the code and
> the architecture correctly, this routine is called only(?) from the SMC
> handler, which means we are in monitor mode, that only exists in secure
> state. So the NS bit is irrelevant until we switch to another mode. And
> we indeed set the bit later, before dropping back to non-secure. So I
> agree that clearing the bit is pointless. Was it put in to be more
> robust, for other potential callers of this function, for instance in
> the boot path?

IIRC the GIC manual says that the secure bit is set or cleared to select
which bank of registers is accessed.

And I suppose it is here to be more robust.

ChenYu

> Does anyone remember?
>
> Cheers,
> Andre
>
> [1]
> https://source.denx.de/u-boot/u-boot/-/commit/d5db7024aafc5ea603f3a34f83bb29a1eaa3cbe7#f377950449a5dba076796d9e48fbd21f5d6ac545_0_65
>
> >   cp15_write_scr(reg);
> >  }
>

Re: [PATCH 10/11] rockchip: misc: Set eth1addr mac address

[Chen-Yu Tsai]

On Thu, Feb 16, 2023 at 7:57 AM Jonas Karlman  wrote:
>
> Set eth1addr when there is an ethernet1 alias in the fdt.

Maybe it makes sense to set it regardless whether an alias is present
or not?

The user might be loading a custom FDT for the kernel, or have DT
overlays stacked on, either could have the "ethernet1" alias while
the U-boot DT doesn't.

ChenYu

> Also allow fdt fixup of ethernet mac addresses when CMD_NET is disabled.
> Set ethaddr and eth1addr based on HASH and SHA256 options.
>
> Signed-off-by: Jonas Karlman 
> ---
>  arch/arm/mach-rockchip/misc.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-rockchip/misc.c b/arch/arm/mach-rockchip/misc.c
> index b350f18f1140..aceaea6b29b7 100644
> --- a/arch/arm/mach-rockchip/misc.c
> +++ b/arch/arm/mach-rockchip/misc.c
> @@ -21,9 +21,11 @@
>
>  #include 
>
> +DECLARE_GLOBAL_DATA_PTR;
> +
>  int rockchip_setup_macaddr(void)
>  {
> -#if IS_ENABLED(CONFIG_CMD_NET)
> +#if CONFIG_IS_ENABLED(HASH) && CONFIG_IS_ENABLED(SHA256)
> int ret;
> const char *cpuid = env_get("cpuid#");
> u8 hash[SHA256_SUM_LEN];
> @@ -52,6 +54,12 @@ int rockchip_setup_macaddr(void)
> mac_addr[0] &= 0xfe;  /* clear multicast bit */
> mac_addr[0] |= 0x02;  /* set local assignment bit (IEEE802) */
> eth_env_set_enetaddr("ethaddr", mac_addr);
> +
> +   if (gd->fdt_blob && fdt_get_alias(gd->fdt_blob, "ethernet1")) {
> +   /* Make a valid MAC address for eth1 */
> +   mac_addr[5] += 0x20;
> +   eth_env_set_enetaddr("eth1addr", mac_addr);
> +   }
>  #endif
> return 0;
>  }
> --
> 2.39.1
>

Re: [PATCH] rockchip: rk3399: add ethaddr and serial# init, enable for R4S

[Chen-Yu Tsai]

On Tue, Sep 27, 2022 at 5:27 AM Christian Kohlschütter
 wrote:
>
> > On 26. Sep 2022, at 13:59, Chen-Yu Tsai  wrote:
> >
> > On Mon, Sep 26, 2022 at 7:53 PM Christian Kohlschütter
> >  wrote:
> >>
> >> Some RK3399 boards, such as newer revisions of NanoPi R4S, do not
> >> provide an EEPROM chip containing a globally unique MAC address.
> >>
> >> Currently, this means that a randomly generated temporary MAC address
> >> may be generated each time the device is rebooted, leading to ARP cache
> >> issues and other confusing bugs.
> >>
> >> Since RK3399 CPUs provide a built-in unique serial number, we can
> >> reliably derive a locally MAC address from it by reading the
> >> corresponding bits from the non-secure efuse block.
> >>
> >> Port from uboot-rockchip 0c294d0, fix compilation issues and adjust
> >> coding style.
> >>
> >> rockchip: board: puma_rk3399: derive ethaddr from cpuid
> >> rockchip: board: puma_rk3399: add support for serial# and cpuid#
> >> rockchip: efuse: add (misc) driver for RK3399 non-secure efuse block
> >> via efuses
> >>
> >> Signed-off-by: Christian Kohlschütter 
> >> ---
> >> board/rockchip/evb_rk3399/evb-rk3399.c | 120 +
> >> configs/nanopi-r4s-rk3399_defconfig|   4 +
> >> drivers/misc/Makefile  |   2 +-
> >
> > There's already code in arch/arm/mach-rockchip/misc.c that does pretty much
> > the same thing.
> >
> > IIRC all you need to do is enable MISC_INIT_R and ROCKCHIP_EFUSE
> > or ROCKCHIP_OTP.
> >
> > ChenYu
>
> Oh cool, thanks ChenYu!
>
> Is there a reason to not enable these options by default (at least for the 
> R4S)?

Personally I think they could be enabled by default for all RK3399 boards.

> Following up with "[PATCH] rockchip: rk3399: add ethaddr and serial# init, 
> enable for R4S", which enables these settings in 
> configs/nanopi-r4s-rk3399_defconfig.

This doesn't look any different from what you already sent.

ChenYu

Re: [PATCH] rockchip: rk3399: add ethaddr and serial# init, enable for R4S

[Chen-Yu Tsai]

On Mon, Sep 26, 2022 at 7:53 PM Christian Kohlschütter
 wrote:
>
> Some RK3399 boards, such as newer revisions of NanoPi R4S, do not
> provide an EEPROM chip containing a globally unique MAC address.
>
> Currently, this means that a randomly generated temporary MAC address
> may be generated each time the device is rebooted, leading to ARP cache
> issues and other confusing bugs.
>
> Since RK3399 CPUs provide a built-in unique serial number, we can
> reliably derive a locally MAC address from it by reading the
> corresponding bits from the non-secure efuse block.
>
> Port from uboot-rockchip 0c294d0, fix compilation issues and adjust
> coding style.
>
> rockchip: board: puma_rk3399: derive ethaddr from cpuid
> rockchip: board: puma_rk3399: add support for serial# and cpuid#
> rockchip: efuse: add (misc) driver for RK3399 non-secure efuse block
> via efuses
>
> Signed-off-by: Christian Kohlschütter 
> ---
>  board/rockchip/evb_rk3399/evb-rk3399.c | 120 +
>  configs/nanopi-r4s-rk3399_defconfig|   4 +
>  drivers/misc/Makefile  |   2 +-

There's already code in arch/arm/mach-rockchip/misc.c that does pretty much
the same thing.

IIRC all you need to do is enable MISC_INIT_R and ROCKCHIP_EFUSE
or ROCKCHIP_OTP.

ChenYu

Re: [PATCH v2] sunxi: psci: Fix sunxi_power_switch on sun8i-r40 platform

[Chen-Yu Tsai]

Hi,

On Sat, May 14, 2022 at 11:19 AM  wrote:
>
> From: qianfan Zhao 
>
> linux system will die if we offline one of the cpu on R40 based board:
> eg: echo 0 > /sys/devices/system/cpu/cpu3/online
>
> Fixed sunxi_power_switch based on allwinner lichee 3.10 kernel driver.
>
> Signed-off-by: qianfan Zhao 

Please add a Fixes tag.

> ---
> v2 changes: Fix the commit message, the source code doesn't change.
>
>  arch/arm/cpu/armv7/sunxi/psci.c | 24 +++-
>  1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
> index 1ac50f558a..63186a9388 100644
> --- a/arch/arm/cpu/armv7/sunxi/psci.c
> +++ b/arch/arm/cpu/armv7/sunxi/psci.c
> @@ -79,8 +79,7 @@ static void __secure __mdelay(u32 ms)
>  static void __secure clamp_release(u32 __maybe_unused *clamp)
>  {
>  #if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN7I) || \
> -   defined(CONFIG_MACH_SUN8I_H3) || \
> -   defined(CONFIG_MACH_SUN8I_R40)
> +   defined(CONFIG_MACH_SUN8I_H3)
> u32 tmp = 0x1ff;
> do {
> tmp >>= 1;
> @@ -88,15 +87,30 @@ static void __secure clamp_release(u32 __maybe_unused 
> *clamp)
> } while (tmp);
>
> __mdelay(10);
> +#elif defined(CONFIG_MACH_SUN8I_R40)
> +   u8 i, tmp = 0xfe;
> +
> +   for (i = 0; i < 5; i++) { /* 0xfe, 0xf8, 0xe0, 0x80, 0x00 */
> +   writel(tmp, clamp);
> +   tmp <<= 2;
> +   }
> +
> +   while (0x00 != readl(clamp)) {
> +   ;
> +   }
>  #endif
>  }
>
>  static void __secure clamp_set(u32 __maybe_unused *clamp)
>  {
>  #if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN7I) || \
> -   defined(CONFIG_MACH_SUN8I_H3) || \
> -   defined(CONFIG_MACH_SUN8I_R40)
> +   defined(CONFIG_MACH_SUN8I_H3)
> writel(0xff, clamp);
> +#elif defined(CONFIG_MACH_SUN8I_R40)
> +   writel(0xff, clamp);
> +   while (0xff != readl(clamp)) {
> +   ;
> +   }
>  #endif
>  }
>
> @@ -153,7 +167,7 @@ static void __secure sunxi_cpu_set_power(int cpu, bool on)
>
> sunxi_power_switch((void *)cpucfg + SUN8I_R40_PWR_CLAMP(cpu),
>(void *)cpucfg + SUN8I_R40_PWROFF,
> -  on, 0);
> +  on, cpu);

I think this is the only change that is needed. Looking again at the
R40 user manual, the original code turned off core 0 regardless of
which core was being brought down.

Could you give that a try? The power clamp stuff shouldn't change
much, as the end result is the same. The readback might make a
difference, but if it does, it should be applied to all SoCs.


Regards
ChenYu

>  }
>  #else /* ! CONFIG_MACH_SUN7I && ! CONFIG_MACH_SUN8I_R40 */
>  static void __secure sunxi_cpu_set_power(int cpu, bool on)
> --
> 2.25.1
>

Re: [linux-sunxi] [PATCH] sunxi: H616: Enable full 4GB of DRAM

[Chen-Yu Tsai]

Hi,

On Thu, Apr 29, 2021 at 6:53 AM Andre Przywara  wrote:
>
> The H616 is our first supported Allwinner SoC which goes beyond the 4GB
> address space "barrier", by having more than 32 address bits.

Nit: I wouldn't say it's the first. The A80 supports up to 8GB address
space with LPAE. It just never shipped with more than 2GB DRAM.


ChenYu

Re: arm64: rk3399: Add support nanopi r4s

[Chen-Yu Tsai]

Hi,

On Mon, Feb 8, 2021 at 9:46 AM alex tian  wrote:
>
> From 01598339be9dbeec6ba41c470b29af1c53e29c40 Mon Sep 17 00:00:00 2001
> From: Xiaobo Tian 
> Date: Mon, 8 Feb 2021 09:40:03 +0800
> Subject: [PATCH] arm64: rk3399: Add support NanoPi R4s

Please tag patches with versions or "resent" if no changes were made.

Also, your patch is pretty messed up, especially on patchwork. For example,
the indents are all wrong. On patchwork, parts of the diff even end up
out of order or in the header.

Please do not copy-paste your patch from a terminal window or editor into
your mail client. Instead, use `git send-email` to send patches.

ChenYu

Re: arm64: rk3399: Add support NanoPi R4s

[Chen-Yu Tsai]

Hi,

On Mon, Feb 1, 2021 at 9:58 AM Kever Yang  wrote:
>
> Hi Xiaobo,
>
>
>  Thanks for your update, see comments in line.
>
> On 2021/1/29 下午10:34, alex tian wrote:
> > From c9563fe439e07e760d29a42e737b8265d5772150 Mon Sep 17 00:00:00 2001
> > From: Xiaobo Tian mailto:peterwil...@gmail.com>>
> > Date: Fri, 29 Jan 2021 22:30:22 +0800
> > Subject: [PATCH] arm64: rk3399: Add support NanoPi R4s
>
> You need to update the patch version, this is at lease version 4, and
> please add change log
>
> for what have been update in new version, these can be found in the link
> I share with you in previous review.
>
> >
> > NanoPi R4s [1] is SBC base on Rockchip RK3399 hexa-core processor with
> > dual-Core Cortex-A72 and Mali-T864 GPU with 4GiB(LPDDR4) of RAM, SD
> > card support,
> > including 2 gigabit ethernet(RTL8211E 1Gbps - RTL8111H 1Gbps) and 2
> > USB 3.0 port.
> > port.It also has two GPIO headers which allows further peripherals to
> > be used.
> >
> > The devicetree file is taken of the rk3399 nanopi4 Linux kernel [2].
> we need a commit number in mainline kernel instead of file link.
> >
> > [1] https://wiki.friendlyarm.com/wiki/index.php/NanoPi_R4S
> This product is no need in the commit message.
> > [2]
> > https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi
> >
> > Cc: Tom Rini mailto:tr...@konsulko.com>>
> > Cc: Kever Yang  > >
> > Reviewed-by: Kever Yang  > >
>
>
> Please don't add my review tag before I reply it to the list with
> "Reviewed-by..." message.
>
> One more thing is that please make sure this patch can pass the
> checkpatch script, 10 warnings for this patch now,
>
> and you will need to add MAINTAINERS info for this board at
> board/rockchip/evb_rk3399/MAINTAINERS if you
>
> want to follow evb with everything other than dts, or else you will need
> to add a board at board/friendlyarm/.
>
>
> Thanks,
>
> - Kever
>
> > Signed-off-by: Xiaobo Tian  > >
> > ---
> >  arch/arm/dts/Makefile  |   1 +
> >  arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi |   7 ++
> >  arch/arm/dts/rk3399-nanopi-r4s.dts | 129 +
> >  configs/nanopi-r4s-rk3399_defconfig|  62 ++
> >  4 files changed, 199 insertions(+)
> >  create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/rk3399-nanopi-r4s.dts
> >  create mode 100644 configs/nanopi-r4s-rk3399_defconfig
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 858b79ac97..528dfe069e 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -92,6 +92,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
> >   rk3288-evb.dtb \
> >   rk3288-firefly.dtb \
> >   rk3288-miqi.dtb \
> > + rk3399-nanopi-r4s.dtb \
> >   rk3288-phycore-rdk.dtb \
> >   rk3288-popmetal.dtb \
> >   rk3288-rock2-square.dtb \
> > diff --git a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> > b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> > new file mode 100644
> > index 00..df193f0e64
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
> > @@ -0,0 +1,7 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2020 Xiaobo  > >
> > + */
> > +
> > +#include "rk3399-nanopi4-u-boot.dtsi"
> > +#include "rk3399-sdram-lpddr4-100.dtsi"

Because of this ...

> > diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts
> > b/arch/arm/dts/rk3399-nanopi-r4s.dts
> > new file mode 100644
> > index 00..36d55fed39
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
> > @@ -0,0 +1,129 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright (c) 2020 FriendlyElec Computer Tech. Co., Ltd.
> > + * (http://www.friendlyarm.com)
> > + *
> > + * Copyright (C) 2020 Xiaobo  > >
> > + */
> > +
> > +/dts-v1/;
> > +#include "rk3399-nanopi4.dtsi"
> > +
> > +/ {
> > + model = "FriendlyElec NanoPi R4S";
> > + compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
> > +
> > +  cpuinfo {
> > +  compatible = "rockchip,cpuinfo";
> > +  nvmem-cells = <_id>;
> > +  nvmem-cell-names = "id";
> > +  };
> > +
> > +  aliases {
> > +  ethernet1 = 
> > +  };
> > +
> > + vdd_5v: vdd-5v {
> > + compatible = "regulator-fixed";
> > + regulator-name = "vdd_5v";
> > + regulator-always-on;
> > + regulator-boot-on;
> > + };
> > +
> > + fan: pwm-fan {
> > + compatible = "pwm-fan";
> > + cooling-levels = <0 12 18 255>;
> > + #cooling-cells = <2>;
> > + fan-supply = <_5v>;
> > + pwms = < 0 5 0>;
> > + };
> > +};
> > +
> > +_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 {
> > + 

Re: [PATCH 1/3] sunxi: dts: OrangePi Zero: Add SPI aliases to make bus usable with u-boot.

[Chen-Yu Tsai]

(Resend from @kernel.org address)

On Tue, Sep 29, 2020 at 5:02 AM Michal Suchanek  wrote:
>
> The u-boot code relies on aliases to assign bus number.
>
> Signed-off-by: Michal Suchanek 
> ---
>  arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts | 2 ++

Anything U-boot specific should be done in the *-u-boot.dts file.
And any changes you do to the U-boot copy of dts files will potentially
be lost when a dts sync happens.

ChenYu

>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts 
> b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> index f19ed981da..090570148e 100644
> --- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> +++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> @@ -59,6 +59,8 @@
> /* ethernet0 is the H3 emac, defined in sun8i-h3.dtsi */
> ethernet0 = 
> ethernet1 = 
> +   spi0 = 
> +   spi1 = 
> };
>
> chosen {
> --
> 2.28.0
>

Re: [PATCH 0/5] Enable I2C in SPL, support runtime detection of add-on board

[Chen-Yu Tsai]

Hi,

On Sat, May 23, 2020 at 2:04 AM  wrote:
>
> From: Suniel Mahesh 
>
> This patch series adds runtime detection of add-on board(ROC-RK3399-PC 
> Mezzanine) by
> enabling I2C in SPL.
> This add on board hosts a CW2015 chip which is connected as slave to I2C2. In 
> order
> to dynamically detect this add-on board at runtime, I2C2 is probed in SPL. If 
> probe
> is successfull then a corresponding dtb is loaded, else regular dtb is loaded 
> for
> the u-boot proper.
>
> Patch #1 moves board initialiation code after rk3399 init is done. Patch #2 
> enables
> I2C in SPL for any add-on board detection at run time. Patch #3 adds support 
> for
> add-on board run-time detection. Patch #4 drops ROC-RK3399-PC Mezzanine board 
> as this
> is an add-on board, it will be detected at runtime. Patch #5 enables PCIe/M.2 
> and NVMe,
> as this add-on board has a PCIe/M.2.
>
> Jagan Teki (1):
>   rockchip: spl: Move board_early_init_f after cpu timer
>
> Suniel Mahesh (4):
>   roc-pc-rk3399: Enable I2C in SPL for add-on board detection
>   roc-pc-rk3399: Add support for add-on board run-time detection
>   rk3399: drop ROC-RK3399-PC Mezzanine board
>   roc-pc-rk3399: Enable PCIe/M.2, NVMe
>
>  arch/arm/dts/rk3399-roc-pc-u-boot.dtsi  | 13 +
>  arch/arm/mach-rockchip/spl.c|  5 +-
>  board/firefly/roc-pc-rk3399/MAINTAINERS |  2 -
>  board/firefly/roc-pc-rk3399/roc-pc-rk3399.c | 56 ++
>  configs/roc-pc-mezzanine-rk3399_defconfig   | 74 
> -


FYI this is going to be problematic for people that have the non-POE
version of the
mezzanine board and still want to access NVMe from U-boot. Maybe worth keeping a
target for these people to use.

ChenYu

>  configs/roc-pc-rk3399_defconfig | 10 +++-
>  6 files changed, 81 insertions(+), 79 deletions(-)
>  delete mode 100644 configs/roc-pc-mezzanine-rk3399_defconfig
>
> --
> 2.7.4
>

Re: [PATCH] rockchip: rk3328: rock64 - fix gen3 SPL hang

[Chen-Yu Tsai]

On Wed, May 20, 2020 at 4:05 PM Matwey V. Kornilov
 wrote:
>
> вт, 19 мая 2020 г. в 17:30, Kurt Miller :
> >
> > On Tue, 2020-05-19 at 12:48 +0300, Matwey V. Kornilov wrote:
> > > вт, 19 мая 2020 г. в 01:06, Kurt Miller :
> > > >
> > > >
> > > > On Wed, 2020-05-13 at 16:10 -0400, Kurt Miller wrote:
> > > > >
> > > > > On Wed, 2020-05-13 at 22:58 +0300, Matwey V. Kornilov wrote:
> > > > > >
> > > > > >
> > > > > > Thanks. Have you already checked it on gen2? I think I have gen2 
> > > > > > board to test.
> > > > > Yes, I have both gen3 and gen2 boards. gen2 continues to work
> > > > > with this patch as well.
> > > > Hi Matwey,
> > > Hi Kurt,
> > >
> > > Sorry for the late reply. I've just managed to apply you patch on top
> > > of ed9a3aa645 and it didn't work for me on 2GB v2.0 rock64 board.
> > >
> > > U-Boot TPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 12:44:16)
> > > LPDDR3, 800MHz
> > > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> > > Trying to boot from BOOTROM
> > > Returning to boot ROM...
> > >
> > > U-Boot SPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 12:44:16 
> > > +0300)
> > > Trying to boot from MMC1
> > > [and nothing else happens here]
> > >
> > > What do you think may be the reason?
> >
> > Hi Matwey,
> >
>
> Hi Kurt,
>
> > Thank you for testing the patch. Hmm, are you building with ATF 2.3?
>
> You are right here, I was testing with ATF 2.1, while ATF 2.3 works correctly.
> First working commit in ATF is 0aad563c ("rockchip: Update BL31_BASE
> to 0x4").
> I suppose, it is worth to mention in the commit message for this
> patch. What do you think?

This was already mentioned in commits such as

c0a474b9d9a1 rockchip: evb-rk3328: Enable support ATF in SPL
4690ef8907e9 rockchip: rk3288-evb: update SPL_STACK/MALLOC_LEN config
with rk3399
6024467bcc0e rockchip: config: update CONFIG_SPL_MAX_SIZE for 64bit CPUs
006ab58d4636 rockchip: rk3399: update SPL_STACK_R_ADDR

ChenYu

>
> >
> > I’m booting from the uSD without an eMMC installed. Are you booting
> > from the eMMC or have one installed?
>
> I'm booting from uSD without eMMC installed also.
>
>
> >
> > Here are some background emails related to the gen3 freeze. I also
> > included the output for when gen3 fails below and the output for
> > my gen2 2gb and gen3 4gb with the patch.
> >
> > https://marc.info/?l=u-boot=158550521101881=2
> > https://marc.info/?l=u-boot=156427088018689=2
> >
> > Gen2 2GB with patch:
> >
> > U-Boot TPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 09:52:15)
> > LPDDR3, 800MHz
> > BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
> > Trying to boot from BOOTROM
> > Returning to boot ROM...
> >
> > U-Boot SPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 09:52:15 
> > -0400)
> > Trying to boot from MMC1
> > NOTICE:  BL31: v2.3():2.3
> > NOTICE:  BL31: Built : 11:30:57, May 15 2020
> > NOTICE:  BL31:Rockchip release version: v1.2
> > INFO:ARM GICv2 driver initialized
> > INFO:plat_rockchip_pmu_init: pd status 0xe
> > INFO:BL31: Initializing runtime services
> > INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
> > INFO:BL31: Preparing for EL3 exit to normal world
> > INFO:Entry point address = 0x20
> > INFO:SPSR = 0x3c9
> >
> >
> > U-Boot 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 09:52:15 -0400)
> >
> > Model: Pine64 Rock64
> > DRAM:  2 GiB
> > PMIC:  RK8050 (on=0x40, off=0x01)
> > MMC:   mmc@ff50: 1, mmc@ff52: 0
> > Loading Environment from MMC... *** Warning - bad CRC, using default 
> > environment
> >
> > In:serial@ff13
> > Out:   serial@ff13
> > Err:   serial@ff13
> > Model: Pine64 Rock64
> > Net:   eth0: ethernet@ff54
> > Hit any key to stop autoboot:  0
> > Card did not respond to voltage select!
> > switch to partitions #0, OK
> > mmc1 is current device
> > Scanning mmc 1:1...
> > Found EFI removable media binary efi/boot/bootaa64.efi
> > libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> > Scanning disk m...@ff50.blk...
> > ** Unrecognized filesystem type **
> > Card did not respond to voltage select!
> > Scanning disk m...@ff52.blk...
> > Disk m...@ff52.blk not ready
> > Found 3 disks
> > BootOrder not defined
> > EFI boot manager: Cannot load any image
> > 169176 bytes read in 15 ms (10.8 MiB/s)
> > libfdt fdt_check_header(): FDT_ERR_BADMAGIC
> > disks: sd0*
> >
> > Gen3 4GB with patch:
> >
> > U-Boot TPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 09:52:15)
> > LPDDR3, 800MHz
> > BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB
> > Trying to boot from BOOTROM
> > Returning to boot ROM...
> >
> > U-Boot SPL 2020.07-rc2-00133-ged9a3aa645-dirty (May 19 2020 - 09:52:15 
> > -0400)
> > Trying to boot from MMC1
> > NOTICE:  BL31: v2.3():2.3
> > NOTICE:  BL31: Built : 11:30:57, May 15 2020
> > NOTICE:  BL31:Rockchip release version: v1.2
> > INFO:ARM GICv2 driver initialized
> > INFO:plat_rockchip_pmu_init: pd status 0xe

Re: [PATCH v3 7/9] rockchip: dts: rk3328: Sync device tree files from Linux

[Chen-Yu Tsai]

Hi Kurt

On Tue, May 12, 2020 at 3:00 AM Kurt Miller  wrote:
>
> On Mon, 2020-04-27 at 14:52 +0800, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai 
> >
> > This syncs rk3328 device tree files from the Linux kernel next-20200324.
> > The last commit to touch these files is:
> >
> > b2411befed60 ("arm64: dts: add bus to rockchip amba nodenames")
> >
> > Additional changes not yet in the Linux kernel include:
> >
> > arm64: dts: rockchip: rk3328: drop #address-cells, #size-cells from grf 
> > node
> > arm64: dts: rockchip: rk3328: drop non-existent gmac2phy pinmux options
> > arm64: dts: rockchip: rk3328: Replace RK805 PMIC node name with "pmic"
> >
> > Changes include:
> >
> >   - conversion of raw pin numbers to macros
> >   - removal of deprecated RK_FUNC_* macros
> >   - update of device tree binding headers
> >   - new devices
> >   - device tree cleanups
> >   - gmac2phy disabled in -u-boot.dtsi as it is not supported in U-boot
> >
> > This includes a re-ordering of the USB device nodes compared to upstream
> > Linux, moving the dwc2 OTG controller after the EHCI/OHCI nodes. This is
> > currently required as otherwise the dwc2 controller would not be able to
> > detect devices in some cases. This may be due to lack of USB PHY support
> > in U-boot.
>
> Hi Chen-Yu,
>
> Thank you for syncing rk3328 device tree files. On the rock64 with
> v2020.04 one USB 2.0 port was working (the lower one). Building
> master now with this merged, no USB ports are working. No power
> appears to be enabled on them and USB devices are not recognized.

When I was working on v3, it was based on

d202f67db077 Merge branch '2020-04-25-master-imports'

And it was definitely working. My Rock64 is back in its case, so I tested
again with the ROC-RK3328-CC just now. All three USB ports work properly,
on both the old tree and current master.

Are you using the defconfig, or have you deviated from it? XHCI must be
enabled, as VBUS is tied to it (to get everything to work).

ChenYu

> Do you have any suggestions for me to try to get them enabled again?
>
> Thanks,
> -Kurt

Re: [PATCH v3 8/9] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

On Thu, Apr 30, 2020 at 5:08 PM Kever Yang  wrote:
>
>
> On 2020/4/27 下午2:52, Chen-Yu Tsai wrote:
> > --- a/board/rockchip/evb_rk3328/MAINTAINERS
> > +++ b/board/rockchip/evb_rk3328/MAINTAINERS
> > @@ -5,6 +5,13 @@ F:  board/rockchip/evb_rk3328
> >   F:  include/configs/evb_rk3328.h
> >   F:  configs/evb-rk3328_defconfig
> >
> > +ROC-RK3328-CC
> > +M:  Loic Devulder
> > +M:  Chen-Yu Tsai
> > +S:  Maintained
> > +F:  configs/roc-rk3328-cc_defconfig
>
> This need to be roc-cc-rk3328_defconfig, or else there will be warning:
>
> WARNING: no status info for 'roc-cc-rk3328'
> WARNING: no maintainers for 'roc-cc-rk3328'
>
> I will update it before merge.

Sorry about that, and thanks for fixing it up.

ChenYu

> Thanks,
>
> - Kever
>
> > +F:  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> > +
>
>

[PATCH v3 8/9] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
card size development board based on the Rockchip RK3328 SoC, with:

  - 1/2/4 GB DDR4 DRAM
  - eMMC connector for optional module
  - micro SD card slot
  - 1 x USB 3.0 host port
  - 2 x USB 2.0 host port
  - 1 x USB 2.0 OTG port
  - HDMI video output
  - TRRS connector with audio and composite video output
  - gigabit Ethernet
  - consumer IR receiver
  - debug UART pins

The ROC-RK3328-CC has the enable pin of the SD card power switch tied
to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
muxed by default. SDMMC0_PWREN is an active high signal controlled by
the MMC controller, however the switch enable is active low, and
pulled low (enabled) by default to make things work on boot.

As such, we need to mux away from SDMMC0_PWREN and use GPIO to enable
power to the card. The default GPIO state for the pin is pull-down and
input, which doesn't require extra configuration when paired with the
external pull-down and active low switch.

Deal with this by enabling regulator support in SPL, and setting
"u-boot,dm-spl" for the regulator and other device nodes needed for
muxing the pin.

The device tree file is synced from the Linux kernel next-20200324.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - Remove regulator-always-on from VBUS regulator
  - Disable CONFIG_PHY
Changes since v1:
  - Drop custom target; use pinctrl and regulators in SPL
---
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi |  47 
 arch/arm/dts/rk3328-roc-cc.dts | 354 +
 board/rockchip/evb_rk3328/MAINTAINERS  |   7 +
 configs/roc-cc-rk3328_defconfig| 102 +++
 doc/README.rockchip|   4 +-
 6 files changed, 514 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3328-roc-cc.dts
 create mode 100644 configs/roc-cc-rk3328_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index af7d804b6669..a683525e7c6a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -106,6 +106,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3308) += \
 
 dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-evb.dtb \
+   rk3328-roc-cc.dtb \
rk3328-rock64.dtb
 
 dtb-$(CONFIG_ROCKCHIP_RK3368) += \
diff --git a/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi 
b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
new file mode 100644
index ..e929d86e306a
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
@@ -0,0 +1,47 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2018-2019 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-ddr4-666.dtsi"
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_gpio {
+   u-boot,dm-spl;
+};
+
+_pull_up_4ma {
+   u-boot,dm-spl;
+};
+
+_host0_xhci {
+   vbus-supply = <_host1_5v>;
+   status = "okay";
+};
+
+/*
+ * This makes XHCI responsible for toggling VBUS. This is needed to work
+ * around an issue where either XHCI only works with USB 2.0 or OTG doesn't
+ * work, depending on how VBUS is configured. Having USB 3.0 seems better.
+ */
+_host1_5v {
+   /delete-property/ regulator-always-on;
+};
+
+/* Need this and all the pinctrl/gpio stuff above to set pinmux */
+_sd {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/rk3328-roc-cc.dts b/arch/arm/dts/rk3328-roc-cc.dts
new file mode 100644
index ..8d553c92182a
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc.dts
@@ -0,0 +1,354 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 T-Chip Intelligent Technology Co., Ltd
+ */
+
+/dts-v1/;
+#include "rk3328.dtsi"
+
+/ {
+   model = "Firefly roc-rk3328-cc";
+   compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
+   dc_12v: dc-12v {
+   compatible = "regulator-fixed";
+   regulator-name = "dc_12v";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+  

[PATCH v3 7/9] rockchip: dts: rk3328: Sync device tree files from Linux

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs rk3328 device tree files from the Linux kernel next-20200324.
The last commit to touch these files is:

b2411befed60 ("arm64: dts: add bus to rockchip amba nodenames")

Additional changes not yet in the Linux kernel include:

arm64: dts: rockchip: rk3328: drop #address-cells, #size-cells from grf node
arm64: dts: rockchip: rk3328: drop non-existent gmac2phy pinmux options
arm64: dts: rockchip: rk3328: Replace RK805 PMIC node name with "pmic"

Changes include:

  - conversion of raw pin numbers to macros
  - removal of deprecated RK_FUNC_* macros
  - update of device tree binding headers
  - new devices
  - device tree cleanups
  - gmac2phy disabled in -u-boot.dtsi as it is not supported in U-boot

This includes a re-ordering of the USB device nodes compared to upstream
Linux, moving the dwc2 OTG controller after the EHCI/OHCI nodes. This is
currently required as otherwise the dwc2 controller would not be able to
detect devices in some cases. This may be due to lack of USB PHY support
in U-boot.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - Dropped reviewed-by
  - Moved dwc2 OTG device node after EHCI/OHCI to make dwc2 work again
Changes since v1:
  - Added Kever's reviewed-by
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi |5 +
 arch/arm/dts/rk3328-evb.dts |  196 ++--
 arch/arm/dts/rk3328-rock64.dts  |  132 ++-
 arch/arm/dts/rk3328.dtsi| 1414 +--
 4 files changed, 1166 insertions(+), 581 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 8ba53cf8f44b..4bfa0c2330ba 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -40,6 +40,11 @@
status = "okay";
 };
 
+ {
+   /* Integrated PHY unsupported by U-boot */
+   status = "broken";
+};
+
 _host0_xhci {
vbus-supply = <_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index 97bef37cf610..6abc6f4a86cf 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -1,6 +1,6 @@
-// SPDX-License-Identifier: GPL-2.0+
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 /*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
  */
 
 /dts-v1/;
@@ -11,24 +11,51 @@
compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
 
chosen {
-   stdout-path = 
+   stdout-path = "serial2:150n8";
};
 
-   vcc3v3_sdmmc: sdmmc-pwren {
+   dc_12v: dc-12v {
compatible = "regulator-fixed";
-   regulator-name = "vcc3v3";
-   gpio = < 30 GPIO_ACTIVE_LOW>;
+   regulator-name = "dc_12v";
regulator-always-on;
regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   pinctrl-names = "default";
+   pinctrl-0 = <_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 = < 18 GPIO_ACTIVE_LOW>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = < 30 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio>;
+   regulator-name = "vcc_sd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_io>;
};
 
-   vcc5v0_otg: vcc5v0-otg-drv {
+   vcc_sys: vcc-sys {
compatible = "regulator-fixed";
-   enable-active-high;
-   regulator-name = "vcc5v0_otg";
-   gpio = < 27 GPIO_ACTIVE_HIGH>;
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
+   vin-supply = <_12v>;
};
 
vcc_phy: vcc-phy-regulator {
@@ -39,80 +66,60 @@
};
 };
 
- {
-   status = "okay";
-};
-
- {
-   status = "okay";
-};
-
- {
-   bus-width = <4>;
-   cap-mmc-highspeed;
-   cap-sd-highspeed;
-   card-detect-delay = <200>;
-   

[PATCH v3 5/9] dt-bindings: power: rk3328-power: sync from upstream Linux kernel

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs the rk3328 power domain header file from Linux kernel
next-20200324, to support newer hardware blocks when syncing the
device tree files.

The last non-merge commit to touch it was

b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to 
files with no license")

Reviewed-by: Kever Yang 
Tested-by: Loic Devulder 
Tested-by: Peter Geis 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - none
Changes since v1:
  - Added Kever's reviewed-by
---
 include/dt-bindings/power/rk3328-power.h | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3328-power.h

diff --git a/include/dt-bindings/power/rk3328-power.h 
b/include/dt-bindings/power/rk3328-power.h
new file mode 100644
index ..02e3d7fc1cce
--- /dev/null
+++ b/include/dt-bindings/power/rk3328-power.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DT_BINDINGS_POWER_RK3328_POWER_H__
+#define __DT_BINDINGS_POWER_RK3328_POWER_H__
+
+/**
+ * RK3328 idle id Summary.
+ */
+#define RK3328_PD_CORE 0
+#define RK3328_PD_GPU  1
+#define RK3328_PD_BUS  2
+#define RK3328_PD_MSCH 3
+#define RK3328_PD_PERI 4
+#define RK3328_PD_VIDEO5
+#define RK3328_PD_HEVC 6
+#define RK3328_PD_SYS  7
+#define RK3328_PD_VPU  8
+#define RK3328_PD_VIO  9
+
+#endif
-- 
2.26.0

[PATCH v3 9/9] rockchip: dts: rock64: Fix XHCI usage

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

If the VBUS regulator is always-on, XHCI will fail to detect USB 3.0
devices; USB 2.0 devices will work however.

Make the VBUS regulator controllable and tie it to only the XHCI. This
makes all three USB ports usable.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - new patch
---
 arch/arm/dts/rk3328-rock64-u-boot.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi 
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index e5946d2d2dc7..8318bf4e6030 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -12,5 +12,16 @@
 };
 
 _host0_xhci {
+   vbus-supply = <_host_5v>;
status = "okay";
 };
+
+/*
+ * This makes XHCI responsible for toggling VBUS. This is needed to work
+ * around an issue where either XHCI only works with USB 2.0 or OTG doesn't
+ * work, depending on how VBUS is configured. Having USB 3.0 seems better.
+ */
+_host_5v {
+   /delete-property/ regulator-always-on;
+   /delete-property/ regulator-boot-on;
+};
-- 
2.26.0

[PATCH v3 0/9] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi everyone,

This is v3 of my ROC-RK3328-CC series. Changes from v2 are mainly
fixing USB functionality on RK3328 in U-boot. This includes restoring
the U-Boot specific "hnp-srp-disable" property for dwc2, moving the
dwc2 device node after the ehci/ohci ones, and making vbus controllable
and tied only to the XHCI controller. Because of this, I dropped review
and tested tags from the DTS sync and new board patches.

Changes from v1 are mainly dropping the custom board target, and dealing
with the pinmuxing through proper use of DM regulators / GPIO / pinctrl
in SPL.

This series adds proper support for Firefly / Libre Computer ROC-RK3328-CC
single board computer.

The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
card size development board based on the Rockchip RK3328 SoC, with:

  - 1/2/4 GB DDR4 DRAM
  - eMMC connector for optional module
  - micro SD card slot
  - 1 x USB 3.0 host port
  - 2 x USB 2.0 host port
  - 1 x USB 2.0 OTG port
  - HDMI video output
  - TRRS connector with audio and composite video output
  - gigabit Ethernet
  - consumer IR receiver
  - debug UART pins

Originally I started with Loic's patches, and syncing the device tree
files from Linux. That didn't get very far, with SPL failing to detect
the SD card. Examining the schematics and internal state of GRF and
GPIOs, I realized that the logic for the SD card power enable switch
is opposite that of what the SD card controller's SDMMC0_PWREN pin
would use. Instead, directly using the GPIO is required.

To deal with this, DM regulator and GPIO are enabled in SPL, and
various device nodes are marked with u-boot,dm-spl to have them work.
pinctrl properties are not stripped, so as to have the SDMMC0_PWREN
pin muxed over to GPIO.

Along the way, there are some clean-ups of existing dts files, moving
U-boot only features to -u-boot.dtsi files, and then a wholesale sync
from Linux. Only boards already existing in U-boot are synced. DT
binding header files are synced separately as there is already one
patch floating around. The DT sync also includes clean-up changes only
recently posted, and likely won't make it in for at least a few weeks.

Please have a look, and test if possible. I cc-ed a couple people that
showed interest in this board on mailing lists recently.

Regards
ChenYu


Chen-Yu Tsai (9):
  rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi
  rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi
  rockchip: dts: rk3328: Move OTG node's hnp-srp-disable to
rk3328-u-boot.dtsi
  dt-bindings: clock: rk3328: sync from upstream Linux kernel
  dt-bindings: power: rk3328-power: sync from upstream Linux kernel
  rockchip: rk3328: Disable generic PHY support
  rockchip: dts: rk3328: Sync device tree files from Linux
  rockchip: rk3328: Add support for ROC-RK3328-CC board
  rockchip: dts: rock64: Fix XHCI usage

 arch/arm/dts/Makefile |1 +
 arch/arm/dts/rk3328-evb-u-boot.dtsi   |   39 +
 arch/arm/dts/rk3328-evb.dts   |  220 +--
 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi|   47 +
 .../{rk3328-rock64.dts => rk3328-roc-cc.dts}  |  135 +-
 arch/arm/dts/rk3328-rock64-u-boot.dtsi|   11 +
 arch/arm/dts/rk3328-rock64.dts|  132 +-
 arch/arm/dts/rk3328-u-boot.dtsi   |4 +
 arch/arm/dts/rk3328.dtsi  | 1415 +++--
 board/rockchip/evb_rk3328/MAINTAINERS |7 +
 configs/evb-rk3328_defconfig  |1 -
 ...3328_defconfig => roc-cc-rk3328_defconfig} |   19 +-
 configs/rock64-rk3328_defconfig   |1 -
 doc/README.rockchip   |4 +-
 include/dt-bindings/clock/rk3328-cru.h|  212 +--
 include/dt-bindings/power/rk3328-power.h  |   19 +
 16 files changed, 1514 insertions(+), 753 deletions(-)
 create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
 copy arch/arm/dts/{rk3328-rock64.dts => rk3328-roc-cc.dts} (68%)
 copy configs/{rock64-rk3328_defconfig => roc-cc-rk3328_defconfig} (81%)
 create mode 100644 include/dt-bindings/power/rk3328-power.h

-- 
2.26.0

[PATCH v3 6/9] rockchip: rk3328: Disable generic PHY support

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The USB PHYs on the RK3328 aren't supported, nor are any other generic
PHYs. Because upstream Linux device trees already include the USB PHYs
and references in the USB hosts, this would result in various calls
to the generic PHY API to fail.

Instead, just disable generic PHY support for now.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - New patch
---
 configs/evb-rk3328_defconfig| 1 -
 configs/rock64-rk3328_defconfig | 1 -
 2 files changed, 2 deletions(-)

diff --git a/configs/evb-rk3328_defconfig b/configs/evb-rk3328_defconfig
index 5bbdc002148c..7667bb037b3d 100644
--- a/configs/evb-rk3328_defconfig
+++ b/configs/evb-rk3328_defconfig
@@ -61,7 +61,6 @@ CONFIG_SF_DEFAULT_SPEED=2000
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PHY=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_DM_PMIC=y
diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig
index 826c7a691742..7d096d38c6d0 100644
--- a/configs/rock64-rk3328_defconfig
+++ b/configs/rock64-rk3328_defconfig
@@ -60,7 +60,6 @@ CONFIG_SF_DEFAULT_SPEED=2000
 CONFIG_DM_ETH=y
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_GMAC_ROCKCHIP=y
-CONFIG_PHY=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 CONFIG_DM_PMIC=y
-- 
2.26.0

[PATCH v3 4/9] dt-bindings: clock: rk3328: sync from upstream Linux kernel

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs the rk3328 clock header file from Linux kernel next-20200324,
to support newer hardware blocks when syncing the device tree files.

The last non-merge commit to touch it was

0dc14b013f79 ("clk: rockchip: add clock id for watchdog pclk on rk3328")

Reviewed-by: Kever Yang 
Tested-by: Loic Devulder 
Tested-by: Peter Geis 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - none
Changes since v1:
  - Added Kever's reviewed-by
---
 include/dt-bindings/clock/rk3328-cru.h | 212 -
 1 file changed, 106 insertions(+), 106 deletions(-)

diff --git a/include/dt-bindings/clock/rk3328-cru.h 
b/include/dt-bindings/clock/rk3328-cru.h
index cde61ed8830b..555b4ff660ae 100644
--- a/include/dt-bindings/clock/rk3328-cru.h
+++ b/include/dt-bindings/clock/rk3328-cru.h
@@ -1,6 +1,7 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
+/* SPDX-License-Identifier: GPL-2.0-or-later */
 /*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Elaine 
  */
 
 #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3328_H
@@ -90,119 +91,118 @@
 #define SCLK_MAC2IO_EXT102
 
 /* dclk gates */
-#define DCLK_LCDC  180
-#define DCLK_HDMIPHY   181
-#define HDMIPHY182
-#define USB480M183
-#define DCLK_LCDC_SRC  184
+#define DCLK_LCDC  120
+#define DCLK_HDMIPHY   121
+#define HDMIPHY122
+#define USB480M123
+#define DCLK_LCDC_SRC  124
 
 /* aclk gates */
-#define ACLK_AXISRAM   190
-#define ACLK_VOP_PRE   191
-#define ACLK_USB3OTG   192
-#define ACLK_RGA_PRE   193
-#define ACLK_DMAC  194
-#define ACLK_GPU   195
-#define ACLK_BUS_PRE   196
-#define ACLK_PERI_PRE  197
-#define ACLK_RKVDEC_PRE198
-#define ACLK_RKVDEC199
-#define ACLK_RKVENC200
-#define ACLK_VPU_PRE   201
-#define ACLK_VIO_PRE   202
-#define ACLK_VPU   203
-#define ACLK_VIO   204
-#define ACLK_VOP   205
-#define ACLK_GMAC  206
-#define ACLK_H265  207
-#define ACLK_H264  208
-#define ACLK_MAC2PHY   209
-#define ACLK_MAC2IO210
-#define ACLK_DCF   211
-#define ACLK_TSP   212
-#define ACLK_PERI  213
-#define ACLK_RGA   214
-#define ACLK_IEP   215
-#define ACLK_CIF   216
-#define ACLK_HDCP  217
+#define ACLK_AXISRAM   130
+#define ACLK_VOP_PRE   131
+#define ACLK_USB3OTG   132
+#define ACLK_RGA_PRE   133
+#define ACLK_DMAC  134
+#define ACLK_GPU   135
+#define ACLK_BUS_PRE   136
+#define ACLK_PERI_PRE  137
+#define ACLK_RKVDEC_PRE138
+#define ACLK_RKVDEC139
+#define ACLK_RKVENC140
+#define ACLK_VPU_PRE   141
+#define ACLK_VIO_PRE   142
+#define ACLK_VPU   143
+#define ACLK_VIO   144
+#define ACLK_VOP   145
+#define ACLK_GMAC  146
+#define ACLK_H265  147
+#define ACLK_H264  148
+#define ACLK_MAC2PHY   149
+#define ACLK_MAC2IO150
+#define ACLK_DCF   151
+#define ACLK_TSP   152
+#define ACLK_PERI  153
+#define ACLK_RGA   154
+#define ACLK_IEP   155
+#define ACLK_CIF   156
+#define ACLK_HDCP  157
 
 /* pclk gates */
-#define PCLK_GPIO0 300
-#define PCLK_GPIO1 301
-#define PCLK_GPIO2 302
-#define PCLK_GPIO3 303
-#define PCLK_GRF   304
-#define PCLK_I2C0  305
-#define PCLK_I2C1  306
-#define PCLK_I2C2  307
-#define PCLK_I2C3  308
-#define PCLK_SPI   309
-#define PCLK_UART0 310
-#define PCLK_UART1 311
-#define PCLK_UART2 312
-#define PCLK_TSADC 313
-#define PCLK_PWM   314
-#define PCLK_TIMER 315
-#define PCLK_BUS_PRE   316
-#define PCLK_PERI_PRE  317
-#define PCLK_HDMI_CTRL 318
-#define PCLK_HDMI_PHY  319
-#define PCLK_GMAC  320
-#define PCLK_H265  321
-#define PCLK_MAC2PHY   322
-#define PCLK_MAC2IO323
-#define PCLK_USB3PHY_OTG   324
-#define PCLK_USB3PHY_PIPE  325
-#define PCLK_USB3_GRF  326
-#define PCLK_USB2_GRF  327
-#define PCLK_HDMIPHY   328
-#define PCLK_DDR   329
-#define PCLK_PERI  330
-#define PCLK_HDMI  331
-#define PCLK_HDCP  332
-#define PCLK_DCF   333
-#define PCLK_SARADC334
+#define PCLK_GPIO0 200
+#define PCLK_GPIO1 20

[PATCH v3 1/9] rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

USB 3.0 is only supported in U-boot, not in the Linux kernel where the
device tree files are ultimately synced from. While the xhci node was
moved, the external vbus regulator was not.

Move it as well.

Fixes: 2e91e2025c1b ("rockchip: rk3328: migrate u-boot node to -u-boot.dtsi")
Reviewed-by: Kever Yang 
Tested-by: Loic Devulder 
Tested-by: Peter Geis 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - none
Changes since v1:
  - Added Kever's reviewed-by
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi | 11 +++
 arch/arm/dts/rk3328-evb.dts |  9 -
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 4a827063c555..5679897279aa 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -6,6 +6,17 @@
 #include "rk3328-u-boot.dtsi"
 #include "rk3328-sdram-ddr3-666.dtsi"
 
+/{
+   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = < 0 GPIO_ACTIVE_HIGH>;
+   regulator-name = "vcc5v0_host_xhci";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
 _host0_xhci {
vbus-supply = <_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index a2ee838fcd6b..e9bc849f8c23 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -38,15 +38,6 @@
regulator-max-microvolt = <500>;
};
 
-   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
-   compatible = "regulator-fixed";
-   enable-active-high;
-   regulator-name = "vcc5v0_host_xhci";
-   gpio = < 0 GPIO_ACTIVE_HIGH>;
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   };
-
vcc_phy: vcc-phy-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_phy";
-- 
2.26.0

[PATCH v3 2/9] rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The device tree file for rk3328-evb in the Linux kernel does not have
gmac2io enabled. Instead, gmac2phy is enabled, but that is not supported
in U-boot.

Move the gmac2io related nodes to rk3328-evb-u-boot.dtsi to preserve the
current functionality. When the device tree files are synced, gmac2phy
should be marked as "broken" in -u-boot.dtsi files.

Reviewed-by: Kever Yang 
Tested-by: Loic Devulder 
Tested-by: Peter Geis 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - none
Changes since v1:
  - Added Kever's reviewed-by
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi | 23 +++
 arch/arm/dts/rk3328-evb.dts | 23 ---
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 5679897279aa..8ba53cf8f44b 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -7,6 +7,13 @@
 #include "rk3328-sdram-ddr3-666.dtsi"
 
 /{
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
compatible = "regulator-fixed";
enable-active-high;
@@ -17,6 +24,22 @@
};
 };
 
+ {
+   phy-supply = <_phy>;
+   phy-mode = "rgmii";
+   clock_in_out = "input";
+   snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 5>;
+   assigned-clocks = < SCLK_MAC2IO>, < SCLK_MAC2IO_EXT>;
+   assigned-clock-parents = <_clkin>, <_clkin>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   tx_delay = <0x26>;
+   rx_delay = <0x11>;
+   status = "okay";
+};
+
 _host0_xhci {
vbus-supply = <_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index e9bc849f8c23..97bef37cf610 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -14,13 +14,6 @@
stdout-path = 
};
 
-   gmac_clkin: external-gmac-clock {
-   compatible = "fixed-clock";
-   clock-frequency = <12500>;
-   clock-output-names = "gmac_clkin";
-   #clock-cells = <0>;
-   };
-
vcc3v3_sdmmc: sdmmc-pwren {
compatible = "regulator-fixed";
regulator-name = "vcc3v3";
@@ -78,22 +71,6 @@
status = "okay";
 };
 
- {
-   phy-supply = <_phy>;
-   phy-mode = "rgmii";
-   clock_in_out = "input";
-   snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
-   snps,reset-active-low;
-   snps,reset-delays-us = <0 1 5>;
-   assigned-clocks = < SCLK_MAC2IO>, < SCLK_MAC2IO_EXT>;
-   assigned-clock-parents = <_clkin>, <_clkin>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   tx_delay = <0x26>;
-   rx_delay = <0x11>;
-   status = "okay";
-};
-
 _host0_ehci {
status = "okay";
 };
-- 
2.26.0

[PATCH v3 3/9] rockchip: dts: rk3328: Move OTG node's hnp-srp-disable to rk3328-u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The "hnp-srp-disable" property for dwc2 is specific to U-boot, not part
of upstream Linux's device tree bindings.

Move it to rk3328-u-boot.dtsi to avoid losing it when syncing device
tree files.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v2:
  - New patch
---
 arch/arm/dts/rk3328-u-boot.dtsi | 4 
 arch/arm/dts/rk3328.dtsi| 1 -
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
index 6d5b3ec06e07..c69e13e11efe 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -62,3 +62,7 @@
/* mmc to sram can't do dma, prevent aborts transfering TF-A parts */
u-boot,spl-fifo-mode;
 };
+
+_otg {
+   hnp-srp-disable;
+};
diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi
index 060c84e6c0cf..57719b82d13e 100644
--- a/arch/arm/dts/rk3328.dtsi
+++ b/arch/arm/dts/rk3328.dtsi
@@ -483,7 +483,6 @@
 "snps,dwc2";
reg = <0x0 0xff58 0x0 0x4>;
interrupts = ;
-   hnp-srp-disable;
dr_mode = "otg";
status = "disabled";
};
-- 
2.26.0

Re: [PATCH v2 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

On Fri, Apr 24, 2020 at 5:20 AM Peter Geis  wrote:
>
> On Thu, Apr 23, 2020 at 5:24 AM Chen-Yu Tsai  wrote:
> >
> > Hi,
> >
> > On Tue, Apr 21, 2020 at 1:35 AM Peter Geis  wrote:
> > >
> > > On Thu, Apr 16, 2020 at 5:53 AM Loic Devulder  wrote:
> > > >
> > > > Hi Chen,
> > > >
> > > > I tested your patches and all work pretty well. I just had issues with
> > > > USB2 that doesn't recognize any of my USB keys (it's OK on USB3).
> > > >
> > > > I also had these issues with XHCI driver:
> > > > => usb reset
> > > > resetting USB...
> > > > BUG at drivers/usb/host/xhci-mem.c:84/xhci_ring_free()!
> > > > BUG!
> > > > �esetting ...
> > > >
> > > > => usb stop
> > > > stopping USB..
> > > > Host not halted after 16000 microseconds.
> > > > XHCI: failed to set VBus supply
> > > > device_remove: Device 'usb@ff60' failed to remove, but children are
> > > > gone
> > > >
> > > > But for the whole series: Tested-by: Loic Devulder 
> > > >
> > > > On Sun, 2020-04-05 at 10:25 +0800, Chen-Yu Tsai wrote:
> > > > > From: Chen-Yu Tsai 
> > > > >
> > > > > Hi everyone,
> > > > >
> > > > > This is v2 of my ROC-RK3328-CC series. Changes from v1 are mainly
> > > > > dropping the custom board target, and dealing with the pinmuxing
> > > > > through proper use of DM regulators / GPIO / pinctrl in SPL.
> > > > >
> > > > > This series adds proper support for Firefly / Libre Computer ROC-
> > > > > RK3328-CC
> > > > > single board computer.
> > > > >
> > > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> > > > > card size development board based on the Rockchip RK3328 SoC, with:
> > > > >
> > > > >   - 1/2/4 GB DDR4 DRAM
> > > > >   - eMMC connector for optional module
> > > > >   - micro SD card slot
> > > > >   - 1 x USB 3.0 host port
> > > > >   - 2 x USB 2.0 host port
> > > > >   - 1 x USB 2.0 OTG port
> > > > >   - HDMI video output
> > > > >   - TRRS connector with audio and composite video output
> > > > >   - gigabit Ethernet
> > > > >   - consumer IR receiver
> > > > >   - debug UART pins
> > > > >
> > > > > Originally I started with Loic's patches, and syncing the device tree
> > > > > files from Linux. That didn't get very far, with SPL failing to
> > > > > detect
> > > > > the SD card. Examining the schematics and internal state of GRF and
> > > > > GPIOs, I realized that the logic for the SD card power enable switch
> > > > > is opposite that of what the SD card controller's SDMMC0_PWREN pin
> > > > > would use. Instead, directly using the GPIO is required.
> > > > >
> > > > > To deal with this, DM regulator and GPIO are enabled in SPL, and
> > > > > various device nodes are marked with u-boot,dm-spl to have them work.
> > > > > pinctrl properties are not stripped, so as to have the SDMMC0_PWREN
> > > > > pin muxed over to GPIO.
> > > > >
> > > > > Along the way, there are some clean-ups of existing dts files, moving
> > > > > U-boot only features to -u-boot.dtsi files, and then a wholesale sync
> > > > > from Linux. Only boards already existing in U-boot are synced. DT
> > > > > binding header files are synced separately as there is already one
> > > > > patch floating around. The DT sync also includes clean-up changes
> > > > > only
> > > > > recently posted, and likely won't make it in for at least a few
> > > > > weeks.
> > > > >
> > > > > Please have a look, and test if possible. I cc-ed a couple people
> > > > > that
> > > > > showed interest in this board on mailing lists recently.
> > > > >
> > > > > Regards
> > > > > ChenYu
> > > > >
> > > > >
> > > > > Chen-Yu Tsai (6):
> > > > >   rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-
> > > > > boot.dtsi
> > > > >   rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-
> > > > &

Re: [PATCH v2 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

Hi,

On Tue, Apr 21, 2020 at 1:35 AM Peter Geis  wrote:
>
> On Thu, Apr 16, 2020 at 5:53 AM Loic Devulder  wrote:
> >
> > Hi Chen,
> >
> > I tested your patches and all work pretty well. I just had issues with
> > USB2 that doesn't recognize any of my USB keys (it's OK on USB3).
> >
> > I also had these issues with XHCI driver:
> > => usb reset
> > resetting USB...
> > BUG at drivers/usb/host/xhci-mem.c:84/xhci_ring_free()!
> > BUG!
> > �esetting ...
> >
> > => usb stop
> > stopping USB..
> > Host not halted after 16000 microseconds.
> > XHCI: failed to set VBus supply
> > device_remove: Device 'usb@ff60' failed to remove, but children are
> > gone
> >
> > But for the whole series: Tested-by: Loic Devulder 
> >
> > On Sun, 2020-04-05 at 10:25 +0800, Chen-Yu Tsai wrote:
> > > From: Chen-Yu Tsai 
> > >
> > > Hi everyone,
> > >
> > > This is v2 of my ROC-RK3328-CC series. Changes from v1 are mainly
> > > dropping the custom board target, and dealing with the pinmuxing
> > > through proper use of DM regulators / GPIO / pinctrl in SPL.
> > >
> > > This series adds proper support for Firefly / Libre Computer ROC-
> > > RK3328-CC
> > > single board computer.
> > >
> > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> > > card size development board based on the Rockchip RK3328 SoC, with:
> > >
> > >   - 1/2/4 GB DDR4 DRAM
> > >   - eMMC connector for optional module
> > >   - micro SD card slot
> > >   - 1 x USB 3.0 host port
> > >   - 2 x USB 2.0 host port
> > >   - 1 x USB 2.0 OTG port
> > >   - HDMI video output
> > >   - TRRS connector with audio and composite video output
> > >   - gigabit Ethernet
> > >   - consumer IR receiver
> > >   - debug UART pins
> > >
> > > Originally I started with Loic's patches, and syncing the device tree
> > > files from Linux. That didn't get very far, with SPL failing to
> > > detect
> > > the SD card. Examining the schematics and internal state of GRF and
> > > GPIOs, I realized that the logic for the SD card power enable switch
> > > is opposite that of what the SD card controller's SDMMC0_PWREN pin
> > > would use. Instead, directly using the GPIO is required.
> > >
> > > To deal with this, DM regulator and GPIO are enabled in SPL, and
> > > various device nodes are marked with u-boot,dm-spl to have them work.
> > > pinctrl properties are not stripped, so as to have the SDMMC0_PWREN
> > > pin muxed over to GPIO.
> > >
> > > Along the way, there are some clean-ups of existing dts files, moving
> > > U-boot only features to -u-boot.dtsi files, and then a wholesale sync
> > > from Linux. Only boards already existing in U-boot are synced. DT
> > > binding header files are synced separately as there is already one
> > > patch floating around. The DT sync also includes clean-up changes
> > > only
> > > recently posted, and likely won't make it in for at least a few
> > > weeks.
> > >
> > > Please have a look, and test if possible. I cc-ed a couple people
> > > that
> > > showed interest in this board on mailing lists recently.
> > >
> > > Regards
> > > ChenYu
> > >
> > >
> > > Chen-Yu Tsai (6):
> > >   rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-
> > > boot.dtsi
> > >   rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-
> > > boot.dtsi
> > >   dt-bindings: clock: rk3328: sync from upstream Linux kernel
> > >   dt-bindings: power: rk3328-power: sync from upstream Linux kernel
> > >   rockchip: dts: rk3328: Sync device tree files from Linux
> > >   rockchip: rk3328: Add support for ROC-RK3328-CC board
> > >
> > >  arch/arm/dts/Makefile |1 +
> > >  arch/arm/dts/rk3328-evb-u-boot.dtsi   |   39 +
> > >  arch/arm/dts/rk3328-evb.dts   |  220 +--
> > >  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi|   38 +
> > >  .../{rk3328-rock64.dts => rk3328-roc-cc.dts}  |  135 +-
> > >  arch/arm/dts/rk3328-rock64.dts|  132 +-
> > >  arch/arm/dts/rk3328.dtsi  | 1420 +++--
> > > 
> > >  board/rockchip/evb_rk3328/MAINTAINERS |7 +
> > >  configs/roc-cc-rk3328_defconfig   |  103 ++
> >

Re: [PATCH V2] rockchip: rk3328: add rockpie-rk3328_defconfig

[Chen-Yu Tsai]

On Thu, Apr 9, 2020 at 7:12 PM b.l.huang  wrote:
>
> From f4253df37579aa9d48f98738eb7db3b6a3b9dff5 Mon Sep 17 00:00:00 2001
> From: "banglang.huang" 
> Date: Thu, 9 Apr 2020 11:49:31 +0800
> Subject: [PATCH V2] rockchip: rk3328: add rockpie-rk3328_defconfig
>
> The ROCKPI-E is a credit card size SBC based on Rockchip RK3328
> Quad-Core ARM Cortex A53.
>
> Net - Dual ethernet port, 1 X Gbe, 1 X 100M
> USB - USB 3.0
> DC  - USB-Type C, 5V 2A
> Storage - TF card, eMMC
>
> Just build u-boot-dtb.bin for Rockpi E board and follow the blow
> steps to replace the relevant partition.
>
>   ./rkbin/tools/loaderimage --pack --uboot u-boot-dtb.bin \
>   uboot.img 0x20 --size 1024 1
>   dd if=uboot.img of=/dev/sdcard seek=16384 conv=notrunc
>
> Signed-off-by: banglang.huang 
> ---
>
> Changes for v2
>
> - add introduction for rockpie in doc/README.rockchip
> - enable CONFIG_MISC_INIT_R, CONFIG_SMBIOS_MANUFACTURER,
>   and CONFIG_SMBIOS_PRODUCT_NAME
>
>  arch/arm/dts/Makefile   |   3 +-
>  arch/arm/dts/rk3328-rockpie-u-boot.dtsi |  12 ++
>  arch/arm/dts/rk3328-rockpie.dts | 256 
>  board/rockchip/evb_rk3328/MAINTAINERS   |   7 +
>  configs/rockpie-rk3328_defconfig|  99 +

Can you separate the different bits of the board name?
For instance we already have

rock-pi-4-rk3399_defconfig / rk3399-rock-pi-4.dts,
so

rock-pi-e-rk3328_defconfig / rk3328-rock-pi-e.dts

should fit the bill.

Also, rockpie will not be pronounced the same way as rock-pi-e.
Rockpie will simply become rock pi, which does wonders for figuring
out which board one is referring to.

ChenYu

[PATCH v2 6/6] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
card size development board based on the Rockchip RK3328 SoC, with:

  - 1/2/4 GB DDR4 DRAM
  - eMMC connector for optional module
  - micro SD card slot
  - 1 x USB 3.0 host port
  - 2 x USB 2.0 host port
  - 1 x USB 2.0 OTG port
  - HDMI video output
  - TRRS connector with audio and composite video output
  - gigabit Ethernet
  - consumer IR receiver
  - debug UART pins

The ROC-RK3328-CC has the enable pin of the SD card power switch tied
to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
muxed by default. SDMMC0_PWREN is an active high signal controlled by
the MMC controller, however the switch enable is active low, and
pulled low (enabled) by default to make things work on boot.

As such, we need to mux away from SDMMC0_PWREN and use GPIO to enable
power to the card. The default GPIO state for the pin is pull-down and
input, which doesn't require extra configuration when paired with the
external pull-down and active low switch.

Deal with this by enabling regulator support in SPL, and setting
"u-boot,dm-spl" for the regulator and other device nodes needed for
muxing the pin.

The device tree file is synced from the Linux kernel next-20200324.

Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:

  - Drop custom target; use pinctrl and regulators in SPL
---
 arch/arm/dts/Makefile  |   1 +
 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi |  38 +++
 arch/arm/dts/rk3328-roc-cc.dts | 354 +
 board/rockchip/evb_rk3328/MAINTAINERS  |   7 +
 configs/roc-cc-rk3328_defconfig| 103 +++
 doc/README.rockchip|   4 +-
 6 files changed, 506 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3328-roc-cc.dts
 create mode 100644 configs/roc-cc-rk3328_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9c593b2c986a..023cb010532d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -104,6 +104,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3308) += \
 
 dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-evb.dtb \
+   rk3328-roc-cc.dtb \
rk3328-rock64.dtb
 
 dtb-$(CONFIG_ROCKCHIP_RK3368) += \
diff --git a/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi 
b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
new file mode 100644
index ..c268fbb9b5b6
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2018-2019 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-ddr4-666.dtsi"
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+ {
+   u-boot,dm-spl;
+};
+
+_gpio {
+   u-boot,dm-spl;
+};
+
+_pull_up_4ma {
+   u-boot,dm-spl;
+};
+
+_host0_xhci {
+   vbus-supply = <_host1_5v>;
+   status = "okay";
+};
+
+/* Need this and all the pinctrl/gpio stuff above to set pinmux */
+_sd {
+   u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/rk3328-roc-cc.dts b/arch/arm/dts/rk3328-roc-cc.dts
new file mode 100644
index ..8d553c92182a
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc.dts
@@ -0,0 +1,354 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 T-Chip Intelligent Technology Co., Ltd
+ */
+
+/dts-v1/;
+#include "rk3328.dtsi"
+
+/ {
+   model = "Firefly roc-rk3328-cc";
+   compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
+   dc_12v: dc-12v {
+   compatible = "regulator-fixed";
+   regulator-name = "dc_12v";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio>;
+   regulator-boot-on;
+   regulator-name = "vcc_sd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_io>;
+   };
+
+   vcc_sdio: sdmmcio-regulator {
+   compatible = "regulator-gpio";
+   

[PATCH v2 2/6] rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The device tree file for rk3328-evb in the Linux kernel does not have
gmac2io enabled. Instead, gmac2phy is enabled, but that is not supported
in U-boot.

Move the gmac2io related nodes to rk3328-evb-u-boot.dtsi to preserve the
current functionality. When the device tree files are synced, gmac2phy
should be marked as "broken" in -u-boot.dtsi files.

Reviewed-by: Kever Yang 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:
  - Added Kever's reviewed-by
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi | 23 +++
 arch/arm/dts/rk3328-evb.dts | 23 ---
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 5679897279aa..8ba53cf8f44b 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -7,6 +7,13 @@
 #include "rk3328-sdram-ddr3-666.dtsi"
 
 /{
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
compatible = "regulator-fixed";
enable-active-high;
@@ -17,6 +24,22 @@
};
 };
 
+ {
+   phy-supply = <_phy>;
+   phy-mode = "rgmii";
+   clock_in_out = "input";
+   snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 5>;
+   assigned-clocks = < SCLK_MAC2IO>, < SCLK_MAC2IO_EXT>;
+   assigned-clock-parents = <_clkin>, <_clkin>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   tx_delay = <0x26>;
+   rx_delay = <0x11>;
+   status = "okay";
+};
+
 _host0_xhci {
vbus-supply = <_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index e9bc849f8c23..97bef37cf610 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -14,13 +14,6 @@
stdout-path = 
};
 
-   gmac_clkin: external-gmac-clock {
-   compatible = "fixed-clock";
-   clock-frequency = <12500>;
-   clock-output-names = "gmac_clkin";
-   #clock-cells = <0>;
-   };
-
vcc3v3_sdmmc: sdmmc-pwren {
compatible = "regulator-fixed";
regulator-name = "vcc3v3";
@@ -78,22 +71,6 @@
status = "okay";
 };
 
- {
-   phy-supply = <_phy>;
-   phy-mode = "rgmii";
-   clock_in_out = "input";
-   snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
-   snps,reset-active-low;
-   snps,reset-delays-us = <0 1 5>;
-   assigned-clocks = < SCLK_MAC2IO>, < SCLK_MAC2IO_EXT>;
-   assigned-clock-parents = <_clkin>, <_clkin>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   tx_delay = <0x26>;
-   rx_delay = <0x11>;
-   status = "okay";
-};
-
 _host0_ehci {
status = "okay";
 };
-- 
2.26.0

[PATCH v2 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi everyone,

This is v2 of my ROC-RK3328-CC series. Changes from v1 are mainly
dropping the custom board target, and dealing with the pinmuxing
through proper use of DM regulators / GPIO / pinctrl in SPL.

This series adds proper support for Firefly / Libre Computer ROC-RK3328-CC
single board computer.

The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
card size development board based on the Rockchip RK3328 SoC, with:

  - 1/2/4 GB DDR4 DRAM
  - eMMC connector for optional module
  - micro SD card slot
  - 1 x USB 3.0 host port
  - 2 x USB 2.0 host port
  - 1 x USB 2.0 OTG port
  - HDMI video output
  - TRRS connector with audio and composite video output
  - gigabit Ethernet
  - consumer IR receiver
  - debug UART pins

Originally I started with Loic's patches, and syncing the device tree
files from Linux. That didn't get very far, with SPL failing to detect
the SD card. Examining the schematics and internal state of GRF and
GPIOs, I realized that the logic for the SD card power enable switch
is opposite that of what the SD card controller's SDMMC0_PWREN pin
would use. Instead, directly using the GPIO is required.

To deal with this, DM regulator and GPIO are enabled in SPL, and
various device nodes are marked with u-boot,dm-spl to have them work.
pinctrl properties are not stripped, so as to have the SDMMC0_PWREN
pin muxed over to GPIO.

Along the way, there are some clean-ups of existing dts files, moving
U-boot only features to -u-boot.dtsi files, and then a wholesale sync
from Linux. Only boards already existing in U-boot are synced. DT
binding header files are synced separately as there is already one
patch floating around. The DT sync also includes clean-up changes only
recently posted, and likely won't make it in for at least a few weeks.

Please have a look, and test if possible. I cc-ed a couple people that
showed interest in this board on mailing lists recently.

Regards
ChenYu


Chen-Yu Tsai (6):
  rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi
  rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi
  dt-bindings: clock: rk3328: sync from upstream Linux kernel
  dt-bindings: power: rk3328-power: sync from upstream Linux kernel
  rockchip: dts: rk3328: Sync device tree files from Linux
  rockchip: rk3328: Add support for ROC-RK3328-CC board

 arch/arm/dts/Makefile |1 +
 arch/arm/dts/rk3328-evb-u-boot.dtsi   |   39 +
 arch/arm/dts/rk3328-evb.dts   |  220 +--
 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi|   38 +
 .../{rk3328-rock64.dts => rk3328-roc-cc.dts}  |  135 +-
 arch/arm/dts/rk3328-rock64.dts|  132 +-
 arch/arm/dts/rk3328.dtsi  | 1420 +++--
 board/rockchip/evb_rk3328/MAINTAINERS |7 +
 configs/roc-cc-rk3328_defconfig   |  103 ++
 doc/README.rockchip   |4 +-
 include/dt-bindings/clock/rk3328-cru.h|  212 +--
 include/dt-bindings/power/rk3328-power.h  |   19 +
 12 files changed, 1578 insertions(+), 752 deletions(-)
 create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
 copy arch/arm/dts/{rk3328-rock64.dts => rk3328-roc-cc.dts} (68%)
 create mode 100644 configs/roc-cc-rk3328_defconfig
 create mode 100644 include/dt-bindings/power/rk3328-power.h

-- 
2.26.0

[PATCH v2 1/6] rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

USB 3.0 is only supported in U-boot, not in the Linux kernel where the
device tree files are ultimately synced from. While the xhci node was
moved, the external vbus regulator was not.

Move it as well.

Fixes: 2e91e2025c1b ("rockchip: rk3328: migrate u-boot node to -u-boot.dtsi")
Reviewed-by: Kever Yang 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:
  - Added Kever's reviewed-by
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi | 11 +++
 arch/arm/dts/rk3328-evb.dts |  9 -
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 4a827063c555..5679897279aa 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -6,6 +6,17 @@
 #include "rk3328-u-boot.dtsi"
 #include "rk3328-sdram-ddr3-666.dtsi"
 
+/{
+   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = < 0 GPIO_ACTIVE_HIGH>;
+   regulator-name = "vcc5v0_host_xhci";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
 _host0_xhci {
vbus-supply = <_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index a2ee838fcd6b..e9bc849f8c23 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -38,15 +38,6 @@
regulator-max-microvolt = <500>;
};
 
-   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
-   compatible = "regulator-fixed";
-   enable-active-high;
-   regulator-name = "vcc5v0_host_xhci";
-   gpio = < 0 GPIO_ACTIVE_HIGH>;
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   };
-
vcc_phy: vcc-phy-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_phy";
-- 
2.26.0

[PATCH v2 5/6] rockchip: dts: rk3328: Sync device tree files from Linux

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs rk3328 device tree files from the Linux kernel next-20200324.
The last commit to touch these files is:

b2411befed60 ("arm64: dts: add bus to rockchip amba nodenames")

Additional changes not yet in the Linux kernel include:

arm64: dts: rockchip: rk3328: drop #address-cells, #size-cells from grf node
arm64: dts: rockchip: rk3328: drop non-existent gmac2phy pinmux options
arm64: dts: rockchip: rk3328: Replace RK805 PMIC node name with "pmic"

Changes include:

  - conversion of raw pin numbers to macros
  - removal of deprecated RK_FUNC_* macros
  - update of device tree binding headers
  - new devices
  - device tree cleanups
  - gmac2phy disabled in -u-boot.dtsi as it is not supported in U-boot

Reviewed-by: Kever Yang 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:
  - Added Kever's reviewed-by
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi |5 +
 arch/arm/dts/rk3328-evb.dts |  196 ++--
 arch/arm/dts/rk3328-rock64.dts  |  132 ++-
 arch/arm/dts/rk3328.dtsi| 1420 +--
 4 files changed, 1164 insertions(+), 589 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 8ba53cf8f44b..4bfa0c2330ba 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -40,6 +40,11 @@
status = "okay";
 };
 
+ {
+   /* Integrated PHY unsupported by U-boot */
+   status = "broken";
+};
+
 _host0_xhci {
vbus-supply = <_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index 97bef37cf610..6abc6f4a86cf 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -1,6 +1,6 @@
-// SPDX-License-Identifier: GPL-2.0+
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 /*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
  */
 
 /dts-v1/;
@@ -11,24 +11,51 @@
compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
 
chosen {
-   stdout-path = 
+   stdout-path = "serial2:150n8";
};
 
-   vcc3v3_sdmmc: sdmmc-pwren {
+   dc_12v: dc-12v {
compatible = "regulator-fixed";
-   regulator-name = "vcc3v3";
-   gpio = < 30 GPIO_ACTIVE_LOW>;
+   regulator-name = "dc_12v";
regulator-always-on;
regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   pinctrl-names = "default";
+   pinctrl-0 = <_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 = < 18 GPIO_ACTIVE_LOW>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = < 30 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio>;
+   regulator-name = "vcc_sd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_io>;
};
 
-   vcc5v0_otg: vcc5v0-otg-drv {
+   vcc_sys: vcc-sys {
compatible = "regulator-fixed";
-   enable-active-high;
-   regulator-name = "vcc5v0_otg";
-   gpio = < 27 GPIO_ACTIVE_HIGH>;
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
+   vin-supply = <_12v>;
};
 
vcc_phy: vcc-phy-regulator {
@@ -39,80 +66,60 @@
};
 };
 
- {
-   status = "okay";
-};
-
- {
-   status = "okay";
-};
-
- {
-   bus-width = <4>;
-   cap-mmc-highspeed;
-   cap-sd-highspeed;
-   card-detect-delay = <200>;
-   disable-wp;
-   num-slots = <1>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_clk>, <_cmd>, <_dectn>, 
<_bus4>;
-   status = "okay";
+ {
+   cpu-supply = <_arm>;
 };
 
  {
bus-width = <8>;
cap-mmc-highspeed;
-   supports-emmc;
-   disable-wp;
non-removable;
-   num-slots = 

[PATCH v2 3/6] dt-bindings: clock: rk3328: sync from upstream Linux kernel

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs the rk3328 clock header file from Linux kernel next-20200324,
to support newer hardware blocks when syncing the device tree files.

The last non-merge commit to touch it was

0dc14b013f79 ("clk: rockchip: add clock id for watchdog pclk on rk3328")

Reviewed-by: Kever Yang 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:
  - Added Kever's reviewed-by
---
 include/dt-bindings/clock/rk3328-cru.h | 212 -
 1 file changed, 106 insertions(+), 106 deletions(-)

diff --git a/include/dt-bindings/clock/rk3328-cru.h 
b/include/dt-bindings/clock/rk3328-cru.h
index cde61ed8830b..555b4ff660ae 100644
--- a/include/dt-bindings/clock/rk3328-cru.h
+++ b/include/dt-bindings/clock/rk3328-cru.h
@@ -1,6 +1,7 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
+/* SPDX-License-Identifier: GPL-2.0-or-later */
 /*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Elaine 
  */
 
 #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3328_H
@@ -90,119 +91,118 @@
 #define SCLK_MAC2IO_EXT102
 
 /* dclk gates */
-#define DCLK_LCDC  180
-#define DCLK_HDMIPHY   181
-#define HDMIPHY182
-#define USB480M183
-#define DCLK_LCDC_SRC  184
+#define DCLK_LCDC  120
+#define DCLK_HDMIPHY   121
+#define HDMIPHY122
+#define USB480M123
+#define DCLK_LCDC_SRC  124
 
 /* aclk gates */
-#define ACLK_AXISRAM   190
-#define ACLK_VOP_PRE   191
-#define ACLK_USB3OTG   192
-#define ACLK_RGA_PRE   193
-#define ACLK_DMAC  194
-#define ACLK_GPU   195
-#define ACLK_BUS_PRE   196
-#define ACLK_PERI_PRE  197
-#define ACLK_RKVDEC_PRE198
-#define ACLK_RKVDEC199
-#define ACLK_RKVENC200
-#define ACLK_VPU_PRE   201
-#define ACLK_VIO_PRE   202
-#define ACLK_VPU   203
-#define ACLK_VIO   204
-#define ACLK_VOP   205
-#define ACLK_GMAC  206
-#define ACLK_H265  207
-#define ACLK_H264  208
-#define ACLK_MAC2PHY   209
-#define ACLK_MAC2IO210
-#define ACLK_DCF   211
-#define ACLK_TSP   212
-#define ACLK_PERI  213
-#define ACLK_RGA   214
-#define ACLK_IEP   215
-#define ACLK_CIF   216
-#define ACLK_HDCP  217
+#define ACLK_AXISRAM   130
+#define ACLK_VOP_PRE   131
+#define ACLK_USB3OTG   132
+#define ACLK_RGA_PRE   133
+#define ACLK_DMAC  134
+#define ACLK_GPU   135
+#define ACLK_BUS_PRE   136
+#define ACLK_PERI_PRE  137
+#define ACLK_RKVDEC_PRE138
+#define ACLK_RKVDEC139
+#define ACLK_RKVENC140
+#define ACLK_VPU_PRE   141
+#define ACLK_VIO_PRE   142
+#define ACLK_VPU   143
+#define ACLK_VIO   144
+#define ACLK_VOP   145
+#define ACLK_GMAC  146
+#define ACLK_H265  147
+#define ACLK_H264  148
+#define ACLK_MAC2PHY   149
+#define ACLK_MAC2IO150
+#define ACLK_DCF   151
+#define ACLK_TSP   152
+#define ACLK_PERI  153
+#define ACLK_RGA   154
+#define ACLK_IEP   155
+#define ACLK_CIF   156
+#define ACLK_HDCP  157
 
 /* pclk gates */
-#define PCLK_GPIO0 300
-#define PCLK_GPIO1 301
-#define PCLK_GPIO2 302
-#define PCLK_GPIO3 303
-#define PCLK_GRF   304
-#define PCLK_I2C0  305
-#define PCLK_I2C1  306
-#define PCLK_I2C2  307
-#define PCLK_I2C3  308
-#define PCLK_SPI   309
-#define PCLK_UART0 310
-#define PCLK_UART1 311
-#define PCLK_UART2 312
-#define PCLK_TSADC 313
-#define PCLK_PWM   314
-#define PCLK_TIMER 315
-#define PCLK_BUS_PRE   316
-#define PCLK_PERI_PRE  317
-#define PCLK_HDMI_CTRL 318
-#define PCLK_HDMI_PHY  319
-#define PCLK_GMAC  320
-#define PCLK_H265  321
-#define PCLK_MAC2PHY   322
-#define PCLK_MAC2IO323
-#define PCLK_USB3PHY_OTG   324
-#define PCLK_USB3PHY_PIPE  325
-#define PCLK_USB3_GRF  326
-#define PCLK_USB2_GRF  327
-#define PCLK_HDMIPHY   328
-#define PCLK_DDR   329
-#define PCLK_PERI  330
-#define PCLK_HDMI  331
-#define PCLK_HDCP  332
-#define PCLK_DCF   333
-#define PCLK_SARADC334
+#define PCLK_GPIO0 200
+#define PCLK_GPIO1 201
+#define PCLK_GPIO2 202
+#define PCLK_GPIO3 20

[PATCH v2 4/6] dt-bindings: power: rk3328-power: sync from upstream Linux kernel

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs the rk3328 power domain header file from Linux kernel
next-20200324, to support newer hardware blocks when syncing the
device tree files.

The last non-merge commit to touch it was

b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to 
files with no license")

Reviewed-by: Kever Yang 
Signed-off-by: Chen-Yu Tsai 
---
Changes since v1:
  - Added Kever's reviewed-by
---
 include/dt-bindings/power/rk3328-power.h | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3328-power.h

diff --git a/include/dt-bindings/power/rk3328-power.h 
b/include/dt-bindings/power/rk3328-power.h
new file mode 100644
index ..02e3d7fc1cce
--- /dev/null
+++ b/include/dt-bindings/power/rk3328-power.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DT_BINDINGS_POWER_RK3328_POWER_H__
+#define __DT_BINDINGS_POWER_RK3328_POWER_H__
+
+/**
+ * RK3328 idle id Summary.
+ */
+#define RK3328_PD_CORE 0
+#define RK3328_PD_GPU  1
+#define RK3328_PD_BUS  2
+#define RK3328_PD_MSCH 3
+#define RK3328_PD_PERI 4
+#define RK3328_PD_VIDEO5
+#define RK3328_PD_HEVC 6
+#define RK3328_PD_SYS  7
+#define RK3328_PD_VPU  8
+#define RK3328_PD_VIO  9
+
+#endif
-- 
2.26.0

Re: [PATCH 6/6] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

On Tue, Mar 31, 2020 at 8:37 PM Jagan Teki  wrote:
>
> On Tue, Mar 31, 2020 at 5:16 PM Chen-Yu Tsai  wrote:
> >
> > On Tue, Mar 31, 2020 at 6:57 PM Jagan Teki  
> > wrote:
> > >
> > > On Mon, Mar 30, 2020 at 11:54 PM Chen-Yu Tsai  wrote:
> > > >
> > > > On Tue, Mar 31, 2020 at 1:44 AM Jagan Teki  
> > > > wrote:
> > > > >
> > > > > Hi Chen-Yu,
> > > > >
> > > > > On Fri, Mar 27, 2020 at 10:12 AM Chen-Yu Tsai  wrote:
> > > > > >
> > > > > > From: Chen-Yu Tsai 
> > > > > >
> > > > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a 
> > > > > > credit
> > > > > > card size development board based on the Rockchip RK3328 SoC, with:
> > > > > >
> > > > > >   - 1/2/4 GB DDR4 DRAM
> > > > > >   - eMMC connector for optional module
> > > > > >   - micro SD card slot
> > > > > >   - 1 x USB 3.0 host port
> > > > > >   - 2 x USB 2.0 host port
> > > > > >   - 1 x USB 2.0 OTG port
> > > > > >   - HDMI video output
> > > > > >   - TRRS connector with audio and composite video output
> > > > > >   - gigabit Ethernet
> > > > > >   - consumer IR receiver
> > > > > >   - debug UART pins
> > > > > >
> > > > > > The ROC-RK3328-CC has the enable pin of the SD card power switch 
> > > > > > tied
> > > > > > to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
> > > > > > muxed by default. SDMMC0_PWREN is an active high signal controlled 
> > > > > > by
> > > > > > the MMC controller, however the switch enable is active low, and
> > > > > > pulled low (enabled) by default to make things work on boot.
> > > > > >
> > > > > > As such, we need to mux away from SDMMC0_PWREN and use GPIO to 
> > > > > > enable
> > > > > > power to the card. The default GPIO state for the pin is pull-down 
> > > > > > and
> > > > > > input, which doesn't require extra configuration when paired with 
> > > > > > the
> > > > > > external pull-down and active low switch.
> > > > > >
> > > > > > Thus we make a custom target for this board and do the muxing in its
> > > > > > spl_board_init() function.
> > > > > >
> > > > > > The device tree file is synced from the Linux kernel next-20200324.
> > > > > >
> > > > > > Signed-off-by: Chen-Yu Tsai 
> > > > > > ---
> > > > >
> > > > > [snip]
> > > > >
> > > > > > diff --git a/board/firefly/roc-cc-rk3328/MAINTAINERS 
> > > > > > b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > > > new file mode 100644
> > > > > > index ..f2318e71ac33
> > > > > > --- /dev/null
> > > > > > +++ b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > > > @@ -0,0 +1,7 @@
> > > > > > +ROC-RK3328-CC
> > > > > > +M:  Loic Devulder 
> > > > > > +M: Chen-Yu Tsai 
> > > > > > +S:  Maintained
> > > > > > +F: board/firefly/roc-cc-rk3328/
> > > > > > +F:  configs/roc-rk3328-cc_defconfig
> > > > > > +F:  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> > > > > > diff --git a/board/firefly/roc-cc-rk3328/Makefile 
> > > > > > b/board/firefly/roc-cc-rk3328/Makefile
> > > > > > new file mode 100644
> > > > > > index ..1550b5f5f16e
> > > > > > --- /dev/null
> > > > > > +++ b/board/firefly/roc-cc-rk3328/Makefile
> > > > > > @@ -0,0 +1 @@
> > > > > > +obj-y  := board.o
> > > > > > diff --git a/board/firefly/roc-cc-rk3328/board.c 
> > > > > > b/board/firefly/roc-cc-rk3328/board.c
> > > > > > new file mode 100644
> > > > > > index ..eca58c86b53e
> > > > > > --- /dev/null
> > > > > > +++ b/board/firefly/roc-cc-rk3328/board.c
> > > > > > @@ -0,0 +1,38 @@
> > > > > > +// SPDX-License-Identifier: GPL-2.0+
> > &g

Re: [PATCH 6/6] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

On Tue, Mar 31, 2020 at 6:57 PM Jagan Teki  wrote:
>
> On Mon, Mar 30, 2020 at 11:54 PM Chen-Yu Tsai  wrote:
> >
> > On Tue, Mar 31, 2020 at 1:44 AM Jagan Teki  
> > wrote:
> > >
> > > Hi Chen-Yu,
> > >
> > > On Fri, Mar 27, 2020 at 10:12 AM Chen-Yu Tsai  wrote:
> > > >
> > > > From: Chen-Yu Tsai 
> > > >
> > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> > > > card size development board based on the Rockchip RK3328 SoC, with:
> > > >
> > > >   - 1/2/4 GB DDR4 DRAM
> > > >   - eMMC connector for optional module
> > > >   - micro SD card slot
> > > >   - 1 x USB 3.0 host port
> > > >   - 2 x USB 2.0 host port
> > > >   - 1 x USB 2.0 OTG port
> > > >   - HDMI video output
> > > >   - TRRS connector with audio and composite video output
> > > >   - gigabit Ethernet
> > > >   - consumer IR receiver
> > > >   - debug UART pins
> > > >
> > > > The ROC-RK3328-CC has the enable pin of the SD card power switch tied
> > > > to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
> > > > muxed by default. SDMMC0_PWREN is an active high signal controlled by
> > > > the MMC controller, however the switch enable is active low, and
> > > > pulled low (enabled) by default to make things work on boot.
> > > >
> > > > As such, we need to mux away from SDMMC0_PWREN and use GPIO to enable
> > > > power to the card. The default GPIO state for the pin is pull-down and
> > > > input, which doesn't require extra configuration when paired with the
> > > > external pull-down and active low switch.
> > > >
> > > > Thus we make a custom target for this board and do the muxing in its
> > > > spl_board_init() function.
> > > >
> > > > The device tree file is synced from the Linux kernel next-20200324.
> > > >
> > > > Signed-off-by: Chen-Yu Tsai 
> > > > ---
> > >
> > > [snip]
> > >
> > > > diff --git a/board/firefly/roc-cc-rk3328/MAINTAINERS 
> > > > b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > new file mode 100644
> > > > index ..f2318e71ac33
> > > > --- /dev/null
> > > > +++ b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > @@ -0,0 +1,7 @@
> > > > +ROC-RK3328-CC
> > > > +M:  Loic Devulder 
> > > > +M: Chen-Yu Tsai 
> > > > +S:  Maintained
> > > > +F: board/firefly/roc-cc-rk3328/
> > > > +F:  configs/roc-rk3328-cc_defconfig
> > > > +F:  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> > > > diff --git a/board/firefly/roc-cc-rk3328/Makefile 
> > > > b/board/firefly/roc-cc-rk3328/Makefile
> > > > new file mode 100644
> > > > index ..1550b5f5f16e
> > > > --- /dev/null
> > > > +++ b/board/firefly/roc-cc-rk3328/Makefile
> > > > @@ -0,0 +1 @@
> > > > +obj-y  := board.o
> > > > diff --git a/board/firefly/roc-cc-rk3328/board.c 
> > > > b/board/firefly/roc-cc-rk3328/board.c
> > > > new file mode 100644
> > > > index ..eca58c86b53e
> > > > --- /dev/null
> > > > +++ b/board/firefly/roc-cc-rk3328/board.c
> > > > @@ -0,0 +1,38 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * (C) Copyright 2020 Chen-Yu Tsai 
> > > > + */
> > > > +#include 
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +#if defined(CONFIG_SPL_BUILD)
> > > > +
> > > > +#define GRF_BASE   0xFF10
> > > > +
> > > > +enum {
> > > > +   GPIO_0_D6_GPIO  = 0   << 12,
> > > > +   GPIO_0_D6_MASK  = 0x3 << 12
> > > > +};
> > > > +
> > > > +/*
> > > > + * The ROC-RK3328-CC has the enable pin of the SD card power switch 
> > > > tied
> > > > + * to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
> > > > + * muxed by default. SDMMC0_PWREN is an active high signal controlled 
> > > > by
> > > > + * the MMC controller, however the switch enable is active low, and
> > > > + * pulled low (enabled) by default to make things work on boot.
> > > &g

Re: [PATCH 6/6] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

On Tue, Mar 31, 2020 at 1:44 AM Jagan Teki  wrote:
>
> Hi Chen-Yu,
>
> On Fri, Mar 27, 2020 at 10:12 AM Chen-Yu Tsai  wrote:
> >
> > From: Chen-Yu Tsai 
> >
> > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> > card size development board based on the Rockchip RK3328 SoC, with:
> >
> >   - 1/2/4 GB DDR4 DRAM
> >   - eMMC connector for optional module
> >   - micro SD card slot
> >   - 1 x USB 3.0 host port
> >   - 2 x USB 2.0 host port
> >   - 1 x USB 2.0 OTG port
> >   - HDMI video output
> >   - TRRS connector with audio and composite video output
> >   - gigabit Ethernet
> >   - consumer IR receiver
> >   - debug UART pins
> >
> > The ROC-RK3328-CC has the enable pin of the SD card power switch tied
> > to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
> > muxed by default. SDMMC0_PWREN is an active high signal controlled by
> > the MMC controller, however the switch enable is active low, and
> > pulled low (enabled) by default to make things work on boot.
> >
> > As such, we need to mux away from SDMMC0_PWREN and use GPIO to enable
> > power to the card. The default GPIO state for the pin is pull-down and
> > input, which doesn't require extra configuration when paired with the
> > external pull-down and active low switch.
> >
> > Thus we make a custom target for this board and do the muxing in its
> > spl_board_init() function.
> >
> > The device tree file is synced from the Linux kernel next-20200324.
> >
> > Signed-off-by: Chen-Yu Tsai 
> > ---
>
> [snip]
>
> > diff --git a/board/firefly/roc-cc-rk3328/MAINTAINERS 
> > b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > new file mode 100644
> > index ..f2318e71ac33
> > --- /dev/null
> > +++ b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > @@ -0,0 +1,7 @@
> > +ROC-RK3328-CC
> > +M:  Loic Devulder 
> > +M: Chen-Yu Tsai 
> > +S:  Maintained
> > +F: board/firefly/roc-cc-rk3328/
> > +F:  configs/roc-rk3328-cc_defconfig
> > +F:  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> > diff --git a/board/firefly/roc-cc-rk3328/Makefile 
> > b/board/firefly/roc-cc-rk3328/Makefile
> > new file mode 100644
> > index ..1550b5f5f16e
> > --- /dev/null
> > +++ b/board/firefly/roc-cc-rk3328/Makefile
> > @@ -0,0 +1 @@
> > +obj-y  := board.o
> > diff --git a/board/firefly/roc-cc-rk3328/board.c 
> > b/board/firefly/roc-cc-rk3328/board.c
> > new file mode 100644
> > index ..eca58c86b53e
> > --- /dev/null
> > +++ b/board/firefly/roc-cc-rk3328/board.c
> > @@ -0,0 +1,38 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * (C) Copyright 2020 Chen-Yu Tsai 
> > + */
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +#if defined(CONFIG_SPL_BUILD)
> > +
> > +#define GRF_BASE   0xFF10
> > +
> > +enum {
> > +   GPIO_0_D6_GPIO  = 0   << 12,
> > +   GPIO_0_D6_MASK  = 0x3 << 12
> > +};
> > +
> > +/*
> > + * The ROC-RK3328-CC has the enable pin of the SD card power switch tied
> > + * to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
> > + * muxed by default. SDMMC0_PWREN is an active high signal controlled by
> > + * the MMC controller, however the switch enable is active low, and
> > + * pulled low (enabled) by default to make things work on boot.
> > + *
> > + * As such, we need to mux away from SDMMC0_PWREN and use GPIO to enable
> > + * power to the card. The default GPIO state for the pin is pull-down and
> > + * input, which doesn't require extra configuration when paired with the
> > + * external pull-down and active low switch.
> > + */
> > +void spl_board_init(void)
> > +{
> > +   struct rk3328_grf_regs * const grf = (void *)GRF_BASE;
> > +
> > +   rk_clrsetreg(>gpio0d_iomux, GPIO_0_D6_MASK, GPIO_0_D6_GPIO);
> > +}
>
> So, this seem toggle the bit 12, 13 of GRF_GPIO0D_IOMUX so-that it
> operate like a gpio(not like default sdmmc0_pwrenm1), isn't it
> required for the next stages like U-Boot proper and Linux? these has
> vcc_sd node where it operates a fixed regulator to active low the same
> pin.
>
> gpio = < RK_PD6 GPIO_ACTIVE_LOW>;

So U-boot proper and Linux both have pinctrl and GPIO and all the stuff
to deal with this. SPL doesn't have GPIO enabled, and I believe all the
pinctrl properties are striped out. (BTW, not sure why we're enabling
pinctrl driver support in SPL if nothing is triggering them.) It seems
a bit heavy pulling all that stuff in just for one pin mux in SPL. The
same is also done for the UART pins.

ChenYu

Re: [PATCH 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

On Sat, Mar 28, 2020 at 6:03 AM Kurt Miller  wrote:
>
> On Sat, 2020-03-28 at 01:44 +0800, Chen-Yu Tsai wrote:
> > Hi,
> >
> > On Fri, Mar 27, 2020 at 11:07 PM Kurt Miller  
> > wrote:
> > >
> > >
> > > On Fri, 2020-03-27 at 12:41 +0800, Chen-Yu Tsai wrote:
> > > >
> > > > From: Chen-Yu Tsai 
> > > >
> > > > Hi everyone,
> > > >
> > > > This series adds proper support for Firefly / Libre Computer 
> > > > ROC-RK3328-CC
> > > > single board computer.
> > > >
> > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> > > > card size development board based on the Rockchip RK3328 SoC, with:
> > > >
> > > >   - 1/2/4 GB DDR4 DRAM
> > > >   - eMMC connector for optional module
> > > >   - micro SD card slot
> > > >   - 1 x USB 3.0 host port
> > > >   - 2 x USB 2.0 host port
> > > >   - 1 x USB 2.0 OTG port
> > > >   - HDMI video output
> > > >   - TRRS connector with audio and composite video output
> > > >   - gigabit Ethernet
> > > >   - consumer IR receiver
> > > >   - debug UART pins
> > > >
> > > > Originally I started with Loic's patches, and syncing the device tree
> > > > files from Linux. That didn't get very far, with SPL failing to detect
> > > > the SD card. Examining the schematics and internal state of GRF and
> > > > GPIOs, I realized that the logic for the SD card power enable switch
> > > > is opposite that of what the SD card controller's SDMMC0_PWREN pin
> > > > would use. Instead, directly using the GPIO is required.
> > > >
> > > > Thus this series creates a special target for this board to handle
> > > > muxing this specific pin to GPIO state. The GPIO is left in input mode,
> > > > letting the external pull-down work its magic.
> > > >
> > > > Along the way, there are some clean-ups of existing dts files, moving
> > > > U-boot only features to -u-boot.dtsi files, and then a wholesale sync
> > > > from Linux. Only boards already existing in U-boot are synced. DT
> > > > binding header files are synced separately as there is already one
> > > > patch floating around. The DT sync also includes clean-up changes only
> > > > recently posted, and likely won't make it in for at least a few weeks.
> > > >
> > > > Please have a look, and test if possible. I cc-ed a couple people that
> > > > showed interest in this board on mailing lists recently.
> > > >
> > > Thank you for updating the dts for rk3328. I have Rock64 v2 and v3
> > > boards and have tested your patchset with OpenBSD-current. The v2 board
> > > is working and I have not noticed any regressions. The v3 board prior
> > > to your patchset was not booting and continues to not boot.
> > >
> > > U-Boot TPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24)
> > > LPDDR3, 800MHz
> > > BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB
> > > Trying to boot from BOOTROM
> > > Returning to boot ROM...
> > >
> > > U-Boot SPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24 
> > > -0400)
> > > Trying to boot from MMC1
> > > Card did not respond to voltage select!
> > > spl: mmc init failed with error: -95
> > > Trying to boot from MMC2
> > > Card did not respond to voltage select!
> > > spl: mmc init failed with error: -95
> > > SPL: failed to boot from all boot devices
> > > ### ERROR ### Please RESET the board ###
> > >
> > > The Rock64 v3 board issues are unrelated to your patch set, but I
> > > believe it needs a similar approach as ROC-RK3328-CC. Here is some
> > > info previously posted regarding this:
> > >
> > > https://marc.info/?t=15575150651=1=2
> > So based on the changes from Pine64, it looks like v3 follows a similar
> > design as the ROC-RK3328-CC, that is use the SDMMC0_PWREN pin to control
> > power to the SD card. On the Rock64 v3, there's no external pull-down,
> > but the internal pull-down might be enough...
> >
> > You could try setting the target to ROC-RK3328-CC through menuconfig
> > after you use the defconfig for rock64 and see if that works for you.
> >
>
> Yes, that works for both the v2 and v3 boards. Thank you.
>
> Would you be able to create a patch 7 in your series to
> apply this approch to the rock64?

I took a look at the schematics again. The SDMMC0_PWREN pin is used to
toggle the I/O signalling voltage. There is no power cut for the SD card.
So configuring SDMMC0_PWREN to GPIO will get you through SPL, but why it
works is slightly different for the Rock64 compared to the ROC-RK3328-CC.

ChenYu

Re: [PATCH 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

Hi,

On Fri, Mar 27, 2020 at 11:07 PM Kurt Miller  wrote:
>
> On Fri, 2020-03-27 at 12:41 +0800, Chen-Yu Tsai wrote:
> > From: Chen-Yu Tsai 
> >
> > Hi everyone,
> >
> > This series adds proper support for Firefly / Libre Computer ROC-RK3328-CC
> > single board computer.
> >
> > The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
> > card size development board based on the Rockchip RK3328 SoC, with:
> >
> >   - 1/2/4 GB DDR4 DRAM
> >   - eMMC connector for optional module
> >   - micro SD card slot
> >   - 1 x USB 3.0 host port
> >   - 2 x USB 2.0 host port
> >   - 1 x USB 2.0 OTG port
> >   - HDMI video output
> >   - TRRS connector with audio and composite video output
> >   - gigabit Ethernet
> >   - consumer IR receiver
> >   - debug UART pins
> >
> > Originally I started with Loic's patches, and syncing the device tree
> > files from Linux. That didn't get very far, with SPL failing to detect
> > the SD card. Examining the schematics and internal state of GRF and
> > GPIOs, I realized that the logic for the SD card power enable switch
> > is opposite that of what the SD card controller's SDMMC0_PWREN pin
> > would use. Instead, directly using the GPIO is required.
> >
> > Thus this series creates a special target for this board to handle
> > muxing this specific pin to GPIO state. The GPIO is left in input mode,
> > letting the external pull-down work its magic.
> >
> > Along the way, there are some clean-ups of existing dts files, moving
> > U-boot only features to -u-boot.dtsi files, and then a wholesale sync
> > from Linux. Only boards already existing in U-boot are synced. DT
> > binding header files are synced separately as there is already one
> > patch floating around. The DT sync also includes clean-up changes only
> > recently posted, and likely won't make it in for at least a few weeks.
> >
> > Please have a look, and test if possible. I cc-ed a couple people that
> > showed interest in this board on mailing lists recently.
> >
>
> Thank you for updating the dts for rk3328. I have Rock64 v2 and v3
> boards and have tested your patchset with OpenBSD-current. The v2 board
> is working and I have not noticed any regressions. The v3 board prior
> to your patchset was not booting and continues to not boot.
>
> U-Boot TPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24)
> LPDDR3, 800MHz
> BW=32 Col=11 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=4096MB
> Trying to boot from BOOTROM
> Returning to boot ROM...
>
> U-Boot SPL 2020.04-rc3-00172-gaf827140e5-dirty (Mar 27 2020 - 09:44:24 -0400)
> Trying to boot from MMC1
> Card did not respond to voltage select!
> spl: mmc init failed with error: -95
> Trying to boot from MMC2
> Card did not respond to voltage select!
> spl: mmc init failed with error: -95
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> The Rock64 v3 board issues are unrelated to your patch set, but I
> believe it needs a similar approach as ROC-RK3328-CC. Here is some
> info previously posted regarding this:
>
> https://marc.info/?t=15575150651=1=2

So based on the changes from Pine64, it looks like v3 follows a similar
design as the ROC-RK3328-CC, that is use the SDMMC0_PWREN pin to control
power to the SD card. On the Rock64 v3, there's no external pull-down,
but the internal pull-down might be enough...

You could try setting the target to ROC-RK3328-CC through menuconfig
after you use the defconfig for rock64 and see if that works for you.


ChenYu

> Regards,
> -Kurt
>
>
> > Regards
> > ChenYu
> >
> >
> > Chen-Yu Tsai (6):
> >   rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi
> >   rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi
> >   dt-bindings: clock: rk3328: sync from upstream Linux kernel
> >   dt-bindings: power: rk3328-power: sync from upstream Linux kernel
> >   rockchip: dts: rk3328: Sync device tree files from Linux
> >   rockchip: rk3328: Add support for ROC-RK3328-CC board
> >
> >  arch/arm/dts/Makefile |1 +
> >  arch/arm/dts/rk3328-evb-u-boot.dtsi   |   39 +
> >  arch/arm/dts/rk3328-evb.dts   |  220 +--
> >  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi|   17 +
> >  .../{rk3328-rock64.dts => rk3328-roc-cc.dts}  |  135 +-
> >  arch/arm/dts/rk3328-rock64.dts|  132 +-
> >  arch/arm/dts/rk3328.dtsi  | 1420 +++--
> >  arch/arm/mach-rockchip/rk3328/Kconfig |8 +
&

[PATCH 5/6] rockchip: dts: rk3328: Sync device tree files from Linux

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs rk3328 device tree files from the Linux kernel next-20200324.
The last commit to touch these files is:

b2411befed60 ("arm64: dts: add bus to rockchip amba nodenames")

Additional changes not yet in the Linux kernel include:

arm64: dts: rockchip: rk3328: drop #address-cells, #size-cells from grf node
arm64: dts: rockchip: rk3328: drop non-existent gmac2phy pinmux options
arm64: dts: rockchip: rk3328: Replace RK805 PMIC node name with "pmic"

Changes include:

  - conversion of raw pin numbers to macros
  - removal of deprecated RK_FUNC_* macros
  - update of device tree binding headers
  - new devices
  - device tree cleanups
  - gmac2phy disabled in -u-boot.dtsi as it is not supported in U-boot

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi |5 +
 arch/arm/dts/rk3328-evb.dts |  196 ++--
 arch/arm/dts/rk3328-rock64.dts  |  132 ++-
 arch/arm/dts/rk3328.dtsi| 1420 +--
 4 files changed, 1164 insertions(+), 589 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 8ba53cf8f44b..4bfa0c2330ba 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -40,6 +40,11 @@
status = "okay";
 };
 
+ {
+   /* Integrated PHY unsupported by U-boot */
+   status = "broken";
+};
+
 _host0_xhci {
vbus-supply = <_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index 97bef37cf610..6abc6f4a86cf 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -1,6 +1,6 @@
-// SPDX-License-Identifier: GPL-2.0+
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
 /*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
  */
 
 /dts-v1/;
@@ -11,24 +11,51 @@
compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
 
chosen {
-   stdout-path = 
+   stdout-path = "serial2:150n8";
};
 
-   vcc3v3_sdmmc: sdmmc-pwren {
+   dc_12v: dc-12v {
compatible = "regulator-fixed";
-   regulator-name = "vcc3v3";
-   gpio = < 30 GPIO_ACTIVE_LOW>;
+   regulator-name = "dc_12v";
regulator-always-on;
regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   pinctrl-names = "default";
+   pinctrl-0 = <_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 = < 18 GPIO_ACTIVE_LOW>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = < 30 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio>;
+   regulator-name = "vcc_sd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_io>;
};
 
-   vcc5v0_otg: vcc5v0-otg-drv {
+   vcc_sys: vcc-sys {
compatible = "regulator-fixed";
-   enable-active-high;
-   regulator-name = "vcc5v0_otg";
-   gpio = < 27 GPIO_ACTIVE_HIGH>;
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
+   vin-supply = <_12v>;
};
 
vcc_phy: vcc-phy-regulator {
@@ -39,80 +66,60 @@
};
 };
 
- {
-   status = "okay";
-};
-
- {
-   status = "okay";
-};
-
- {
-   bus-width = <4>;
-   cap-mmc-highspeed;
-   cap-sd-highspeed;
-   card-detect-delay = <200>;
-   disable-wp;
-   num-slots = <1>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_clk>, <_cmd>, <_dectn>, 
<_bus4>;
-   status = "okay";
+ {
+   cpu-supply = <_arm>;
 };
 
  {
bus-width = <8>;
cap-mmc-highspeed;
-   supports-emmc;
-   disable-wp;
non-removable;
-   num-slots = <1>;
pinctrl-names = "default";
pinctrl

[PATCH 2/6] rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The device tree file for rk3328-evb in the Linux kernel does not have
gmac2io enabled. Instead, gmac2phy is enabled, but that is not supported
in U-boot.

Move the gmac2io related nodes to rk3328-evb-u-boot.dtsi to preserve the
current functionality. When the device tree files are synced, gmac2phy
should be marked as "broken" in -u-boot.dtsi files.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi | 23 +++
 arch/arm/dts/rk3328-evb.dts | 23 ---
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 5679897279aa..8ba53cf8f44b 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -7,6 +7,13 @@
 #include "rk3328-sdram-ddr3-666.dtsi"
 
 /{
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
compatible = "regulator-fixed";
enable-active-high;
@@ -17,6 +24,22 @@
};
 };
 
+ {
+   phy-supply = <_phy>;
+   phy-mode = "rgmii";
+   clock_in_out = "input";
+   snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 5>;
+   assigned-clocks = < SCLK_MAC2IO>, < SCLK_MAC2IO_EXT>;
+   assigned-clock-parents = <_clkin>, <_clkin>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   tx_delay = <0x26>;
+   rx_delay = <0x11>;
+   status = "okay";
+};
+
 _host0_xhci {
vbus-supply = <_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index e9bc849f8c23..97bef37cf610 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -14,13 +14,6 @@
stdout-path = 
};
 
-   gmac_clkin: external-gmac-clock {
-   compatible = "fixed-clock";
-   clock-frequency = <12500>;
-   clock-output-names = "gmac_clkin";
-   #clock-cells = <0>;
-   };
-
vcc3v3_sdmmc: sdmmc-pwren {
compatible = "regulator-fixed";
regulator-name = "vcc3v3";
@@ -78,22 +71,6 @@
status = "okay";
 };
 
- {
-   phy-supply = <_phy>;
-   phy-mode = "rgmii";
-   clock_in_out = "input";
-   snps,reset-gpio = < RK_PC2 GPIO_ACTIVE_LOW>;
-   snps,reset-active-low;
-   snps,reset-delays-us = <0 1 5>;
-   assigned-clocks = < SCLK_MAC2IO>, < SCLK_MAC2IO_EXT>;
-   assigned-clock-parents = <_clkin>, <_clkin>;
-   pinctrl-names = "default";
-   pinctrl-0 = <_pins>;
-   tx_delay = <0x26>;
-   rx_delay = <0x11>;
-   status = "okay";
-};
-
 _host0_ehci {
status = "okay";
 };
-- 
2.25.1

[PATCH 0/6] rockchip: rk3328: sync dts and add ROC-RK3328-CC board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi everyone,

This series adds proper support for Firefly / Libre Computer ROC-RK3328-CC
single board computer.

The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
card size development board based on the Rockchip RK3328 SoC, with:

  - 1/2/4 GB DDR4 DRAM
  - eMMC connector for optional module
  - micro SD card slot
  - 1 x USB 3.0 host port
  - 2 x USB 2.0 host port
  - 1 x USB 2.0 OTG port
  - HDMI video output
  - TRRS connector with audio and composite video output
  - gigabit Ethernet
  - consumer IR receiver
  - debug UART pins

Originally I started with Loic's patches, and syncing the device tree
files from Linux. That didn't get very far, with SPL failing to detect
the SD card. Examining the schematics and internal state of GRF and
GPIOs, I realized that the logic for the SD card power enable switch
is opposite that of what the SD card controller's SDMMC0_PWREN pin
would use. Instead, directly using the GPIO is required.

Thus this series creates a special target for this board to handle
muxing this specific pin to GPIO state. The GPIO is left in input mode,
letting the external pull-down work its magic.

Along the way, there are some clean-ups of existing dts files, moving
U-boot only features to -u-boot.dtsi files, and then a wholesale sync
from Linux. Only boards already existing in U-boot are synced. DT
binding header files are synced separately as there is already one
patch floating around. The DT sync also includes clean-up changes only
recently posted, and likely won't make it in for at least a few weeks.

Please have a look, and test if possible. I cc-ed a couple people that
showed interest in this board on mailing lists recently.

Regards
ChenYu


Chen-Yu Tsai (6):
  rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi
  rockchip: dts: rk3328-evb: Move gmac2io related nodes to -u-boot.dtsi
  dt-bindings: clock: rk3328: sync from upstream Linux kernel
  dt-bindings: power: rk3328-power: sync from upstream Linux kernel
  rockchip: dts: rk3328: Sync device tree files from Linux
  rockchip: rk3328: Add support for ROC-RK3328-CC board

 arch/arm/dts/Makefile |1 +
 arch/arm/dts/rk3328-evb-u-boot.dtsi   |   39 +
 arch/arm/dts/rk3328-evb.dts   |  220 +--
 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi|   17 +
 .../{rk3328-rock64.dts => rk3328-roc-cc.dts}  |  135 +-
 arch/arm/dts/rk3328-rock64.dts|  132 +-
 arch/arm/dts/rk3328.dtsi  | 1420 +++--
 arch/arm/mach-rockchip/rk3328/Kconfig |8 +
 board/firefly/roc-cc-rk3328/Kconfig   |   24 +
 board/firefly/roc-cc-rk3328/MAINTAINERS   |7 +
 board/firefly/roc-cc-rk3328/Makefile  |1 +
 board/firefly/roc-cc-rk3328/board.c   |   38 +
 configs/roc-cc-rk3328_defconfig   |   97 ++
 doc/README.rockchip   |4 +-
 include/dt-bindings/clock/rk3328-cru.h|  212 +--
 include/dt-bindings/power/rk3328-power.h  |   19 +
 16 files changed, 1622 insertions(+), 752 deletions(-)
 create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
 copy arch/arm/dts/{rk3328-rock64.dts => rk3328-roc-cc.dts} (68%)
 create mode 100644 board/firefly/roc-cc-rk3328/Kconfig
 create mode 100644 board/firefly/roc-cc-rk3328/MAINTAINERS
 create mode 100644 board/firefly/roc-cc-rk3328/Makefile
 create mode 100644 board/firefly/roc-cc-rk3328/board.c
 create mode 100644 configs/roc-cc-rk3328_defconfig
 create mode 100644 include/dt-bindings/power/rk3328-power.h

-- 
2.25.1

[PATCH 3/6] dt-bindings: clock: rk3328: sync from upstream Linux kernel

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs the rk3328 clock header file from Linux kernel next-20200324,
to support newer hardware blocks when syncing the device tree files.

The last non-merge commit to touch it was

0dc14b013f79 ("clk: rockchip: add clock id for watchdog pclk on rk3328")

Signed-off-by: Chen-Yu Tsai 
---
 include/dt-bindings/clock/rk3328-cru.h | 212 -
 1 file changed, 106 insertions(+), 106 deletions(-)

diff --git a/include/dt-bindings/clock/rk3328-cru.h 
b/include/dt-bindings/clock/rk3328-cru.h
index cde61ed8830b..555b4ff660ae 100644
--- a/include/dt-bindings/clock/rk3328-cru.h
+++ b/include/dt-bindings/clock/rk3328-cru.h
@@ -1,6 +1,7 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
+/* SPDX-License-Identifier: GPL-2.0-or-later */
 /*
- * (C) Copyright 2016 Rockchip Electronics Co., Ltd
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Elaine 
  */
 
 #ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3328_H
@@ -90,119 +91,118 @@
 #define SCLK_MAC2IO_EXT102
 
 /* dclk gates */
-#define DCLK_LCDC  180
-#define DCLK_HDMIPHY   181
-#define HDMIPHY182
-#define USB480M183
-#define DCLK_LCDC_SRC  184
+#define DCLK_LCDC  120
+#define DCLK_HDMIPHY   121
+#define HDMIPHY122
+#define USB480M123
+#define DCLK_LCDC_SRC  124
 
 /* aclk gates */
-#define ACLK_AXISRAM   190
-#define ACLK_VOP_PRE   191
-#define ACLK_USB3OTG   192
-#define ACLK_RGA_PRE   193
-#define ACLK_DMAC  194
-#define ACLK_GPU   195
-#define ACLK_BUS_PRE   196
-#define ACLK_PERI_PRE  197
-#define ACLK_RKVDEC_PRE198
-#define ACLK_RKVDEC199
-#define ACLK_RKVENC200
-#define ACLK_VPU_PRE   201
-#define ACLK_VIO_PRE   202
-#define ACLK_VPU   203
-#define ACLK_VIO   204
-#define ACLK_VOP   205
-#define ACLK_GMAC  206
-#define ACLK_H265  207
-#define ACLK_H264  208
-#define ACLK_MAC2PHY   209
-#define ACLK_MAC2IO210
-#define ACLK_DCF   211
-#define ACLK_TSP   212
-#define ACLK_PERI  213
-#define ACLK_RGA   214
-#define ACLK_IEP   215
-#define ACLK_CIF   216
-#define ACLK_HDCP  217
+#define ACLK_AXISRAM   130
+#define ACLK_VOP_PRE   131
+#define ACLK_USB3OTG   132
+#define ACLK_RGA_PRE   133
+#define ACLK_DMAC  134
+#define ACLK_GPU   135
+#define ACLK_BUS_PRE   136
+#define ACLK_PERI_PRE  137
+#define ACLK_RKVDEC_PRE138
+#define ACLK_RKVDEC139
+#define ACLK_RKVENC140
+#define ACLK_VPU_PRE   141
+#define ACLK_VIO_PRE   142
+#define ACLK_VPU   143
+#define ACLK_VIO   144
+#define ACLK_VOP   145
+#define ACLK_GMAC  146
+#define ACLK_H265  147
+#define ACLK_H264  148
+#define ACLK_MAC2PHY   149
+#define ACLK_MAC2IO150
+#define ACLK_DCF   151
+#define ACLK_TSP   152
+#define ACLK_PERI  153
+#define ACLK_RGA   154
+#define ACLK_IEP   155
+#define ACLK_CIF   156
+#define ACLK_HDCP  157
 
 /* pclk gates */
-#define PCLK_GPIO0 300
-#define PCLK_GPIO1 301
-#define PCLK_GPIO2 302
-#define PCLK_GPIO3 303
-#define PCLK_GRF   304
-#define PCLK_I2C0  305
-#define PCLK_I2C1  306
-#define PCLK_I2C2  307
-#define PCLK_I2C3  308
-#define PCLK_SPI   309
-#define PCLK_UART0 310
-#define PCLK_UART1 311
-#define PCLK_UART2 312
-#define PCLK_TSADC 313
-#define PCLK_PWM   314
-#define PCLK_TIMER 315
-#define PCLK_BUS_PRE   316
-#define PCLK_PERI_PRE  317
-#define PCLK_HDMI_CTRL 318
-#define PCLK_HDMI_PHY  319
-#define PCLK_GMAC  320
-#define PCLK_H265  321
-#define PCLK_MAC2PHY   322
-#define PCLK_MAC2IO323
-#define PCLK_USB3PHY_OTG   324
-#define PCLK_USB3PHY_PIPE  325
-#define PCLK_USB3_GRF  326
-#define PCLK_USB2_GRF  327
-#define PCLK_HDMIPHY   328
-#define PCLK_DDR   329
-#define PCLK_PERI  330
-#define PCLK_HDMI  331
-#define PCLK_HDCP  332
-#define PCLK_DCF   333
-#define PCLK_SARADC334
+#define PCLK_GPIO0 200
+#define PCLK_GPIO1 201
+#define PCLK_GPIO2 202
+#define PCLK_GPIO3 203
+#define PCLK_GRF   204
+#define PCLK_I2C0  20

[PATCH 6/6] rockchip: rk3328: Add support for ROC-RK3328-CC board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The ROC-RK3328-CC from Firefly and Libre Computer Project is a credit
card size development board based on the Rockchip RK3328 SoC, with:

  - 1/2/4 GB DDR4 DRAM
  - eMMC connector for optional module
  - micro SD card slot
  - 1 x USB 3.0 host port
  - 2 x USB 2.0 host port
  - 1 x USB 2.0 OTG port
  - HDMI video output
  - TRRS connector with audio and composite video output
  - gigabit Ethernet
  - consumer IR receiver
  - debug UART pins

The ROC-RK3328-CC has the enable pin of the SD card power switch tied
to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
muxed by default. SDMMC0_PWREN is an active high signal controlled by
the MMC controller, however the switch enable is active low, and
pulled low (enabled) by default to make things work on boot.

As such, we need to mux away from SDMMC0_PWREN and use GPIO to enable
power to the card. The default GPIO state for the pin is pull-down and
input, which doesn't require extra configuration when paired with the
external pull-down and active low switch.

Thus we make a custom target for this board and do the muxing in its
spl_board_init() function.

The device tree file is synced from the Linux kernel next-20200324.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi  |  17 ++
 arch/arm/dts/rk3328-roc-cc.dts  | 354 
 arch/arm/mach-rockchip/rk3328/Kconfig   |   8 +
 board/firefly/roc-cc-rk3328/Kconfig |  24 ++
 board/firefly/roc-cc-rk3328/MAINTAINERS |   7 +
 board/firefly/roc-cc-rk3328/Makefile|   1 +
 board/firefly/roc-cc-rk3328/board.c |  38 +++
 configs/roc-cc-rk3328_defconfig |  97 +++
 doc/README.rockchip |   4 +-
 10 files changed, 550 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
 create mode 100644 arch/arm/dts/rk3328-roc-cc.dts
 create mode 100644 board/firefly/roc-cc-rk3328/Kconfig
 create mode 100644 board/firefly/roc-cc-rk3328/MAINTAINERS
 create mode 100644 board/firefly/roc-cc-rk3328/Makefile
 create mode 100644 board/firefly/roc-cc-rk3328/board.c
 create mode 100644 configs/roc-cc-rk3328_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9c593b2c986a..023cb010532d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -104,6 +104,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3308) += \
 
 dtb-$(CONFIG_ROCKCHIP_RK3328) += \
rk3328-evb.dtb \
+   rk3328-roc-cc.dtb \
rk3328-rock64.dtb
 
 dtb-$(CONFIG_ROCKCHIP_RK3368) += \
diff --git a/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi 
b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
new file mode 100644
index ..15b67f8bbdf4
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2018-2019 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-ddr4-666.dtsi"
+/ {
+   chosen {
+   u-boot,spl-boot-order = "same-as-spl", , 
+   };
+};
+
+_host0_xhci {
+   vbus-supply = <_host1_5v>;
+   status = "okay";
+};
diff --git a/arch/arm/dts/rk3328-roc-cc.dts b/arch/arm/dts/rk3328-roc-cc.dts
new file mode 100644
index ..8d553c92182a
--- /dev/null
+++ b/arch/arm/dts/rk3328-roc-cc.dts
@@ -0,0 +1,354 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 T-Chip Intelligent Technology Co., Ltd
+ */
+
+/dts-v1/;
+#include "rk3328.dtsi"
+
+/ {
+   model = "Firefly roc-rk3328-cc";
+   compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   gmac_clkin: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "gmac_clkin";
+   #clock-cells = <0>;
+   };
+
+   dc_12v: dc-12v {
+   compatible = "regulator-fixed";
+   regulator-name = "dc_12v";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio>;
+   regulator-boot-on;
+   regulator-name = "vcc_sd";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_io>;
+   };
+
+   vcc_sdio: sdmmcio-regulator {
+   compatible = &qu

[PATCH 1/6] rockchip: dts: rk3328-evb: Move vcc5v0-host-xhci-drv to -u-boot.dtsi

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

USB 3.0 is only supported in U-boot, not in the Linux kernel where the
device tree files are ultimately synced from. While the xhci node was
moved, the external vbus regulator was not.

Move it as well.

Fixes: 2e91e2025c1b ("rockchip: rk3328: migrate u-boot node to -u-boot.dtsi")
Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/rk3328-evb-u-boot.dtsi | 11 +++
 arch/arm/dts/rk3328-evb.dts |  9 -
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi 
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 4a827063c555..5679897279aa 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -6,6 +6,17 @@
 #include "rk3328-u-boot.dtsi"
 #include "rk3328-sdram-ddr3-666.dtsi"
 
+/{
+   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = < 0 GPIO_ACTIVE_HIGH>;
+   regulator-name = "vcc5v0_host_xhci";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   };
+};
+
 _host0_xhci {
vbus-supply = <_host_xhci>;
status = "okay";
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index a2ee838fcd6b..e9bc849f8c23 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -38,15 +38,6 @@
regulator-max-microvolt = <500>;
};
 
-   vcc5v0_host_xhci: vcc5v0-host-xhci-drv {
-   compatible = "regulator-fixed";
-   enable-active-high;
-   regulator-name = "vcc5v0_host_xhci";
-   gpio = < 0 GPIO_ACTIVE_HIGH>;
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   };
-
vcc_phy: vcc-phy-regulator {
compatible = "regulator-fixed";
regulator-name = "vcc_phy";
-- 
2.25.1

[PATCH 4/6] dt-bindings: power: rk3328-power: sync from upstream Linux kernel

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

This syncs the rk3328 power domain header file from Linux kernel
next-20200324, to support newer hardware blocks when syncing the
device tree files.

The last non-merge commit to touch it was

b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier to 
files with no license")

Signed-off-by: Chen-Yu Tsai 
---
 include/dt-bindings/power/rk3328-power.h | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 include/dt-bindings/power/rk3328-power.h

diff --git a/include/dt-bindings/power/rk3328-power.h 
b/include/dt-bindings/power/rk3328-power.h
new file mode 100644
index ..02e3d7fc1cce
--- /dev/null
+++ b/include/dt-bindings/power/rk3328-power.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __DT_BINDINGS_POWER_RK3328_POWER_H__
+#define __DT_BINDINGS_POWER_RK3328_POWER_H__
+
+/**
+ * RK3328 idle id Summary.
+ */
+#define RK3328_PD_CORE 0
+#define RK3328_PD_GPU  1
+#define RK3328_PD_BUS  2
+#define RK3328_PD_MSCH 3
+#define RK3328_PD_PERI 4
+#define RK3328_PD_VIDEO5
+#define RK3328_PD_HEVC 6
+#define RK3328_PD_SYS  7
+#define RK3328_PD_VPU  8
+#define RK3328_PD_VIO  9
+
+#endif
-- 
2.25.1

Re: [PATCH v1 0/2] Add roc-rk3328-cc support

[Chen-Yu Tsai]

Hi,

On Fri, Feb 28, 2020 at 1:47 AM Peter Geis  wrote:
>
> On Fri, Feb 14, 2020 at 9:47 AM Loic Devulder  wrote:
> >
> > This serie add support for roc-rk33239 board from Firefly/Libre
> > Computer:
> >   - add missing L2 cache entry in rk3328 dts
> >   - add roc-rk3328-cc board support
> >
> > With this we can successfully boot the board with mainline U-Boot and
> > binary blob firmwares. Boot with ATF and TPL/SPL partially works: TPL
> > works fine but SPL fails to find a bootable device.
>
> I have tpl/spl fully enabled on this device privately.
> The SPL fails to find a boot device when booted from the sdcard.
> It successfully boots from emmc though.
> I believe this is due to the 3.3/1.8 mode switch.

Actually this is due to no power being supplied to the card.

The SD card's VCC is driven by a switched regulator, which is controlled
by SDMMC0_PWREN, and is also pulled down externally. The enable line is
active low. The bootrom does not touch the line, but the MMC driver in
U-boot sets PWREN in the MMC controller, which I assume changes the state
of SDMMC0_PWREN.

My solution was to simply mux the pin over to GPIO, instead of being
controlled through the MMC controller, the latter being the default.
The GPIO default state is input, and so the external pull-down works
to keep the power enabled. This is done by creating spl_board_init()
especially for this board, so essentially creating another target.

I suppose the other way to do it is to enable a bunch of stuff such
as regulators and GPIO in SPL, and also do proper pinmuxing, i.e.
not throwing away pinctrl properties in the SPL device tree.

My work also includes syncing the rk3328 device tree files from the
Linux kernel, along with some cleanups. If Loic and Kever are OK with
another series, I can send it out.

Regards
ChenYu



> Have you tested off emmc with your patch?
>
> >
> > I didn't used the DTS from Linux kernel: USB2 fails in that case, this
> > should be corrected but maybe later?
> >
> > Note: sorry if this serie has been send twice, but I had issue with my
> > email server...
> >
> >
> > Loic Devulder (2):
> >   rockchip: rk3328: dts: add L2 cache entry
> >   rockchip: rk3328: add roc-rk3328-cc support
> >
> >  arch/arm/dts/Makefile  |   3 +-
> >  arch/arm/dts/rk3328-roc-cc-u-boot.dtsi |  16 ++
> >  arch/arm/dts/rk3328-roc-cc.dts | 260 +
> >  arch/arm/dts/rk3328.dtsi   |  25 ++-
> >  arch/arm/mach-rockchip/rk3328/Kconfig  |   1 -
> >  board/rockchip/evb_rk3328/MAINTAINERS  |   6 +
> >  configs/roc-cc-rk3328_defconfig|  95 +
> >  doc/README.rockchip|   9 +-
> >  8 files changed, 408 insertions(+), 7 deletions(-)
> >  create mode 100644 arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> >  create mode 100644 arch/arm/dts/rk3328-roc-cc.dts
> >  create mode 100644 configs/roc-cc-rk3328_defconfig
> >
> > --
> > 2.25.0
> >

Re: [PATCH] arch: arm: rockchip: order the rk3399 entries alphabetically

[Chen-Yu Tsai]

On Mon, Jan 20, 2020 at 7:06 PM Peter Robinson  wrote:
>
> On Mon, 20 Jan 2020, 10:08 Kever Yang,  wrote:
>
> > Hi Peter,
> >
> > On 2020/1/20 下午5:22, Peter Robinson wrote:
> > > On Mon, Jan 13, 2020 at 7:03 AM Kever Yang 
> > wrote:
> > >> Hi Peter,
> > >>
> > >> On 2020/1/8 上午11:56, Peter Robinson wrote:
> > >>> Put the target entries for rk3399 devices in alphabetical order.
> > >>>
> > >>> Signed-off-by: Peter Robinson 
> > >> Reviewed-by: Kever Yang 
> > > Any reason this didn't make the latest rockchip MR?
> >
> > This patch break the build for rk3399 boards other than chromebook_bob,
> >
> > and I have to leave it until other boards add CONFIG_TARGET_* to pass
> > the build.
> >
>
> How would it do that by simply reordering a kconfig file? I've tested it
> with at least building evm, rock960, rockpro64 and firefly 3399 builds with
> out issues.

AFAICT if the defconfig has no preferred setting, then the first entry
is used. The targets you tested likely all had a preferred setting, but
other ones such as the NanoPi M4 did not, and was counting on the EVB
target being the default.

ChenYu

Re: [PATCH 2/3] sunxi: Add Libre Computer ALL-H3-IT H5 board

[Chen-Yu Tsai]

On Fri, Jan 24, 2020 at 4:32 PM Chen-Yu Tsai  wrote:
>
> On Fri, Jan 24, 2020 at 2:24 PM Jagan Teki  wrote:
> >
> > On Tue, Jan 21, 2020 at 1:11 PM Chen-Yu Tsai  wrote:
> > >
> > > On Tue, Jan 21, 2020 at 3:29 PM Jagan Teki  
> > > wrote:
> > > >
> > > > On Sun, Jan 12, 2020 at 9:06 PM Chen-Yu Tsai  wrote:
> > > > >
> > > > > From: Chen-Yu Tsai 
> > > > >
> > > > > The Libre Computer ALL-H3-IT board is a small single board computer 
> > > > > that
> > > > > is roughly the same size as the Raspberry Pi Zero, or around 20% 
> > > > > smaller
> > > > > than a credit card.
> > > > >
> > > > > The board features:
> > > > >
> > > > >   - H2, H3, or H5 SoC from Allwinner
> > > > >   - 2 DDR3 DRAM chips
> > > > >   - Realtek RTL8821CU based WiFi module
> > > > >   - 128 Mbit SPI-NOR flash
> > > > >   - micro-SD card slot
> > > > >   - micro HDMI video output
> > > > >   - FPC connector for camera sensor module
> > > > >   - generic Raspberri-Pi style 40 pin GPIO header
> > > > >   - additional pin headers for extra USB host ports, ananlog audio and
> > > > > IR receiver
> > > > >
> > > > > Only H5 variant test samples were made available, but the vendor does
> > > > > have plans to include at least an H3 variant. Thus the device tree is
> > > > > split much like the ALL-H3-CC, with a common dtsi file for the board
> > > > > design, and separate dts files including the common board file and the
> > > > > SoC dtsi file. The other variants will be added as they are made
> > > > > available.
> > > > >
> > > > > The device tree was synced over from the Linux kernel, along with 
> > > > > other
> > > > > H3/H5 changes, in a previous patch. Thus only the defconfig and an 
> > > > > entry
> > > > > to the MAINTAINERS file is added.
> > > > >
> > > > > Signed-off-by: Chen-Yu Tsai 
> > > > > ---
> > > > >  board/sunxi/MAINTAINERS  |  5 +
> > > > >  configs/libretech_all_h3_it_h5_defconfig | 22 ++
> > > > >  2 files changed, 27 insertions(+)
> > > > >  create mode 100644 configs/libretech_all_h3_it_h5_defconfig
> > > > >
> > > > > diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> > > > > index 4a89bb0e7b7e..ed620ade766c 100644
> > > > > --- a/board/sunxi/MAINTAINERS
> > > > > +++ b/board/sunxi/MAINTAINERS
> > > > > @@ -318,6 +318,11 @@ F: configs/libretech_all_h3_cc_h2_plus_defconfig
> > > > >  F: configs/libretech_all_h3_cc_h3_defconfig
> > > > >  F: configs/libretech_all_h3_cc_h5_defconfig
> > > > >
> > > > > +LIBRETECH ALL-H3-IT BOARDS
> > > > > +M: Chen-Yu Tsai 
> > > > > +S: Maintained
> > > > > +F: configs/libretech_all_h3_it_h5_defconfig
> > > > > +
> > > > >  NANOPI-M1 BOARD
> > > > >  M: Mylène Josserand 
> > > > >  S: Maintained
> > > > > diff --git a/configs/libretech_all_h3_it_h5_defconfig 
> > > > > b/configs/libretech_all_h3_it_h5_defconfig
> > > > > new file mode 100644
> > > > > index ..df13f4a0d307
> > > > > --- /dev/null
> > > > > +++ b/configs/libretech_all_h3_it_h5_defconfig
> > > > > @@ -0,0 +1,22 @@
> > > > > +CONFIG_ARM=y
> > > > > +CONFIG_ARCH_SUNXI=y
> > > > > +CONFIG_NR_DRAM_BANKS=1
> > > > > +CONFIG_SPL=y
> > > > > +CONFIG_MACH_SUN50I_H5=y
> > > > > +CONFIG_DRAM_CLK=672
> > > > > +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> > > > > +CONFIG_SPL_SPI_SUNXI=y
> > > > > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > > > > +CONFIG_USE_PREBOOT=y
> > > > > +CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000
> > > > > +# CONFIG_SPL_DOS_PARTITION is not set
> > > > > +# CONFIG_SPL_EFI_PARTITION is not set
> > > > > +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-libretech-all-h3-it"
> > > > > +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > > > > +CONFIG_DM_SPI_FLASH=y
> > > &g

Re: Pull request: u-boot-rockchip-20200120

[Chen-Yu Tsai]

On Tue, Jan 28, 2020 at 2:32 AM Tom Rini  wrote:
>
> On Mon, Jan 27, 2020 at 11:25:16PM +0530, Jagan Teki wrote:
> > Hi Tom,
> >
> > On Thu, Jan 23, 2020 at 11:30 PM Tom Rini  wrote:
> > >
> > > On Mon, Jan 20, 2020 at 10:30:07AM +0800, Kever Yang wrote:
> > >
> > > > Hi Tom,
> > > >
> > > > Please pull the rockchip updates:
> > > > - Support SPI boot and redundant boot for rk3399
> > > > - Support binman for rockchip platform
> > > > - Update ram driver and add ddr4 support for rk3328
> > > >
> > > > Travis:
> > > > https://travis-ci.org/keveryang/u-boot/builds/639069624
> > > >
> > > > Thanks,
> > > > - Kever
> > > >
> > > > The following changes since commit 
> > > > d7bb6aceb2e99a832efbb96f9bf480bf95602192:
> > > >
> > > >   Merge tag 'mmc-1-16-2020' of 
> > > > https://gitlab.denx.de/u-boot/custodians/u-boot-mmc (2020-01-16 
> > > > 13:20:51 -0500)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > >   https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git 
> > > > tags/u-boot-rockchip-20200120
> > > >
> > > > for you to fetch changes up to f9a0f5b83e9eabf4d064c7ec46fe2f9b9b694b4e:
> > > >
> > > >   configs: firefly-rk3399: Enable CONFIG_MISC_INIT_R and ROCKCHIP_EFUSE 
> > > > (2020-01-19 15:19:03 +0800)
> > > >
> > >
> > > Per the details in the "distro_bootcmd: Add SF support" thread, I'm not
> > > taking this as the distro_bootcmd changes need to be dropped.  Thanks!
> >
> > Seems like Kever was Off for vacations or so, if possible maybe you
> > can drop below 'sf distro changes from PR'
> >
> >   distro_bootcmd: Add SF support
> >   rockchip: Include SF on distrocmd devices
> >   rk3399: Add boot flash script offet, size
>
> I will just wait for a new PR early in the -rc2 cycle to take care of
> outstanding rockchip changes.  Thanks.

It's Chinese New Year, with an extended vacation in China till this Sunday,
due to the coronavirus outbreak [1].

[1] https://www.bbc.com/news/world-asia-china-51259649

Re: [PATCH 2/3] sunxi: Add Libre Computer ALL-H3-IT H5 board

[Chen-Yu Tsai]

On Fri, Jan 24, 2020 at 2:24 PM Jagan Teki  wrote:
>
> On Tue, Jan 21, 2020 at 1:11 PM Chen-Yu Tsai  wrote:
> >
> > On Tue, Jan 21, 2020 at 3:29 PM Jagan Teki  
> > wrote:
> > >
> > > On Sun, Jan 12, 2020 at 9:06 PM Chen-Yu Tsai  wrote:
> > > >
> > > > From: Chen-Yu Tsai 
> > > >
> > > > The Libre Computer ALL-H3-IT board is a small single board computer that
> > > > is roughly the same size as the Raspberry Pi Zero, or around 20% smaller
> > > > than a credit card.
> > > >
> > > > The board features:
> > > >
> > > >   - H2, H3, or H5 SoC from Allwinner
> > > >   - 2 DDR3 DRAM chips
> > > >   - Realtek RTL8821CU based WiFi module
> > > >   - 128 Mbit SPI-NOR flash
> > > >   - micro-SD card slot
> > > >   - micro HDMI video output
> > > >   - FPC connector for camera sensor module
> > > >   - generic Raspberri-Pi style 40 pin GPIO header
> > > >   - additional pin headers for extra USB host ports, ananlog audio and
> > > > IR receiver
> > > >
> > > > Only H5 variant test samples were made available, but the vendor does
> > > > have plans to include at least an H3 variant. Thus the device tree is
> > > > split much like the ALL-H3-CC, with a common dtsi file for the board
> > > > design, and separate dts files including the common board file and the
> > > > SoC dtsi file. The other variants will be added as they are made
> > > > available.
> > > >
> > > > The device tree was synced over from the Linux kernel, along with other
> > > > H3/H5 changes, in a previous patch. Thus only the defconfig and an entry
> > > > to the MAINTAINERS file is added.
> > > >
> > > > Signed-off-by: Chen-Yu Tsai 
> > > > ---
> > > >  board/sunxi/MAINTAINERS  |  5 +
> > > >  configs/libretech_all_h3_it_h5_defconfig | 22 ++
> > > >  2 files changed, 27 insertions(+)
> > > >  create mode 100644 configs/libretech_all_h3_it_h5_defconfig
> > > >
> > > > diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> > > > index 4a89bb0e7b7e..ed620ade766c 100644
> > > > --- a/board/sunxi/MAINTAINERS
> > > > +++ b/board/sunxi/MAINTAINERS
> > > > @@ -318,6 +318,11 @@ F: configs/libretech_all_h3_cc_h2_plus_defconfig
> > > >  F: configs/libretech_all_h3_cc_h3_defconfig
> > > >  F: configs/libretech_all_h3_cc_h5_defconfig
> > > >
> > > > +LIBRETECH ALL-H3-IT BOARDS
> > > > +M: Chen-Yu Tsai 
> > > > +S: Maintained
> > > > +F: configs/libretech_all_h3_it_h5_defconfig
> > > > +
> > > >  NANOPI-M1 BOARD
> > > >  M: Mylène Josserand 
> > > >  S: Maintained
> > > > diff --git a/configs/libretech_all_h3_it_h5_defconfig 
> > > > b/configs/libretech_all_h3_it_h5_defconfig
> > > > new file mode 100644
> > > > index ..df13f4a0d307
> > > > --- /dev/null
> > > > +++ b/configs/libretech_all_h3_it_h5_defconfig
> > > > @@ -0,0 +1,22 @@
> > > > +CONFIG_ARM=y
> > > > +CONFIG_ARCH_SUNXI=y
> > > > +CONFIG_NR_DRAM_BANKS=1
> > > > +CONFIG_SPL=y
> > > > +CONFIG_MACH_SUN50I_H5=y
> > > > +CONFIG_DRAM_CLK=672
> > > > +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> > > > +CONFIG_SPL_SPI_SUNXI=y
> > > > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > > > +CONFIG_USE_PREBOOT=y
> > > > +CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000
> > > > +# CONFIG_SPL_DOS_PARTITION is not set
> > > > +# CONFIG_SPL_EFI_PARTITION is not set
> > > > +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-libretech-all-h3-it"
> > > > +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > > > +CONFIG_DM_SPI_FLASH=y
> > > > +CONFIG_SPI_FLASH_XMC=y
> > > > +CONFIG_SPI=y
> > > > +CONFIG_DM_SPI=y
> > >
> > > We just enable SPI_FLASH_XMC and rest we can add it via arch Kconfig?
> > > like A64 does.
> >
> > Are you referring to the rest of the SPI stuff?
>
> Yes.
>
> >
> > Only the more recent boards have SPI flash on board, so if we enable
> > it by default, we might end up with a whole bunch of boards disabling
> > it because they don't actually have SPI flash, and maybe don't want
> > the overhead.

Re: [PATCH 2/3] sunxi: Add Libre Computer ALL-H3-IT H5 board

[Chen-Yu Tsai]

On Tue, Jan 21, 2020 at 3:29 PM Jagan Teki  wrote:
>
> On Sun, Jan 12, 2020 at 9:06 PM Chen-Yu Tsai  wrote:
> >
> > From: Chen-Yu Tsai 
> >
> > The Libre Computer ALL-H3-IT board is a small single board computer that
> > is roughly the same size as the Raspberry Pi Zero, or around 20% smaller
> > than a credit card.
> >
> > The board features:
> >
> >   - H2, H3, or H5 SoC from Allwinner
> >   - 2 DDR3 DRAM chips
> >   - Realtek RTL8821CU based WiFi module
> >   - 128 Mbit SPI-NOR flash
> >   - micro-SD card slot
> >   - micro HDMI video output
> >   - FPC connector for camera sensor module
> >   - generic Raspberri-Pi style 40 pin GPIO header
> >   - additional pin headers for extra USB host ports, ananlog audio and
> > IR receiver
> >
> > Only H5 variant test samples were made available, but the vendor does
> > have plans to include at least an H3 variant. Thus the device tree is
> > split much like the ALL-H3-CC, with a common dtsi file for the board
> > design, and separate dts files including the common board file and the
> > SoC dtsi file. The other variants will be added as they are made
> > available.
> >
> > The device tree was synced over from the Linux kernel, along with other
> > H3/H5 changes, in a previous patch. Thus only the defconfig and an entry
> > to the MAINTAINERS file is added.
> >
> > Signed-off-by: Chen-Yu Tsai 
> > ---
> >  board/sunxi/MAINTAINERS  |  5 +
> >  configs/libretech_all_h3_it_h5_defconfig | 22 ++
> >  2 files changed, 27 insertions(+)
> >  create mode 100644 configs/libretech_all_h3_it_h5_defconfig
> >
> > diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
> > index 4a89bb0e7b7e..ed620ade766c 100644
> > --- a/board/sunxi/MAINTAINERS
> > +++ b/board/sunxi/MAINTAINERS
> > @@ -318,6 +318,11 @@ F: configs/libretech_all_h3_cc_h2_plus_defconfig
> >  F: configs/libretech_all_h3_cc_h3_defconfig
> >  F: configs/libretech_all_h3_cc_h5_defconfig
> >
> > +LIBRETECH ALL-H3-IT BOARDS
> > +M: Chen-Yu Tsai 
> > +S: Maintained
> > +F: configs/libretech_all_h3_it_h5_defconfig
> > +
> >  NANOPI-M1 BOARD
> >  M: Mylène Josserand 
> >  S: Maintained
> > diff --git a/configs/libretech_all_h3_it_h5_defconfig 
> > b/configs/libretech_all_h3_it_h5_defconfig
> > new file mode 100644
> > index ..df13f4a0d307
> > --- /dev/null
> > +++ b/configs/libretech_all_h3_it_h5_defconfig
> > @@ -0,0 +1,22 @@
> > +CONFIG_ARM=y
> > +CONFIG_ARCH_SUNXI=y
> > +CONFIG_NR_DRAM_BANKS=1
> > +CONFIG_SPL=y
> > +CONFIG_MACH_SUN50I_H5=y
> > +CONFIG_DRAM_CLK=672
> > +CONFIG_MMC_SUNXI_SLOT_EXTRA=2
> > +CONFIG_SPL_SPI_SUNXI=y
> > +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
> > +CONFIG_USE_PREBOOT=y
> > +CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000
> > +# CONFIG_SPL_DOS_PARTITION is not set
> > +# CONFIG_SPL_EFI_PARTITION is not set
> > +CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-libretech-all-h3-it"
> > +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > +CONFIG_DM_SPI_FLASH=y
> > +CONFIG_SPI_FLASH_XMC=y
> > +CONFIG_SPI=y
> > +CONFIG_DM_SPI=y
>
> We just enable SPI_FLASH_XMC and rest we can add it via arch Kconfig?
> like A64 does.

Are you referring to the rest of the SPI stuff?

Only the more recent boards have SPI flash on board, so if we enable
it by default, we might end up with a whole bunch of boards disabling
it because they don't actually have SPI flash, and maybe don't want
the overhead.

The rest of the generic stuff could be moved to Kconfig. DRAM_CLK
is probably not doable as the values vary a lot. NR_DRAM_BANKS yes.
SYS_SPI_U_BOOT_OFFS was already done I believe. Not sure about
some of the rest of the SPL settings.

ChenYu

Re: [PATCH 0/3] sunxi: Sync H3/H5 DT and add ALL-H3-IT and ALL-H5-CC

[Chen-Yu Tsai]

Hi Jagan,

On Sun, Jan 12, 2020 at 11:36 PM Chen-Yu Tsai  wrote:
>
> From: Chen-Yu Tsai 
>
> Hi everyone,
>
> This patch series syncs up the device tree files and header files for
> Allwinner H3/H5 SoCs and related boards to linux-next-20200108, and
> then adds support for Libre Computer ALL-H3-IT H5 and ALL-H5-CC H5
> boards.
>
> Patch 1 syncs up the device tree files and related device tree binding
> header files for the Allwinner H3 and H5 SoCs, and boards using these
> chips. These were compile tested.
>
> Patch 2 adds a defconfig and MAINTAINERS entry for the ALL-H3-IT's H5
> variant. Other variants will be added as they are made available.
>
> Patch 3 adds a defconfig and MAINTAINERS entry for the ALL-H5-CC's H5
> variant. Other variants will be added as they are made available.
>
> Please have a look.

One week left in the merge window. Any thoughts on this series?

Thanks
ChenYu

> Regards
> ChenYu
>
>
> Chen-Yu Tsai (3):
>   sunxi: H3/H5 Sync DT files from upstream Linux kernel as of
> next-20200108
>   sunxi: Add Libre Computer ALL-H3-IT H5 board
>   sunxi: Add Libre Computer ALL-H5-CC H5 board
>
>  arch/arm/dts/Makefile |   9 +-
>  .../dts/sun50i-h5-bananapi-m2-plus-v1.2.dts   |  11 ++
>  .../sun50i-h5-emlid-neutis-n5-devboard.dts| 137 ++---
>  arch/arm/dts/sun50i-h5-emlid-neutis-n5.dtsi   |  95 +
>  .../arm/dts/sun50i-h5-libretech-all-h3-cc.dts |  10 +-
>  .../arm/dts/sun50i-h5-libretech-all-h3-it.dts |  11 ++
>  .../arm/dts/sun50i-h5-libretech-all-h5-cc.dts |  61 ++
>  arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts   |  53 +
>  arch/arm/dts/sun50i-h5-nanopi-neo2.dts|  45 +
>  arch/arm/dts/sun50i-h5-orangepi-pc2.dts   |  47 +
>  arch/arm/dts/sun50i-h5-orangepi-prime.dts |  52 +
>  arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts |  11 +-
>  .../arm/dts/sun50i-h5-orangepi-zero-plus2.dts |  46 +
>  arch/arm/dts/sun50i-h5.dtsi   | 186 +-
>  .../dts/sun8i-h2-plus-bananapi-m2-zero.dts|  40 +++-
>  arch/arm/dts/sun8i-h2-plus-orangepi-r1.dts|   2 -
>  arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts  |  22 ++-
>  .../dts/sun8i-h3-bananapi-m2-plus-v1.2.dts|  13 ++
>  arch/arm/dts/sun8i-h3-beelink-x2.dts  |  11 +-
>  .../sun8i-h3-emlid-neutis-n5h3-devboard.dts   |  72 +++
>  arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi  |  11 ++
>  arch/arm/dts/sun8i-h3-mapleboard-mp130.dts| 152 ++
>  arch/arm/dts/sun8i-h3-nanopi-duo2.dts | 173 
>  arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts  |  28 ++-
>  arch/arm/dts/sun8i-h3-nanopi-m1.dts   |   2 +-
>  arch/arm/dts/sun8i-h3-nanopi-neo-air.dts  |   2 +-
>  arch/arm/dts/sun8i-h3-nanopi.dtsi |  25 +--
>  arch/arm/dts/sun8i-h3-orangepi-2.dts  |  34 +---
>  arch/arm/dts/sun8i-h3-orangepi-lite.dts   |  27 +--
>  arch/arm/dts/sun8i-h3-orangepi-one.dts|  28 +--
>  arch/arm/dts/sun8i-h3-orangepi-pc.dts |  27 +--
>  arch/arm/dts/sun8i-h3-orangepi-plus.dts   |  23 ++-
>  arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts |   2 +-
>  arch/arm/dts/sun8i-h3-rervision-dvk.dts   | 114 +++
>  arch/arm/dts/sun8i-h3.dtsi|  86 +++-
>  arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi |  30 +++
>  arch/arm/dts/sunxi-bananapi-m2-plus.dtsi  |   7 +-
>  arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi| 170 
>  arch/arm/dts/sunxi-h3-h5.dtsi | 137 -
>  arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi   |  65 +-
>  arch/arm/dts/sunxi-libretech-all-h3-it.dtsi   | 180 +
>  board/sunxi/MAINTAINERS   |  10 +
>  configs/libretech_all_h3_it_h5_defconfig  |  22 +++
>  configs/libretech_all_h5_cc_h5_defconfig  |  23 +++
>  include/dt-bindings/clock/sun8i-h3-ccu.h  |  11 +-
>  include/dt-bindings/reset/sun8i-h3-ccu.h  |   5 +-
>  46 files changed, 1605 insertions(+), 723 deletions(-)
>  create mode 100644 arch/arm/dts/sun50i-h5-bananapi-m2-plus-v1.2.dts
>  create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h3-it.dts
>  create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h5-cc.dts
>  create mode 100644 arch/arm/dts/sun8i-h3-bananapi-m2-plus-v1.2.dts
>  create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3-devboard.dts
>  create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi
>  create mode 100644 arch/arm/dts/sun8i-h3-mapleboard-mp130.dts
>  create mode 100644 arch/arm/dts/sun8i-h3-nanopi-duo2.dts
>  create mode 100644 arch/arm/dts/sun8i-h3-rervision-dvk.dts
>  create mode 100644 arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
>  create mode 100644 arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi
>  create mode 100644 arch/arm/dts/sunxi-libretech-all-h3-it.dtsi
>  create mode 100644 configs/libretech_all_h3_it_h5_defconfig
>  create mode 100644 configs/libretech_all_h5_cc_h5_defconfig
>
> --
> 2.24.1
>

[PATCH 1/3] sunxi: H3/H5 Sync DT files from upstream Linux kernel as of next-20200108

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Sync the device tree files and device tree header files from upstream
Linux kernel, as of 2020-01-08. The commit synced to in the sunxi repo

98d25b0b266d Merge branch 'sunxi/dt-for-5.6' into sunxi/for-next

which is also part of next-20200108.

Changes brought in include:

  - cleanup of pinmux node names
  - addition of Security ID, MBUS, CSI, crypto engine, video codec,
pmu, and thermal sensor device nodes for both SoCs
  - addition of deinterlacing engine device node on H3
  - cleanup of RTC device node and addition of its clocks
  - various board cleanups and improvements
- removal of pinmux node for GPIO lines
- cpufreq / DVFS
- HDMI output
- UART-based Bluetooth
- audio codec
- USB ports
  - new boards

Most of the changes don't concern U-boot.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/dts/Makefile |   9 +-
 .../dts/sun50i-h5-bananapi-m2-plus-v1.2.dts   |  11 ++
 .../sun50i-h5-emlid-neutis-n5-devboard.dts| 137 ++---
 arch/arm/dts/sun50i-h5-emlid-neutis-n5.dtsi   |  95 +
 .../arm/dts/sun50i-h5-libretech-all-h3-cc.dts |  10 +-
 .../arm/dts/sun50i-h5-libretech-all-h3-it.dts |  11 ++
 .../arm/dts/sun50i-h5-libretech-all-h5-cc.dts |  61 ++
 arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts   |  53 +
 arch/arm/dts/sun50i-h5-nanopi-neo2.dts|  45 +
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts   |  47 +
 arch/arm/dts/sun50i-h5-orangepi-prime.dts |  52 +
 arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts |  11 +-
 .../arm/dts/sun50i-h5-orangepi-zero-plus2.dts |  46 +
 arch/arm/dts/sun50i-h5.dtsi   | 186 +-
 .../dts/sun8i-h2-plus-bananapi-m2-zero.dts|  40 +++-
 arch/arm/dts/sun8i-h2-plus-orangepi-r1.dts|   2 -
 arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts  |  22 ++-
 .../dts/sun8i-h3-bananapi-m2-plus-v1.2.dts|  13 ++
 arch/arm/dts/sun8i-h3-beelink-x2.dts  |  11 +-
 .../sun8i-h3-emlid-neutis-n5h3-devboard.dts   |  72 +++
 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi  |  11 ++
 arch/arm/dts/sun8i-h3-mapleboard-mp130.dts| 152 ++
 arch/arm/dts/sun8i-h3-nanopi-duo2.dts | 173 
 arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts  |  28 ++-
 arch/arm/dts/sun8i-h3-nanopi-m1.dts   |   2 +-
 arch/arm/dts/sun8i-h3-nanopi-neo-air.dts  |   2 +-
 arch/arm/dts/sun8i-h3-nanopi.dtsi |  25 +--
 arch/arm/dts/sun8i-h3-orangepi-2.dts  |  34 +---
 arch/arm/dts/sun8i-h3-orangepi-lite.dts   |  27 +--
 arch/arm/dts/sun8i-h3-orangepi-one.dts|  28 +--
 arch/arm/dts/sun8i-h3-orangepi-pc.dts |  27 +--
 arch/arm/dts/sun8i-h3-orangepi-plus.dts   |  23 ++-
 arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts |   2 +-
 arch/arm/dts/sun8i-h3-rervision-dvk.dts   | 114 +++
 arch/arm/dts/sun8i-h3.dtsi|  86 +++-
 arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi |  30 +++
 arch/arm/dts/sunxi-bananapi-m2-plus.dtsi  |   7 +-
 arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi| 170 
 arch/arm/dts/sunxi-h3-h5.dtsi | 137 -
 arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi   |  65 +-
 arch/arm/dts/sunxi-libretech-all-h3-it.dtsi   | 180 +
 include/dt-bindings/clock/sun8i-h3-ccu.h  |  11 +-
 include/dt-bindings/reset/sun8i-h3-ccu.h  |   5 +-
 43 files changed, 1550 insertions(+), 723 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-h5-bananapi-m2-plus-v1.2.dts
 create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h3-it.dts
 create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h5-cc.dts
 create mode 100644 arch/arm/dts/sun8i-h3-bananapi-m2-plus-v1.2.dts
 create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3-devboard.dts
 create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi
 create mode 100644 arch/arm/dts/sun8i-h3-mapleboard-mp130.dts
 create mode 100644 arch/arm/dts/sun8i-h3-nanopi-duo2.dts
 create mode 100644 arch/arm/dts/sun8i-h3-rervision-dvk.dts
 create mode 100644 arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
 create mode 100644 arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi
 create mode 100644 arch/arm/dts/sunxi-libretech-all-h3-it.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 983e235f4427..b89ed48e9a4e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -513,8 +513,12 @@ dtb-$(CONFIG_MACH_SUN8I_H3) += \
sun8i-h2-plus-orangepi-r1.dtb \
sun8i-h2-plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
+   sun8i-h3-bananapi-m2-plus-v1.2.dtb \
sun8i-h3-beelink-x2.dtb \
+   sun8i-h3-emlid-neutis-n5h3-devboard.dtb \
sun8i-h3-libretech-all-h3-cc.dtb \
+   sun8i-h3-mapleboard-mp130.dtb \
+   sun8i-h3-nanopi-duo2.dtb \
sun8i-h3-nanopi-m1.dtb \
sun8i-h3-nanopi-m1-plus.dtb \
sun8i-h3-nanopi-neo.dtb \
@@ -526,7 +530,8 @@ dtb-$(CONFIG_MACH_SUN8I_H3

[PATCH 2/3] sunxi: Add Libre Computer ALL-H3-IT H5 board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The Libre Computer ALL-H3-IT board is a small single board computer that
is roughly the same size as the Raspberry Pi Zero, or around 20% smaller
than a credit card.

The board features:

  - H2, H3, or H5 SoC from Allwinner
  - 2 DDR3 DRAM chips
  - Realtek RTL8821CU based WiFi module
  - 128 Mbit SPI-NOR flash
  - micro-SD card slot
  - micro HDMI video output
  - FPC connector for camera sensor module
  - generic Raspberri-Pi style 40 pin GPIO header
  - additional pin headers for extra USB host ports, ananlog audio and
IR receiver

Only H5 variant test samples were made available, but the vendor does
have plans to include at least an H3 variant. Thus the device tree is
split much like the ALL-H3-CC, with a common dtsi file for the board
design, and separate dts files including the common board file and the
SoC dtsi file. The other variants will be added as they are made
available.

The device tree was synced over from the Linux kernel, along with other
H3/H5 changes, in a previous patch. Thus only the defconfig and an entry
to the MAINTAINERS file is added.

Signed-off-by: Chen-Yu Tsai 
---
 board/sunxi/MAINTAINERS  |  5 +
 configs/libretech_all_h3_it_h5_defconfig | 22 ++
 2 files changed, 27 insertions(+)
 create mode 100644 configs/libretech_all_h3_it_h5_defconfig

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 4a89bb0e7b7e..ed620ade766c 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -318,6 +318,11 @@ F: configs/libretech_all_h3_cc_h2_plus_defconfig
 F: configs/libretech_all_h3_cc_h3_defconfig
 F: configs/libretech_all_h3_cc_h5_defconfig
 
+LIBRETECH ALL-H3-IT BOARDS
+M: Chen-Yu Tsai 
+S: Maintained
+F: configs/libretech_all_h3_it_h5_defconfig
+
 NANOPI-M1 BOARD
 M: Mylène Josserand 
 S: Maintained
diff --git a/configs/libretech_all_h3_it_h5_defconfig 
b/configs/libretech_all_h3_it_h5_defconfig
new file mode 100644
index ..df13f4a0d307
--- /dev/null
+++ b/configs/libretech_all_h3_it_h5_defconfig
@@ -0,0 +1,22 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL=y
+CONFIG_MACH_SUN50I_H5=y
+CONFIG_DRAM_CLK=672
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+CONFIG_SPL_SPI_SUNXI=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_USE_PREBOOT=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-libretech-all-h3-it"
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_XMC=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
-- 
2.24.1

[PATCH 3/3] sunxi: Add Libre Computer ALL-H5-CC H5 board

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The Libre Computer ALL-H5-CC board is an upgraded version of the
ALL-H3-CC. Changes include:

  - Gigabit Ethernet via external RTL8211E Ethernet PHY
  - 16 MiB SPI NOR flash memory
  - PoE tap header
  - Line out jack removed

Only H5 variant test samples were made available, and the vendor is not
certain whether other SoC variants would be made or not. Furthermore the
board is a minor upgrade compared to the ALL-H3-CC. Thus the device tree
simply includes the one for the ALL-H3-CC, and adds the changes on top.

The device tree was synced over from the Linux kernel, along with other
H3/H5 changes, in a previous patch. Thus only the defconfig and an entry
to the MAINTAINERS file is added.

Signed-off-by: Chen-Yu Tsai 
---
 board/sunxi/MAINTAINERS  |  5 +
 configs/libretech_all_h5_cc_h5_defconfig | 23 +++
 2 files changed, 28 insertions(+)
 create mode 100644 configs/libretech_all_h5_cc_h5_defconfig

diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index ed620ade766c..1180b86db3ba 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -323,6 +323,11 @@ M: Chen-Yu Tsai 
 S: Maintained
 F: configs/libretech_all_h3_it_h5_defconfig
 
+LIBRETECH ALL-H5-CC BOARDS
+M: Chen-Yu Tsai 
+S: Maintained
+F: configs/libretech_all_h5_cc_h5_defconfig
+
 NANOPI-M1 BOARD
 M: Mylène Josserand 
 S: Maintained
diff --git a/configs/libretech_all_h5_cc_h5_defconfig 
b/configs/libretech_all_h5_cc_h5_defconfig
new file mode 100644
index ..97a1b6ddae39
--- /dev/null
+++ b/configs/libretech_all_h5_cc_h5_defconfig
@@ -0,0 +1,23 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL=y
+CONFIG_MACH_SUN50I_H5=y
+CONFIG_DRAM_CLK=672
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+CONFIG_SPL_SPI_SUNXI=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_USE_PREBOOT=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-h5-libretech-all-h5-cc"
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_DM_SPI_FLASH=y
+CONFIG_SPI_FLASH_XMC=y
+CONFIG_SUN8I_EMAC=y
+CONFIG_SPI=y
+CONFIG_DM_SPI=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
-- 
2.24.1

[PATCH 0/3] sunxi: Sync H3/H5 DT and add ALL-H3-IT and ALL-H5-CC

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi everyone,

This patch series syncs up the device tree files and header files for
Allwinner H3/H5 SoCs and related boards to linux-next-20200108, and
then adds support for Libre Computer ALL-H3-IT H5 and ALL-H5-CC H5
boards.

Patch 1 syncs up the device tree files and related device tree binding
header files for the Allwinner H3 and H5 SoCs, and boards using these
chips. These were compile tested.

Patch 2 adds a defconfig and MAINTAINERS entry for the ALL-H3-IT's H5
variant. Other variants will be added as they are made available.

Patch 3 adds a defconfig and MAINTAINERS entry for the ALL-H5-CC's H5
variant. Other variants will be added as they are made available.

Please have a look.


Regards
ChenYu


Chen-Yu Tsai (3):
  sunxi: H3/H5 Sync DT files from upstream Linux kernel as of
next-20200108
  sunxi: Add Libre Computer ALL-H3-IT H5 board
  sunxi: Add Libre Computer ALL-H5-CC H5 board

 arch/arm/dts/Makefile |   9 +-
 .../dts/sun50i-h5-bananapi-m2-plus-v1.2.dts   |  11 ++
 .../sun50i-h5-emlid-neutis-n5-devboard.dts| 137 ++---
 arch/arm/dts/sun50i-h5-emlid-neutis-n5.dtsi   |  95 +
 .../arm/dts/sun50i-h5-libretech-all-h3-cc.dts |  10 +-
 .../arm/dts/sun50i-h5-libretech-all-h3-it.dts |  11 ++
 .../arm/dts/sun50i-h5-libretech-all-h5-cc.dts |  61 ++
 arch/arm/dts/sun50i-h5-nanopi-neo-plus2.dts   |  53 +
 arch/arm/dts/sun50i-h5-nanopi-neo2.dts|  45 +
 arch/arm/dts/sun50i-h5-orangepi-pc2.dts   |  47 +
 arch/arm/dts/sun50i-h5-orangepi-prime.dts |  52 +
 arch/arm/dts/sun50i-h5-orangepi-zero-plus.dts |  11 +-
 .../arm/dts/sun50i-h5-orangepi-zero-plus2.dts |  46 +
 arch/arm/dts/sun50i-h5.dtsi   | 186 +-
 .../dts/sun8i-h2-plus-bananapi-m2-zero.dts|  40 +++-
 arch/arm/dts/sun8i-h2-plus-orangepi-r1.dts|   2 -
 arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts  |  22 ++-
 .../dts/sun8i-h3-bananapi-m2-plus-v1.2.dts|  13 ++
 arch/arm/dts/sun8i-h3-beelink-x2.dts  |  11 +-
 .../sun8i-h3-emlid-neutis-n5h3-devboard.dts   |  72 +++
 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi  |  11 ++
 arch/arm/dts/sun8i-h3-mapleboard-mp130.dts| 152 ++
 arch/arm/dts/sun8i-h3-nanopi-duo2.dts | 173 
 arch/arm/dts/sun8i-h3-nanopi-m1-plus.dts  |  28 ++-
 arch/arm/dts/sun8i-h3-nanopi-m1.dts   |   2 +-
 arch/arm/dts/sun8i-h3-nanopi-neo-air.dts  |   2 +-
 arch/arm/dts/sun8i-h3-nanopi.dtsi |  25 +--
 arch/arm/dts/sun8i-h3-orangepi-2.dts  |  34 +---
 arch/arm/dts/sun8i-h3-orangepi-lite.dts   |  27 +--
 arch/arm/dts/sun8i-h3-orangepi-one.dts|  28 +--
 arch/arm/dts/sun8i-h3-orangepi-pc.dts |  27 +--
 arch/arm/dts/sun8i-h3-orangepi-plus.dts   |  23 ++-
 arch/arm/dts/sun8i-h3-orangepi-zero-plus2.dts |   2 +-
 arch/arm/dts/sun8i-h3-rervision-dvk.dts   | 114 +++
 arch/arm/dts/sun8i-h3.dtsi|  86 +++-
 arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi |  30 +++
 arch/arm/dts/sunxi-bananapi-m2-plus.dtsi  |   7 +-
 arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi| 170 
 arch/arm/dts/sunxi-h3-h5.dtsi | 137 -
 arch/arm/dts/sunxi-libretech-all-h3-cc.dtsi   |  65 +-
 arch/arm/dts/sunxi-libretech-all-h3-it.dtsi   | 180 +
 board/sunxi/MAINTAINERS   |  10 +
 configs/libretech_all_h3_it_h5_defconfig  |  22 +++
 configs/libretech_all_h5_cc_h5_defconfig  |  23 +++
 include/dt-bindings/clock/sun8i-h3-ccu.h  |  11 +-
 include/dt-bindings/reset/sun8i-h3-ccu.h  |   5 +-
 46 files changed, 1605 insertions(+), 723 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-h5-bananapi-m2-plus-v1.2.dts
 create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h3-it.dts
 create mode 100644 arch/arm/dts/sun50i-h5-libretech-all-h5-cc.dts
 create mode 100644 arch/arm/dts/sun8i-h3-bananapi-m2-plus-v1.2.dts
 create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3-devboard.dts
 create mode 100644 arch/arm/dts/sun8i-h3-emlid-neutis-n5h3.dtsi
 create mode 100644 arch/arm/dts/sun8i-h3-mapleboard-mp130.dts
 create mode 100644 arch/arm/dts/sun8i-h3-nanopi-duo2.dts
 create mode 100644 arch/arm/dts/sun8i-h3-rervision-dvk.dts
 create mode 100644 arch/arm/dts/sunxi-bananapi-m2-plus-v1.2.dtsi
 create mode 100644 arch/arm/dts/sunxi-h3-h5-emlid-neutis.dtsi
 create mode 100644 arch/arm/dts/sunxi-libretech-all-h3-it.dtsi
 create mode 100644 configs/libretech_all_h3_it_h5_defconfig
 create mode 100644 configs/libretech_all_h5_cc_h5_defconfig

-- 
2.24.1

Re: SUNXI : CONFIG_VIDEO_SUNXI is never set

[Chen-Yu Tsai]

On Sun, Dec 22, 2019 at 10:07 PM Arjan van Vught
 wrote:
>
>
>
> > Op 10 mrt. 2019, om 20:18 heeft Arjan van Vught  
> > het volgende geschreven:
> >
> >
> >
> >> Op 7 mrt. 2019, om 09:04 heeft Chen-Yu Tsai  het volgende 
> >> geschreven:
> >>
> >> On Fri, Mar 1, 2019 at 11:36 PM Arjan van Vught
> >>  wrote:
> >>>
> >>> Version: u-boot-2018.09
> >>>
> >>> This is a follow-up for : "SUNXI : setenv video-mode not working"
> >>>
> >>> Although I have added CONFIG_VIDEO_SUNXI=y in 
> >>> configs/orangepi_one_defconfig
> >>>
> >>> the source file sunxi_display.c is not compiled. Hence the setenv
> >>> video-mode is not working ?
> >>
> >> That file is only used for DE 1.0, while the H3, which the Orange Pi
> >> One is based
> >> on, has DE 2.0.
> > Is it on the roadmap adding support for DE 2.0 ?
>
> Hi ChenYu, any updates for this issue ? Thanks, Arjan

You are asking the wrong person.

Re: [PATCH 5/5] arm64: dts: meson: add libretech-pc support

[Chen-Yu Tsai]

On Fri, Dec 20, 2019 at 2:37 AM Jerome Brunet  wrote:
>
> Add support for the Amlogic based libretech-pc platform.
> This platform comes with 2 variant, based on the s905d or s912 SoC.
>
> Signed-off-by: Jerome Brunet 
> ---
>  arch/arm/dts/Makefile |   2 +
>  arch/arm/dts/meson-gx-libretech-pc.dtsi   | 376 ++
>  .../meson-gxl-s905d-libretech-pc-u-boot.dtsi  |   7 +
>  arch/arm/dts/meson-gxl-s905d-libretech-pc.dts |  17 +
>  arch/arm/dts/meson-gxl-s905d.dtsi |  12 +
>  arch/arm/dts/meson-gxl.dtsi   |  35 +-
>  .../meson-gxm-s912-libretech-pc-u-boot.dtsi   |   7 +
>  arch/arm/dts/meson-gxm-s912-libretech-pc.dts  |  62 +++
>  configs/libretech-s905d-pc_defconfig  |  73 
>  configs/libretech-s912-pc_defconfig   |  73 
>  10 files changed, 654 insertions(+), 10 deletions(-)
>  create mode 100644 arch/arm/dts/meson-gx-libretech-pc.dtsi
>  create mode 100644 arch/arm/dts/meson-gxl-s905d-libretech-pc-u-boot.dtsi
>  create mode 100644 arch/arm/dts/meson-gxl-s905d-libretech-pc.dts
>  create mode 100644 arch/arm/dts/meson-gxl-s905d.dtsi
>  create mode 100644 arch/arm/dts/meson-gxm-s912-libretech-pc-u-boot.dtsi
>  create mode 100644 arch/arm/dts/meson-gxm-s912-libretech-pc.dts
>  create mode 100644 configs/libretech-s905d-pc_defconfig
>  create mode 100644 configs/libretech-s912-pc_defconfig

May I suggest including the actual model name "AML-S912-PC" in the
file names? That will make it that much more obvious what these files
are for, instead of "libretech-pc" which few people have heard of.

So something like "meson-libretech-aml-s912-pc.dtsi",
"meson-gxl-s905d-libretech-aml-s912-pc.dts",
"meson-gxm-s912-libretech-aml-s912-pc.dts",
"libretech-aml-s912-pc-s905d_defconfig", and
"libretech-aml-s912-pc-s912_defconfig".

Same goes for the Linux copy.

ChenYu

Re: [U-Boot] [PATCH 4/4] sunxi: board: fixup the BT address for Orange Pi 3

[Chen-Yu Tsai]

On Fri, Nov 22, 2019 at 9:05 PM Andre Heider  wrote:
>
> The BCM4345C5 of the Orange Pi 3 ships with the controller default
> address. Fix it up so it can function properly.
>
> The used address is "ethaddr" with the LSB flipped.
>
> Signed-off-by: Andre Heider 
> ---
>
> NOTE:
>  "local-bd-address" is a universal property, the kernel patch for
>  btbcm to use that is in bluetooth-next.
>
>  board/sunxi/board.c | 28 
>  1 file changed, 28 insertions(+)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index bb35d6b66e..2897bf45e1 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -856,6 +856,32 @@ int misc_init_r(void)
> return 0;
>  }
>
> +static void fixup_bd_address(void *blob)
> +{
> +#if defined(CONFIG_MACH_SUN50I_H6)
> +   /* Some devices ship with the controller default address.
> +* Set a valid address through the device tree.
> +*/
> +   uchar mac[ETH_ALEN], bdaddr[ETH_ALEN];
> +   int i;
> +
> +   if (!of_machine_is_compatible("xunlong,orangepi-3"))
> +   return;
> +
> +   if (!eth_env_get_enetaddr("ethaddr", mac))
> +   return;
> +
> +   /* Addresses need to be in the binary format of the corresponding 
> stack */
> +   for (i = 0; i < ETH_ALEN; ++i)
> +   bdaddr[i] = mac[ETH_ALEN - i - 1];
> +
> +   bdaddr[0] ^= 1;

IIRC someone mentioned before that unlike Ethernet and WiFi,
Bluetooth does not have a "locally administered" address space,
so any address used could possibly collide with other devices.

ChenYu


> +
> +   do_fixup_by_compat(blob, "brcm,bcm4345c5",
> +  "local-bd-address", bdaddr, ETH_ALEN, 1);
> +#endif
> +}
> +
>  int ft_board_setup(void *blob, bd_t *bd)
>  {
> int __maybe_unused r;
> @@ -866,6 +892,8 @@ int ft_board_setup(void *blob, bd_t *bd)
>  */
> setup_environment(blob);
>
> +   fixup_bd_address(blob);
> +
>  #ifdef CONFIG_VIDEO_DT_SIMPLEFB
> r = sunxi_simplefb_setup(blob);
> if (r)
> --
> 2.24.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] rockchip: rk3328: enable DMA for MMCs at Rock64

[Chen-Yu Tsai]

On Mon, Aug 5, 2019 at 8:54 PM Kever Yang  wrote:
>
>
> On 2019/7/29 下午5:18, Matwey V. Kornilov wrote:
> > DMA for MMCs can be enabled, since the previous patch fixes
> > the following issue in SPL:
> >
> >  Trying to boot from MMC1
> >  spl: mmc init failed with error: -110
> >  SPL: failed to boot from all boot devices
> >  ### ERROR ### Please RESET the board ###
> >
> > Signed-off-by: Matwey V. Kornilov 
>
> Reviewed-by: Kever Yang 

Tested-by: Chen-Yu Tsai 

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

Re: [U-Boot] [PATCH 1/2] rockchip: rk3328: set DDR as non-secure in SPL

[Chen-Yu Tsai]

On Mon, Aug 5, 2019 at 8:54 PM Kever Yang  wrote:
>
>
> On 2019/7/29 下午5:18, Matwey V. Kornilov wrote:
> > From: Kever Yang 
> >
> > Set DDR as non-secure so that MMC DMA can access.
> >
> > Signed-off-by: Kever Yang 
> > [cherry picked from 
> > https://github.com/rockchip-linux/u-boot/commit/bfe741ab9eb4f97371a4e6c24185419d57a3a75f
> >  and 
> > https://github.com/rockchip-linux/u-boot/commit/73d952acc8cc1ddad6652ba71895d9fe928c1e4b
> >  with minor modifications]
> > Signed-off-by: Matwey V. Kornilov 
>
> Reviewed-by: Kever Yang 

Tested-by: Chen-Yu Tsai 

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

Re: [U-Boot] [PATCH v2 0/7] Add TPL support for Pine64 Rock64 board.

[Chen-Yu Tsai]

On Fri, Aug 2, 2019 at 6:55 PM Matwey V. Kornilov
 wrote:
>
> пт, 2 авг. 2019 г. в 13:41, Chen-Yu Tsai :
> >
> > On Fri, Aug 2, 2019 at 3:40 PM Matwey V. Kornilov
> >  wrote:
> > >
> > > This series adds initial TPL support for Pine64 Rock64 board.
> > >
> > > The ROCK64 is a credit card size SBC based on Rockchip RK3328 Quad-Core 
> > > ARM Cortex A53.
> > >
> > > The series has been tested with ATF v2.1.
> > >
> > > Some patches in the series are taken from 
> > > https://github.com/rockchip-linux/u-boot
> > > Credits are given in each patch separately.
> > >
> > > Changes since v1:
> > >  - Added commit message in patch 6
> > >  - Split config to rk3328/Kconfig in patch 4
> > >  - Introduced rk3328-evb-u-boot.dtsi to collect u-boot specific dts 
> > > configs
> > >
> > > Kever Yang (4):
> > >   rockchip: ram: add full feature rk3328 DRAM driver
> > >   rockchip: dts: rk3328: update dmc node for driver
> > >   rockchip: Kconfig: enable TPL support for rk3328
> > >   rockchip: evb-rk3328: enable defconfig options for TPL/SPL
> > >
> > > Matwey V. Kornilov (3):
> > >   rockchip: dts: rk3328: Add rk3328-evb-u-boot.dtsi
> > >   configs: rk3328: enable TPL for rock64-rk3328_defconfig
> > >   doc: rockchip: Adapt Pine64 Rock64 board instructions
> > >
> > >  arch/arm/dts/rk3328-evb-u-boot.dtsi   |   33 +
> > >  arch/arm/dts/rk3328-rock64-u-boot.dtsi|2 +
> > >  arch/arm/dts/rk3328-sdram-ddr3-666.dtsi   |  215 +
> > >  arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi|  215 +
> > >  arch/arm/dts/rk3328-sdram-lpddr3-666.dtsi |  215 +
> > >  arch/arm/dts/rk3328.dtsi  |   11 +-
> > >  arch/arm/include/asm/arch-rockchip/sdram_rk3328.h |  441 +
> > >  arch/arm/mach-rockchip/Kconfig|5 +
> > >  arch/arm/mach-rockchip/rk3328/Kconfig |   12 +
> > >  configs/evb-rk3328_defconfig  |   37 +-
> > >  configs/rock64-rk3328_defconfig   |   14 +
> > >  doc/README.rockchip   |   10 +-
> > >  drivers/ram/rockchip/sdram_rk3328.c   | 1018 
> > > -
> > >  13 files changed, 2212 insertions(+), 16 deletions(-)
> > >  create mode 100644 arch/arm/dts/rk3328-evb-u-boot.dtsi
> > >  create mode 100644 arch/arm/dts/rk3328-sdram-ddr3-666.dtsi
> > >  create mode 100644 arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi
> > >  create mode 100644 arch/arm/dts/rk3328-sdram-lpddr3-666.dtsi
> > >  create mode 100644 arch/arm/include/asm/arch-rockchip/sdram_rk3328.h
> >
> > Tested-by: Chen-Yu Tsai 
> >
> > It correctly boots up to a U-boot prompt on my Rock64. However it
> > fails to read data correctly from the SD card afterwards:
> >
> > U-Boot TPL 2019.10-rc1-00072-gaf0ea60e1a42 (Aug 02 2019 - 18:10:38)
> > LPDDR3
> > Trying to boot from BOOTROM
> > Returning to boot ROM...
> >
> > U-Boot SPL 2019.10-rc1-00072-gaf0ea60e1a42 (Aug 02 2019 - 18:10:38 +0800)
> > Trying to boot from MMC2
> > Card did not respond to voltage select!
> > spl: mmc init failed with error: -95
> > Trying to boot from MMC1
> > NOTICE:  BL31: v2.1(release):v2.1-531-g3ee48f40f
> > NOTICE:  BL31: Built : 17:09:50, Aug  2 2019
> > ERROR:   over or zero region, nr=4187640, max=10
> > NOTICE:  BL31:Rockchip release version: v1.2
> >
> >
> > U-Boot 2019.10-rc1-00072-gaf0ea60e1a42 (Aug 02 2019 - 18:11:02 +0800)
> >
> > Model: Pine64 Rock64
> > DRAM:  4 GiB
> > MMC:   rksdmmc@ff50: 1, rksdmmc@ff52: 0
> > Loading Environment from MMC... *** Warning - bad CRC, using default 
> > environment
> >
> > In:serial@ff13
> > Out:   serial@ff13
> > Err:   serial@ff13
> > Model: Pine64 Rock64
> > Net:
> > Warning: ethernet@ff54 (eth0) using random MAC address - 
> > 7e:ba:fc:e6:98:1f
> > eth0: ethernet@ff54
> > Hit any key to stop autoboot:  0
> > Card did not respond to voltage select!
> > switch to partitions #0, OK
> > mmc1 is current device
> > Scanning mmc 1:1...
> > Found U-Boot script /boot/boot.scr
> > 588 bytes read in 13 ms (43.9 KiB/s)
> > ## Executing script at 0050
> >  ** fs_devread read error - block
> > ** No partition table - mmc 1 **
> > ** No partition table - mmc 1 **
> 

Re: [U-Boot] [PATCH v2 0/7] Add TPL support for Pine64 Rock64 board.

[Chen-Yu Tsai]

On Fri, Aug 2, 2019 at 3:40 PM Matwey V. Kornilov
 wrote:
>
> This series adds initial TPL support for Pine64 Rock64 board.
>
> The ROCK64 is a credit card size SBC based on Rockchip RK3328 Quad-Core ARM 
> Cortex A53.
>
> The series has been tested with ATF v2.1.
>
> Some patches in the series are taken from 
> https://github.com/rockchip-linux/u-boot
> Credits are given in each patch separately.
>
> Changes since v1:
>  - Added commit message in patch 6
>  - Split config to rk3328/Kconfig in patch 4
>  - Introduced rk3328-evb-u-boot.dtsi to collect u-boot specific dts configs
>
> Kever Yang (4):
>   rockchip: ram: add full feature rk3328 DRAM driver
>   rockchip: dts: rk3328: update dmc node for driver
>   rockchip: Kconfig: enable TPL support for rk3328
>   rockchip: evb-rk3328: enable defconfig options for TPL/SPL
>
> Matwey V. Kornilov (3):
>   rockchip: dts: rk3328: Add rk3328-evb-u-boot.dtsi
>   configs: rk3328: enable TPL for rock64-rk3328_defconfig
>   doc: rockchip: Adapt Pine64 Rock64 board instructions
>
>  arch/arm/dts/rk3328-evb-u-boot.dtsi   |   33 +
>  arch/arm/dts/rk3328-rock64-u-boot.dtsi|2 +
>  arch/arm/dts/rk3328-sdram-ddr3-666.dtsi   |  215 +
>  arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi|  215 +
>  arch/arm/dts/rk3328-sdram-lpddr3-666.dtsi |  215 +
>  arch/arm/dts/rk3328.dtsi  |   11 +-
>  arch/arm/include/asm/arch-rockchip/sdram_rk3328.h |  441 +
>  arch/arm/mach-rockchip/Kconfig|5 +
>  arch/arm/mach-rockchip/rk3328/Kconfig |   12 +
>  configs/evb-rk3328_defconfig  |   37 +-
>  configs/rock64-rk3328_defconfig   |   14 +
>  doc/README.rockchip   |   10 +-
>  drivers/ram/rockchip/sdram_rk3328.c   | 1018 
> -
>  13 files changed, 2212 insertions(+), 16 deletions(-)
>  create mode 100644 arch/arm/dts/rk3328-evb-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3328-sdram-ddr3-666.dtsi
>  create mode 100644 arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi
>  create mode 100644 arch/arm/dts/rk3328-sdram-lpddr3-666.dtsi
>  create mode 100644 arch/arm/include/asm/arch-rockchip/sdram_rk3328.h

Tested-by: Chen-Yu Tsai 

It correctly boots up to a U-boot prompt on my Rock64. However it
fails to read data correctly from the SD card afterwards:

U-Boot TPL 2019.10-rc1-00072-gaf0ea60e1a42 (Aug 02 2019 - 18:10:38)
LPDDR3
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2019.10-rc1-00072-gaf0ea60e1a42 (Aug 02 2019 - 18:10:38 +0800)
Trying to boot from MMC2
Card did not respond to voltage select!
spl: mmc init failed with error: -95
Trying to boot from MMC1
NOTICE:  BL31: v2.1(release):v2.1-531-g3ee48f40f
NOTICE:  BL31: Built : 17:09:50, Aug  2 2019
ERROR:   over or zero region, nr=4187640, max=10
NOTICE:  BL31:Rockchip release version: v1.2


U-Boot 2019.10-rc1-00072-gaf0ea60e1a42 (Aug 02 2019 - 18:11:02 +0800)

Model: Pine64 Rock64
DRAM:  4 GiB
MMC:   rksdmmc@ff50: 1, rksdmmc@ff52: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:serial@ff13
Out:   serial@ff13
Err:   serial@ff13
Model: Pine64 Rock64
Net:
Warning: ethernet@ff54 (eth0) using random MAC address - 7e:ba:fc:e6:98:1f
eth0: ethernet@ff54
Hit any key to stop autoboot:  0
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
588 bytes read in 13 ms (43.9 KiB/s)
## Executing script at 0050
 ** fs_devread read error - block
** No partition table - mmc 1 **
** No partition table - mmc 1 **
ERROR: Did not find a cmdline Flattened Device Tree
FDT and ATAGS support not compiled in - hanging
### ERROR ### Please RESET the board ###


boot script contents:

setenv bootargs console=ttyS2,150n8 earlycon=uart,mmio32,ff13
loglevel=8 root=/dev/mmcblk0p1 rootwait kpti=off panic=10 debug

load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ${prefix}Image
load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${fdtfile}

if load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r}
${prefix}rock64-audio-dac.dtbo; then
fdt addr ${fdt_addr_r}
fdt resize 2048
fdt apply ${ramdisk_addr_r}
fi

booti ${kernel_addr_r} - ${fdt_addr_r}

=

If I manually load the kernel Image, that also fails.
If I manually load the fdt file, it completes, but the data is
complete gibberish.
ls works fine though.

And removing the fifo-mode flag from
arch/arm/dts/rk3328-rock64-u-boot.dtsi makes it
not boot at all.

Previously I was using an old build from Armbian, and that worked fine.

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

Re: [U-Boot] [linux-sunxi] Re: [PATCH 6/6] sunxi: Pine64: DTS: enable USB PHY 0 for HCI0

[Chen-Yu Tsai]

On Wed, Jun 19, 2019 at 1:17 AM Jernej Škrabec  wrote:
>
> Dne torek, 18. junij 2019 ob 19:13:16 CEST je Clément Péron napisal(a):
> > Hi,
> >
> > On Thu, 16 May 2019 at 03:27, Andre Przywara  wrote:
> > > The first USB controller on the H6 SoC shares a PHY with the OTG
> > > controller. Reportedly to avoid problems with the VBUS regulator under
> > > Linux, we don't link OHCI0/EHCI0 to the USB PHY in the H6 .dtsi file.
> > >
> > > However on boards which can't use peripheral mode (because they have an
> > > always-on VBUS supply on an USB-A socket) we don't need this trick, and
> > > can properly connect host controller 0 to the PHY 0.
> > >
> > > Amend the Pine H64 .dts to reflect this. This enables the upper USB port
> > > in U-Boot on this board.
> > >
> > > Signed-off-by: Andre Przywara 
> > > ---
> > >
> > >  arch/arm/dts/sun50i-h6-pine-h64.dts | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/dts/sun50i-h6-pine-h64.dts
> > > b/arch/arm/dts/sun50i-h6-pine-h64.dts index 4802902e12..aad7646b18 100644
> > > --- a/arch/arm/dts/sun50i-h6-pine-h64.dts
> > > +++ b/arch/arm/dts/sun50i-h6-pine-h64.dts
> > > @@ -96,6 +96,8 @@
> > >
> > >  };
> > >
> > >   {
> > >
> > > +   phys = < 0>;
> > > +   phy-names = "usb";
> > >
> > > status = "okay";
> > >
> > >  };
> > >
> > > @@ -120,6 +122,8 @@
> > >
> > >  };
> > >
> > >   {
> > >
> > > +   phys = < 0>;
> > > +   phy-names = "usb";
> > >
> > > status = "okay";
> > >
> > >  };
> > >
> > > @@ -255,7 +259,6 @@
> > >
> > >   {
> > >
> > > dr_mode = "host";
> > >
> > > -   status = "okay";
> > >
> > >  };
> >
> > Maybe you should add explicit comments in the device-tree to avoid
> > losing this at next sync with linux dt.
>
> If DT change is U-Boot specific, it should be moved to *-u-boot.dtsi file,
> although I'm not sure if you can delete properties in such way.

You can use /delete-property/. Though in the case of "status",
it is best to set it to "disabled", since no property is the same
as "okay".

The question then becomes when the *-u-boot.dtsi file is merged in.

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

Re: [U-Boot] [linux-sunxi] [PATCH 0/3] Enable networking for BananaPi M3

[Chen-Yu Tsai]

On Mon, Jun 17, 2019 at 12:31 AM Corentin Labbe
 wrote:
>
> Hello
>
> This serie fix building sun8i-emac for a83t and then enable networking
> for BananaPi M3.
>
> Regards
>
> Corentin Labbe (3):
>   configs: Sinovoip_BPI_M3_defconfig: Fix invalid DLDO3 settings
>   net: sun8i-emac: bring back support of A83T
>   configs: Sinovoip_BPI_M3_defconfig: enable sun8i-emac
>
>  configs/Sinovoip_BPI_M3_defconfig | 3 ++-
>  drivers/net/sun8i_emac.c  | 4 
>  2 files changed, 6 insertions(+), 1 deletion(-)

I'm quite sure I already too care of this in


http://git.denx.de/?p=u-boot.git;a=log;h=c23b33f5311abe32db96884318996d2b41db4c94

Furthermore, sun8i-emac was already converted to use DM clocks and resets.
I think you may have a stale branch.

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

Re: [U-Boot] [PATCH v3 0/2] sunxi: Enable EMAC on A83T boards using Realtek RTL8211E PHY

[Chen-Yu Tsai]

On Fri, May 3, 2019 at 8:15 PM Jagan Teki  wrote:
>
> On Fri, May 3, 2019 at 3:31 PM Chen-Yu Tsai  wrote:
> >
> > On Fri, May 3, 2019 at 5:49 PM Jagan Teki  
> > wrote:
> > >
> > > On Fri, May 3, 2019 at 7:58 AM Chen-Yu Tsai  wrote:
> > > >
> > > > From: Chen-Yu Tsai 
> > > >
> > > > Hi everyone,
> > > >
> > > > This series enables EMAC (Ethernet controller) on two A83T boards,
> > > > the Cubietruck Plus and Bananapi M3.
> > > >
> > > > This series is now based on sunxi/next, which has patches that convert
> > > > sun8i-emac to use the common CLK and DM_RESET framework.
> > > >
> > > > The two patches enable the sun8i-emac and Realtek PHY driver in their
> > >
> > > So, the U-Boot operates realtek than what Linux does via
> > > ethernet-phy-ieee802.3-c22 right? if someone add it in future it will
> > > override realtek since we have a dts compatible enabled it dts files
> > > already isn't it?
> >
> > What? No. The PHY vendor and model are automatically detected by reading
> > the standard registers in the PHY. The compatible string is only used to
> > determine how to access the registers. c22 vs c45 define different ways
> > of accessing registers, as well as a larger address space for c45.
> >
> > See https://www.totalphase.com/support/articles/200349206-MDIO-Background
> >
> > By reading the vendor and model IDs, the system, be it Linux or U-boot,
> > can then go through the list of registered PHY drivers to find a match,
> > or fall back to some generic implementation.
>
> Yes, I understand thanks.
>
> >
> > It used to be you needed to enable the Realtek driver for gigabit links
> > to work properly, but that seems to have been fixed. Nevertheless, having
> > the specific driver enabled is better.
>
> Ah.. this is what exactly I tried before in Linux since it doesn't
> enable default in sunxi_defconfig. on the other-hand the existing
> generic compatible is also working for gigabit links as well.

Yeah. My memories of it not working are from way back, before the whole
DM conversion even started.

I think it's still better to have the specific driver enabled though,
as the PHY has some vendor specific features or status flags.

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

Re: [U-Boot] [PATCH v3 0/2] sunxi: Enable EMAC on A83T boards using Realtek RTL8211E PHY

[Chen-Yu Tsai]

On Fri, May 3, 2019 at 5:49 PM Jagan Teki  wrote:
>
> On Fri, May 3, 2019 at 7:58 AM Chen-Yu Tsai  wrote:
> >
> > From: Chen-Yu Tsai 
> >
> > Hi everyone,
> >
> > This series enables EMAC (Ethernet controller) on two A83T boards,
> > the Cubietruck Plus and Bananapi M3.
> >
> > This series is now based on sunxi/next, which has patches that convert
> > sun8i-emac to use the common CLK and DM_RESET framework.
> >
> > The two patches enable the sun8i-emac and Realtek PHY driver in their
>
> So, the U-Boot operates realtek than what Linux does via
> ethernet-phy-ieee802.3-c22 right? if someone add it in future it will
> override realtek since we have a dts compatible enabled it dts files
> already isn't it?

What? No. The PHY vendor and model are automatically detected by reading
the standard registers in the PHY. The compatible string is only used to
determine how to access the registers. c22 vs c45 define different ways
of accessing registers, as well as a larger address space for c45.

See https://www.totalphase.com/support/articles/200349206-MDIO-Background

By reading the vendor and model IDs, the system, be it Linux or U-boot,
can then go through the list of registered PHY drivers to find a match,
or fall back to some generic implementation.

It used to be you needed to enable the Realtek driver for gigabit links
to work properly, but that seems to have been fixed. Nevertheless, having
the specific driver enabled is better.

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

[U-Boot] [PATCH v3 2/2] sunxi: Enable EMAC on the Bananapi M3

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The Bananapi M3 has an RTL8211E PHY connected to the EMAC using
RGMII. The PHY is powered by DCDC1 through SW @ 3.3V.

The board is designed to use 3.3V with RGMII, instead of the standard
reduced voltage of 2.5V we see everywhere. DLDO3, which provides the
I/O voltages, is raised to match.

This patch enables the EMAC and Realtek PHY drivers in the defconfig.
The device tree file already has the EMAC enabled.

Signed-off-by: Chen-Yu Tsai 

---

Changes in v3:
  - Rebased on sunxi/master

Changes in v2:
  - Dropped clk/reset related changes in favor of DM CLK / RESET support
  - Raised DLDO3 for RGMII I/O on Bananapi M3 to 3.3V per design

 configs/Sinovoip_BPI_M3_defconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configs/Sinovoip_BPI_M3_defconfig 
b/configs/Sinovoip_BPI_M3_defconfig
index 79743a9c9a51..b9ab00cb8a29 100644
--- a/configs/Sinovoip_BPI_M3_defconfig
+++ b/configs/Sinovoip_BPI_M3_defconfig
@@ -21,8 +21,10 @@ CONFIG_CONSOLE_MUX=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_DEFAULT_DEVICE_TREE="sun8i-a83t-bananapi-m3"
+CONFIG_PHY_REALTEK=y
+CONFIG_SUN8I_EMAC=y
 CONFIG_AXP_DCDC5_VOLT=1200
-CONFIG_AXP_DLDO3_VOLT=2500
+CONFIG_AXP_DLDO3_VOLT=3300
 CONFIG_AXP_SW_ON=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_OHCI_HCD=y
-- 
2.20.1

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

[U-Boot] [PATCH v3 0/2] sunxi: Enable EMAC on A83T boards using Realtek RTL8211E PHY

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi everyone,

This series enables EMAC (Ethernet controller) on two A83T boards,
the Cubietruck Plus and Bananapi M3.

This series is now based on sunxi/next, which has patches that convert
sun8i-emac to use the common CLK and DM_RESET framework.

The two patches enable the sun8i-emac and Realtek PHY driver in their
respective defconfigs. The device trees already have the EMAC enabled.
For the Bananapi M3, the regulator providing the I/O voltages is raised
to 3.3V.

This was tested with the "dhcp" command followed by using the "ping"
command to ping an external IP, in this case 8.8.8.8.

Regards
ChenYu

Changes in v3:
  - Rebased on sunxi/master

Changes in v2:
  - Dropped clk/reset related changes in favor of DM CLK / RESET support
  - Raised DLDO3 for RGMII I/O on Bananapi M3 to 3.3V per design

Chen-Yu Tsai (2):
  sunxi: Enable EMAC on the Cubietruck Plus
  sunxi: Enable EMAC on the Bananapi M3

 configs/Cubietruck_plus_defconfig | 2 ++
 configs/Sinovoip_BPI_M3_defconfig | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

-- 
2.20.1

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

[U-Boot] [PATCH v3 1/2] sunxi: Enable EMAC on the Cubietruck Plus

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The Cubietruck Plus has an RTL8211E PHY connected to the EMAC using
RGMII. The PHY is powered by DLDO4 @ 3.3V, while the I/O pins are
powered by DLDO3 @ 2.5V.

This patch enables the EMAC and Realtek PHY drivers in the defconfig.
The device tree file already has the EMAC enabled.

Signed-off-by: Chen-Yu Tsai 
---

Changes in v3: None
Changes in v2: None

 configs/Cubietruck_plus_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/Cubietruck_plus_defconfig 
b/configs/Cubietruck_plus_defconfig
index 869bffcfca0c..044af12779c6 100644
--- a/configs/Cubietruck_plus_defconfig
+++ b/configs/Cubietruck_plus_defconfig
@@ -20,6 +20,8 @@ CONFIG_CONSOLE_MUX=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_DEFAULT_DEVICE_TREE="sun8i-a83t-cubietruck-plus"
+CONFIG_PHY_REALTEK=y
+CONFIG_SUN8I_EMAC=y
 CONFIG_AXP_DLDO3_VOLT=2500
 CONFIG_AXP_DLDO4_VOLT=3300
 CONFIG_AXP_FLDO1_VOLT=1200
-- 
2.20.1

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

[U-Boot] [RFT PATCH v2 2/2] sunxi: Enable EMAC on the Bananapi M3

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The Bananapi M3 has an RTL8211E PHY connected to the EMAC using
RGMII. The PHY is powered by DCDC1 through SW @ 3.3V.

The board is designed to use 3.3V with RGMII, instead of the standard
reduced voltage of 2.5V we see everywhere. DLDO3, which provides the
I/O voltages, is raised to match.

This patch enables the EMAC and Realtek PHY drivers in the defconfig.
The device tree file already has the EMAC enabled.

Signed-off-by: Chen-Yu Tsai 

---

Changes in v2:
  - Dropped clk/reset related changes in favor of DM CLK / RESET support
  - Raised DLDO3 for RGMII I/O on Bananapi M3 to 3.3V per design

 configs/Sinovoip_BPI_M3_defconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configs/Sinovoip_BPI_M3_defconfig 
b/configs/Sinovoip_BPI_M3_defconfig
index 79743a9c9a51..b9ab00cb8a29 100644
--- a/configs/Sinovoip_BPI_M3_defconfig
+++ b/configs/Sinovoip_BPI_M3_defconfig
@@ -21,8 +21,10 @@ CONFIG_CONSOLE_MUX=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_DEFAULT_DEVICE_TREE="sun8i-a83t-bananapi-m3"
+CONFIG_PHY_REALTEK=y
+CONFIG_SUN8I_EMAC=y
 CONFIG_AXP_DCDC5_VOLT=1200
-CONFIG_AXP_DLDO3_VOLT=2500
+CONFIG_AXP_DLDO3_VOLT=3300
 CONFIG_AXP_SW_ON=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_OHCI_HCD=y
-- 
2.20.1

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

[U-Boot] [RFT PATCH v2 0/2] sunxi: Enable EMAC on A83T boards using Realtek RTL8211E PHY

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

Hi everyone,

This series enables EMAC (Ethernet controller) on two A83T boards,
the Cubietruck Plus and Bananapi M3.

This series is now based on sunxi/next, which has patches that convert
sun8i-emac to use the common CLK and DM_RESET framework.

The two patches enable the sun8i-emac and Realtek PHY driver in their
respective defconfigs. The device trees already have the EMAC enabled.
For the Bananapi M3, the regulator providing the I/O voltages is raised
to 3.3V.

As I currently do not have access to my boards, testing by others is
requested.

Regards
ChenYu

Changes in v2:
  - Dropped clk/reset related changes in favor of DM CLK / RESET support
  - Raised DLDO3 for RGMII I/O on Bananapi M3 to 3.3V per design

Chen-Yu Tsai (2):
  sunxi: Enable EMAC on the Cubietruck Plus
  sunxi: Enable EMAC on the Bananapi M3

 configs/Cubietruck_plus_defconfig | 2 ++
 configs/Sinovoip_BPI_M3_defconfig | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

-- 
2.20.1

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

[U-Boot] [RFT PATCH v2 1/2] sunxi: Enable EMAC on the Cubietruck Plus

[Chen-Yu Tsai]

From: Chen-Yu Tsai 

The Cubietruck Plus has an RTL8211E PHY connected to the EMAC using
RGMII. The PHY is powered by DLDO4 @ 3.3V, while the I/O pins are
powered by DLDO3 @ 2.5V.

This patch enables the EMAC and Realtek PHY drivers in the defconfig.
The device tree file already has the EMAC enabled.

Signed-off-by: Chen-Yu Tsai 
---

Changes in v2: None

 configs/Cubietruck_plus_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/Cubietruck_plus_defconfig 
b/configs/Cubietruck_plus_defconfig
index 869bffcfca0c..044af12779c6 100644
--- a/configs/Cubietruck_plus_defconfig
+++ b/configs/Cubietruck_plus_defconfig
@@ -20,6 +20,8 @@ CONFIG_CONSOLE_MUX=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_DEFAULT_DEVICE_TREE="sun8i-a83t-cubietruck-plus"
+CONFIG_PHY_REALTEK=y
+CONFIG_SUN8I_EMAC=y
 CONFIG_AXP_DLDO3_VOLT=2500
 CONFIG_AXP_DLDO4_VOLT=3300
 CONFIG_AXP_FLDO1_VOLT=1200
-- 
2.20.1

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

Re: [U-Boot] [RESEND-2 PATCH 0/4] sunxi: Enable EMAC on A83T boards using Realtek RTL8211E PHY

[Chen-Yu Tsai]

On Thu, Apr 18, 2019 at 10:07 AM Jagan Teki  wrote:
>
> On Thu, Apr 18, 2019 at 10:33 PM Chen-Yu Tsai  wrote:
> >
> > On Thu, Apr 18, 2019 at 9:51 AM Jagan Teki  
> > wrote:
> > >
> > > On Thu, Apr 18, 2019 at 10:19 PM Chen-Yu Tsai  wrote:
> > > >
> > > > On Thu, Apr 18, 2019 at 9:42 AM Jagan Teki  
> > > > wrote:
> > > > >
> > > > > On Thu, Apr 18, 2019 at 10:00 PM Chen-Yu Tsai  wrote:
> > > > > >
> > > > > > On Thu, Apr 18, 2019 at 9:15 AM Chen-Yu Tsai  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Apr 18, 2019 at 8:09 AM Chen-Yu Tsai  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Wed, Apr 17, 2019 at 4:38 AM Jagan Teki 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > On Fri, Apr 12, 2019 at 4:05 PM Chen-Yu Tsai 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > From: Chen-Yu Tsai 
> > > > > > > > > >
> > > > > > > > > > (Resending yet again with correct email address now 
> > > > > > > > > > subscribed
> > > > > > > > > >  and with proper cover letter subject. Sorry for the noise.)
> > > > > > > > > >
> > > > > > > > > > Hi everyone,
> > > > > > > > > >
> > > > > > > > > > This series enables EMAC (Ethernet controller) on two A83T 
> > > > > > > > > > boards,
> > > > > > > > > > the Cubietruck Plus and Bananapi M3.
> > > > > > > > > >
> > > > > > > > > > A couple of changes are required to the clock definitions 
> > > > > > > > > > to make the
> > > > > > > > > > compiler happy, as it hasn't been coverted to use the 
> > > > > > > > > > common CLK and
> > > > > > > > > > DM_RESET framework. These changes are not used in the A83T 
> > > > > > > > > > code path.
> > > > > > > > > >
> > > > > > > > > > The other two patches enable the sun8i-emac and Realtek PHY 
> > > > > > > > > > driver in
> > > > > > > > > > their respective defconfigs. The device trees already have 
> > > > > > > > > > the EMAC
> > > > > > > > > > enabled.
> > > > > > > > > >
> > > > > > > > > > Since these are compile time issues, all patches should go 
> > > > > > > > > > through
> > > > > > > > > > the same tree.
> > > > > > > > > >
> > > > > > > > > > Regards
> > > > > > > > > > ChenYu
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Chen-Yu Tsai (4):
> > > > > > > > > >   sunxi: Fix compilation of sun8i-emac for A83T
> > > > > > > > > >   net: sun8i-emac: Fix compilation for A83T
> > > > > > > > > >   sunxi: Enable EMAC on the Cubietruck Plus
> > > > > > > > > >   sunxi: Enable EMAC on the Bananapi M3
> > > > > > > > >
> > > > > > > > > We have EPHY clock and reset support via respective framework 
> > > > > > > > > [1]
> > > > > > > > > would you rebase these changes on top this.
> > > > > > > > >
> > > > > > > > > [1] 
> > > > > > > > > http://git.denx.de/?p=u-boot-sunxi.git;a=commitdiff;h=6b2ccabee2368d059513a9be37c0ffaa4a47ec99
> > > > > > > >
> > > > > > > > Lovely! I'll throw the clock register bit patches out and 
> > > > > > > > rework the
> > > > > > > > other stuff.
> > > > > > > >
> > > > > > > > Does anyone