* [PATCH 00/11] rk3399: SPI boot support (fixes, updates)
@ 2019-12-21 7:54 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: Simon Glass, Kever Yang, Philipp Tomsich
Cc: u-boot, linux-amarula, linux-rockchip
This series support SPI boot on rk3399 in ROC-PC-RK3399 as
an example board.
Series introduces rk_spi fixes, sf distroboot, SPI boot support
on ROC-PC-RK3399 board.
SPI Boot log:
------------
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
U-Boot SPL 2020.01-rc4-00241-g9c3e7e925f (Dec 18 2019 - 19:54:46 +0530)
Trying to boot from SPI
U-Boot 2020.01-rc4-00241-g9c3e7e925f (Dec 18 2019 - 19:54:46 +0530)
Model: Firefly ROC-RK3399-PC Board
DRAM: 3.9 GiB
PMIC: RK808
MMC: dwmmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment
In: serial@ff1a0000
Out: serial@ff1a0000
Err: serial@ff1a0000
Model: Firefly ROC-RK3399-PC Board
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net:
Error: ethernet@fe300000 address not set.
No ethernet found.
Hit any key to stop autoboot: 0
=>
Any inputs?
Jagan.
Jagan Teki (11):
spi: rk: Limit transfers to (64K - 1) bytes
distro_bootcmd: Add SF support
rockchip: Include SF on distrocmd devices
rk3399: Add boot flash script offet, size
rk3399: Check MMC env while defining it
env: kconfig: Restrict rockchip env for MMC
env: Enable SPI flash env for rockchip
rockchip: dts: Sync ROC-RK3399-PC changes from Linux
roc-pc-rk3399: Enable SPI Flash
rockpro-rk3399: Enable SPI Flash
roc-rk3399-pc: Add SPI boot support
arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 16 +-
arch/arm/dts/rk3399-roc-pc.dts | 673 +-----------------
arch/arm/dts/rk3399-roc-pc.dtsi | 813 ++++++++++++++++++++++
arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 +
board/rockchip/evb_rk3399/MAINTAINERS | 2 +
configs/roc-pc-rk3399-spi_defconfig | 62 ++
configs/roc-pc-rk3399_defconfig | 2 +
configs/rockpro64-rk3399_defconfig | 2 +
drivers/spi/rk_spi.c | 10 +-
env/Kconfig | 8 +-
include/config_distro_bootcmd.h | 35 +
include/configs/evb_rk3399.h | 4 +-
include/configs/rk3399_common.h | 2 +
include/configs/rockchip-common.h | 7 +
14 files changed, 964 insertions(+), 676 deletions(-)
create mode 100644 arch/arm/dts/rk3399-roc-pc.dtsi
create mode 100644 configs/roc-pc-rk3399-spi_defconfig
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 00/11] rk3399: SPI boot support (fixes, updates)
@ 2019-12-21 7:54 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: u-boot
This series support SPI boot on rk3399 in ROC-PC-RK3399 as
an example board.
Series introduces rk_spi fixes, sf distroboot, SPI boot support
on ROC-PC-RK3399 board.
SPI Boot log:
------------
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
U-Boot SPL 2020.01-rc4-00241-g9c3e7e925f (Dec 18 2019 - 19:54:46 +0530)
Trying to boot from SPI
U-Boot 2020.01-rc4-00241-g9c3e7e925f (Dec 18 2019 - 19:54:46 +0530)
Model: Firefly ROC-RK3399-PC Board
DRAM: 3.9 GiB
PMIC: RK808
MMC: dwmmc at fe320000: 1, sdhci at fe330000: 0
Loading Environment from SPI Flash... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
*** Warning - bad CRC, using default environment
In: serial at ff1a0000
Out: serial at ff1a0000
Err: serial at ff1a0000
Model: Firefly ROC-RK3399-PC Board
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net:
Error: ethernet at fe300000 address not set.
No ethernet found.
Hit any key to stop autoboot: 0
=>
Any inputs?
Jagan.
Jagan Teki (11):
spi: rk: Limit transfers to (64K - 1) bytes
distro_bootcmd: Add SF support
rockchip: Include SF on distrocmd devices
rk3399: Add boot flash script offet, size
rk3399: Check MMC env while defining it
env: kconfig: Restrict rockchip env for MMC
env: Enable SPI flash env for rockchip
rockchip: dts: Sync ROC-RK3399-PC changes from Linux
roc-pc-rk3399: Enable SPI Flash
rockpro-rk3399: Enable SPI Flash
roc-rk3399-pc: Add SPI boot support
arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 16 +-
arch/arm/dts/rk3399-roc-pc.dts | 673 +-----------------
arch/arm/dts/rk3399-roc-pc.dtsi | 813 ++++++++++++++++++++++
arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 +
board/rockchip/evb_rk3399/MAINTAINERS | 2 +
configs/roc-pc-rk3399-spi_defconfig | 62 ++
configs/roc-pc-rk3399_defconfig | 2 +
configs/rockpro64-rk3399_defconfig | 2 +
drivers/spi/rk_spi.c | 10 +-
env/Kconfig | 8 +-
include/config_distro_bootcmd.h | 35 +
include/configs/evb_rk3399.h | 4 +-
include/configs/rk3399_common.h | 2 +
include/configs/rockchip-common.h | 7 +
14 files changed, 964 insertions(+), 676 deletions(-)
create mode 100644 arch/arm/dts/rk3399-roc-pc.dtsi
create mode 100644 configs/roc-pc-rk3399-spi_defconfig
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 01/11] spi: rk: Limit transfers to (64K - 1) bytes
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-21 7:54 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: Simon Glass, Kever Yang, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula, Jagan Teki,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
The Rockchip SPI controller's length register only supports 16-bits,
yielding a maximum length of 64KiB (the CTRLR1 register holds "length -
1"). Trying to transfer more than that (e.g., with a large SPI flash
read) will cause the driver to hang.
Now, it seems that while theoretically we should be able to program
CTRLR1 with 0xffff, and get a 64KiB transfer, but that also seems to
cause the core to choke, so stick with a maximum of 64K - 1 bytes --
i.e., 0xffff.
Note, that the size is further divided into 'minus 1' while writing
into CTRLR1.
This change fixed two different read issues,
1. sf read failure when with > 0x10000
2. Boot from SPI flash failed during spi_flash_read call in
common/spl/spl_spi.c
Observed and Tested in
- Rockpro64 with Gigadevice flash
- ROC-RK3399-PC with Winbond flash
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
drivers/spi/rk_spi.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/rk_spi.c b/drivers/spi/rk_spi.c
index c04535ac44..95eeb8307a 100644
--- a/drivers/spi/rk_spi.c
+++ b/drivers/spi/rk_spi.c
@@ -27,6 +27,12 @@
/* Change to 1 to output registers at the start of each transaction */
#define DEBUG_RK_SPI 0
+/*
+ * ctrlr1 is 16-bits, so we should support lengths of 0xffff + 1. However,
+ * the controller seems to hang when given 0x10000, so stick with this for now.
+ */
+#define ROCKCHIP_SPI_MAX_TRANLEN 0xffff
+
struct rockchip_spi_params {
/* RXFIFO overruns and TXFIFO underruns stop the master clock */
bool master_manages_fifo;
@@ -367,7 +373,7 @@ static inline int rockchip_spi_16bit_reader(struct udevice *dev,
* represented in CTRLR1.
*/
if (data && data->master_manages_fifo)
- max_chunk_size = 0x10000;
+ max_chunk_size = ROCKCHIP_SPI_MAX_TRANLEN;
// rockchip_spi_configure(dev, mode, size)
rkspi_enable_chip(regs, false);
@@ -451,7 +457,7 @@ static int rockchip_spi_xfer(struct udevice *dev, unsigned int bitlen,
/* This is the original 8bit reader/writer code */
while (len > 0) {
- int todo = min(len, 0x10000);
+ int todo = min(len, ROCKCHIP_SPI_MAX_TRANLEN);
rkspi_enable_chip(regs, false);
writel(todo - 1, ®s->ctrlr1);
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 01/11] spi: rk: Limit transfers to (64K - 1) bytes
@ 2019-12-21 7:54 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: u-boot
The Rockchip SPI controller's length register only supports 16-bits,
yielding a maximum length of 64KiB (the CTRLR1 register holds "length -
1"). Trying to transfer more than that (e.g., with a large SPI flash
read) will cause the driver to hang.
Now, it seems that while theoretically we should be able to program
CTRLR1 with 0xffff, and get a 64KiB transfer, but that also seems to
cause the core to choke, so stick with a maximum of 64K - 1 bytes --
i.e., 0xffff.
Note, that the size is further divided into 'minus 1' while writing
into CTRLR1.
This change fixed two different read issues,
1. sf read failure when with > 0x10000
2. Boot from SPI flash failed during spi_flash_read call in
common/spl/spl_spi.c
Observed and Tested in
- Rockpro64 with Gigadevice flash
- ROC-RK3399-PC with Winbond flash
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
drivers/spi/rk_spi.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/rk_spi.c b/drivers/spi/rk_spi.c
index c04535ac44..95eeb8307a 100644
--- a/drivers/spi/rk_spi.c
+++ b/drivers/spi/rk_spi.c
@@ -27,6 +27,12 @@
/* Change to 1 to output registers at the start of each transaction */
#define DEBUG_RK_SPI 0
+/*
+ * ctrlr1 is 16-bits, so we should support lengths of 0xffff + 1. However,
+ * the controller seems to hang when given 0x10000, so stick with this for now.
+ */
+#define ROCKCHIP_SPI_MAX_TRANLEN 0xffff
+
struct rockchip_spi_params {
/* RXFIFO overruns and TXFIFO underruns stop the master clock */
bool master_manages_fifo;
@@ -367,7 +373,7 @@ static inline int rockchip_spi_16bit_reader(struct udevice *dev,
* represented in CTRLR1.
*/
if (data && data->master_manages_fifo)
- max_chunk_size = 0x10000;
+ max_chunk_size = ROCKCHIP_SPI_MAX_TRANLEN;
// rockchip_spi_configure(dev, mode, size)
rkspi_enable_chip(regs, false);
@@ -451,7 +457,7 @@ static int rockchip_spi_xfer(struct udevice *dev, unsigned int bitlen,
/* This is the original 8bit reader/writer code */
while (len > 0) {
- int todo = min(len, 0x10000);
+ int todo = min(len, ROCKCHIP_SPI_MAX_TRANLEN);
rkspi_enable_chip(regs, false);
writel(todo - 1, ®s->ctrlr1);
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 02/11] distro_bootcmd: Add SF support
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-21 7:54 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: Simon Glass, Kever Yang, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula, Jagan Teki,
Tom Rini, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Add distro boot command support for SPI flash.
This distro boot will read the boot script at specific
location at the flash and start sourcing the same.
The common macro like BOOTENV_SHARED_FLASH would help
to extend the support for nand flash in future.
Cc: Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
include/config_distro_bootcmd.h | 35 +++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index fc0935fa21..d68b79e290 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -43,6 +43,22 @@
#define BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) \
#devtypel #instance " "
+#define BOOTENV_SHARED_SF_BODY(devtypel) \
+ "if " #devtypel " probe ${devnum}; then " \
+ "devtype=" #devtypel "; " \
+ "run scan_flash_for_scripts; " \
+ "fi\0"
+
+#define BOOTENV_SHARED_FLASH(devtypel) \
+ #devtypel "_boot=" \
+ BOOTENV_SHARED_SF_BODY(devtypel)
+
+#define BOOTENV_DEV_FLASH(devtypeu, devtypel, instance) \
+ BOOTENV_DEV_BLKDEV(devtypeu, devtypel, instance)
+
+#define BOOTENV_DEV_NAME_FLASH(devtypeu, devtypel, instance) \
+ BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance)
+
#ifdef CONFIG_SANDBOX
#define BOOTENV_SHARED_HOST BOOTENV_SHARED_BLKDEV(host)
#define BOOTENV_DEV_HOST BOOTENV_DEV_BLKDEV
@@ -398,6 +414,18 @@
BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE
#endif
+#if defined(CONFIG_CMD_SF)
+#define BOOTENV_SHARED_SF BOOTENV_SHARED_FLASH(sf)
+#define BOOTENV_DEV_SF BOOTENV_DEV_FLASH
+#define BOOTENV_DEV_NAME_SF BOOTENV_DEV_NAME_FLASH
+#else
+#define BOOTENV_SHARED_SF
+#define BOOTENV_DEV_SF \
+ BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF
+#define BOOTENV_DEV_NAME_SF \
+ BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF
+#endif
+
#define BOOTENV_DEV_NAME(devtypeu, devtypel, instance) \
BOOTENV_DEV_NAME_##devtypeu(devtypeu, devtypel, instance)
#define BOOTENV_BOOT_TARGETS \
@@ -412,6 +440,7 @@
BOOTENV_SHARED_USB \
BOOTENV_SHARED_SATA \
BOOTENV_SHARED_SCSI \
+ BOOTENV_SHARED_SF \
BOOTENV_SHARED_NVME \
BOOTENV_SHARED_IDE \
BOOTENV_SHARED_UBIFS \
@@ -436,6 +465,12 @@
"echo SCRIPT FAILED: continuing...; " \
"fi\0" \
\
+ "scan_flash_for_scripts=" \
+ "${devtype} read ${scriptaddr} " \
+ "${script_offset_f} ${script_size_f}; " \
+ "source ${scriptaddr}; " \
+ "echo SCRIPT FAILED: continuing...\0" \
+ \
"boot_a_script=" \
"load ${devtype} ${devnum}:${distro_bootpart} " \
"${scriptaddr} ${prefix}${script}; " \
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 02/11] distro_bootcmd: Add SF support
@ 2019-12-21 7:54 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: u-boot
Add distro boot command support for SPI flash.
This distro boot will read the boot script at specific
location at the flash and start sourcing the same.
The common macro like BOOTENV_SHARED_FLASH would help
to extend the support for nand flash in future.
Cc: Tom Rini <trini@konsulko.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
include/config_distro_bootcmd.h | 35 +++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index fc0935fa21..d68b79e290 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -43,6 +43,22 @@
#define BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) \
#devtypel #instance " "
+#define BOOTENV_SHARED_SF_BODY(devtypel) \
+ "if " #devtypel " probe ${devnum}; then " \
+ "devtype=" #devtypel "; " \
+ "run scan_flash_for_scripts; " \
+ "fi\0"
+
+#define BOOTENV_SHARED_FLASH(devtypel) \
+ #devtypel "_boot=" \
+ BOOTENV_SHARED_SF_BODY(devtypel)
+
+#define BOOTENV_DEV_FLASH(devtypeu, devtypel, instance) \
+ BOOTENV_DEV_BLKDEV(devtypeu, devtypel, instance)
+
+#define BOOTENV_DEV_NAME_FLASH(devtypeu, devtypel, instance) \
+ BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance)
+
#ifdef CONFIG_SANDBOX
#define BOOTENV_SHARED_HOST BOOTENV_SHARED_BLKDEV(host)
#define BOOTENV_DEV_HOST BOOTENV_DEV_BLKDEV
@@ -398,6 +414,18 @@
BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE
#endif
+#if defined(CONFIG_CMD_SF)
+#define BOOTENV_SHARED_SF BOOTENV_SHARED_FLASH(sf)
+#define BOOTENV_DEV_SF BOOTENV_DEV_FLASH
+#define BOOTENV_DEV_NAME_SF BOOTENV_DEV_NAME_FLASH
+#else
+#define BOOTENV_SHARED_SF
+#define BOOTENV_DEV_SF \
+ BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF
+#define BOOTENV_DEV_NAME_SF \
+ BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF
+#endif
+
#define BOOTENV_DEV_NAME(devtypeu, devtypel, instance) \
BOOTENV_DEV_NAME_##devtypeu(devtypeu, devtypel, instance)
#define BOOTENV_BOOT_TARGETS \
@@ -412,6 +440,7 @@
BOOTENV_SHARED_USB \
BOOTENV_SHARED_SATA \
BOOTENV_SHARED_SCSI \
+ BOOTENV_SHARED_SF \
BOOTENV_SHARED_NVME \
BOOTENV_SHARED_IDE \
BOOTENV_SHARED_UBIFS \
@@ -436,6 +465,12 @@
"echo SCRIPT FAILED: continuing...; " \
"fi\0" \
\
+ "scan_flash_for_scripts=" \
+ "${devtype} read ${scriptaddr} " \
+ "${script_offset_f} ${script_size_f}; " \
+ "source ${scriptaddr}; " \
+ "echo SCRIPT FAILED: continuing...\0" \
+ \
"boot_a_script=" \
"load ${devtype} ${devnum}:${distro_bootpart} " \
"${scriptaddr} ${prefix}${script}; " \
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 03/11] rockchip: Include SF on distrocmd devices
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-21 7:54 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: Simon Glass, Kever Yang, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula, Jagan Teki,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Include the SPI flash device on distro boot targets.
Included at the beginning of the target devices list
since the rockchip platform has a boot order start
from SPI Flash.
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
include/configs/rockchip-common.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
index 68e1105a4b..4e6d6e98d9 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -11,6 +11,12 @@
#ifndef CONFIG_SPL_BUILD
+#if CONFIG_IS_ENABLED(CMD_SF)
+# define BOOT_TARGET_SF(func) func(SF, sf, 0)
+#else
+# define BOOT_TARGET_SF(func)
+#endif
+
/* First try to boot from SD (index 0), then eMMC (index 1) */
#if CONFIG_IS_ENABLED(CMD_MMC)
#define BOOT_TARGET_MMC(func) \
@@ -39,6 +45,7 @@
#endif
#define BOOT_TARGET_DEVICES(func) \
+ BOOT_TARGET_SF(func) \
BOOT_TARGET_MMC(func) \
BOOT_TARGET_USB(func) \
BOOT_TARGET_PXE(func) \
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 03/11] rockchip: Include SF on distrocmd devices
@ 2019-12-21 7:54 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: u-boot
Include the SPI flash device on distro boot targets.
Included at the beginning of the target devices list
since the rockchip platform has a boot order start
from SPI Flash.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
include/configs/rockchip-common.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
index 68e1105a4b..4e6d6e98d9 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -11,6 +11,12 @@
#ifndef CONFIG_SPL_BUILD
+#if CONFIG_IS_ENABLED(CMD_SF)
+# define BOOT_TARGET_SF(func) func(SF, sf, 0)
+#else
+# define BOOT_TARGET_SF(func)
+#endif
+
/* First try to boot from SD (index 0), then eMMC (index 1) */
#if CONFIG_IS_ENABLED(CMD_MMC)
#define BOOT_TARGET_MMC(func) \
@@ -39,6 +45,7 @@
#endif
#define BOOT_TARGET_DEVICES(func) \
+ BOOT_TARGET_SF(func) \
BOOT_TARGET_MMC(func) \
BOOT_TARGET_USB(func) \
BOOT_TARGET_PXE(func) \
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 04/11] rk3399: Add boot flash script offet, size
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-21 7:54 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: Simon Glass, Kever Yang, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula, Jagan Teki,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Most of the SPI flash devices in rockchip (rk3399)
are 16MiB size. So, let's use the script offset at
the end of 8K.
This way it cannot overlap any offsets being used
by software components in flash layout.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
include/configs/rk3399_common.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index 127ca1f09c..92eb5cb750 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -48,6 +48,8 @@
#define ENV_MEM_LAYOUT_SETTINGS \
"scriptaddr=0x00500000\0" \
+ "script_offset_f=0xffe000\0" \
+ "script_size_f=0x2000\0" \
"pxefile_addr_r=0x00600000\0" \
"fdt_addr_r=0x01f00000\0" \
"kernel_addr_r=0x02080000\0" \
--
2.18.0.321.gffc6fa0e3
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 04/11] rk3399: Add boot flash script offet, size
@ 2019-12-21 7:54 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: u-boot
Most of the SPI flash devices in rockchip (rk3399)
are 16MiB size. So, let's use the script offset at
the end of 8K.Â
This way it cannot overlap any offsets being used
by software components in flash layout.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
include/configs/rk3399_common.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index 127ca1f09c..92eb5cb750 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -48,6 +48,8 @@
#define ENV_MEM_LAYOUT_SETTINGS \
"scriptaddr=0x00500000\0" \
+ "script_offset_f=0xffe000\0" \
+ "script_size_f=0x2000\0" \
"pxefile_addr_r=0x00600000\0" \
"fdt_addr_r=0x01f00000\0" \
"kernel_addr_r=0x02080000\0" \
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 05/11] rk3399: Check MMC env while defining it
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-21 7:54 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: Simon Glass, Kever Yang, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula, Jagan Teki,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
rk3399 do support SPI flash as well, so there is
a possibility of using flash environment for those
usecases.
So define env device for MMC only when it is used
by specific configuration.
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
include/configs/evb_rk3399.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/configs/evb_rk3399.h b/include/configs/evb_rk3399.h
index b9c4d683f4..c0b0358893 100644
--- a/include/configs/evb_rk3399.h
+++ b/include/configs/evb_rk3399.h
@@ -8,7 +8,9 @@
#include <configs/rk3399_common.h>
-#define CONFIG_SYS_MMC_ENV_DEV 0
+#if defined(CONFIG_ENV_IS_IN_MMC)
+# define CONFIG_SYS_MMC_ENV_DEV 0
+#endif
#define SDRAM_BANK_SIZE (2UL << 30)
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 05/11] rk3399: Check MMC env while defining it
@ 2019-12-21 7:54 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: u-boot
rk3399 do support SPI flash as well, so there is
a possibility of using flash environment for those
usecases.
So define env device for MMC only when it is used
by specific configuration.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
include/configs/evb_rk3399.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/configs/evb_rk3399.h b/include/configs/evb_rk3399.h
index b9c4d683f4..c0b0358893 100644
--- a/include/configs/evb_rk3399.h
+++ b/include/configs/evb_rk3399.h
@@ -8,7 +8,9 @@
#include <configs/rk3399_common.h>
-#define CONFIG_SYS_MMC_ENV_DEV 0
+#if defined(CONFIG_ENV_IS_IN_MMC)
+# define CONFIG_SYS_MMC_ENV_DEV 0
+#endif
#define SDRAM_BANK_SIZE (2UL << 30)
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 06/11] env: kconfig: Restrict rockchip env for MMC
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-21 7:54 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: Simon Glass, Kever Yang, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula, Jagan Teki,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Rockchip do support SPI flash as well, so there is
a possibility of using flash environment for those
use cases.
So, restrict the current env offset, size for MMC.
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
env/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/env/Kconfig b/env/Kconfig
index ed12609f6a..9416a70022 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -488,7 +488,7 @@ config ENV_OFFSET
hex "Environment offset"
depends on ENV_IS_IN_EEPROM || ENV_IS_IN_MMC || ENV_IS_IN_NAND || \
ENV_IS_IN_SPI_FLASH
- default 0x3f8000 if ARCH_ROCKCHIP
+ default 0x3f8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
default 0x88000 if ARCH_SUNXI
default 0xE0000 if ARCH_ZYNQ
default 0x1E00000 if ARCH_ZYNQMP
@@ -511,7 +511,8 @@ config ENV_SIZE
hex "Environment Size"
default 0x40000 if ENV_IS_IN_SPI_FLASH && ARCH_ZYNQMP
default 0x20000 if ARCH_SUNXI || ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
- default 0x8000 if ARCH_ROCKCHIP || ARCH_ZYNQMP || ARCH_VERSAL
+ default 0x8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
+ default 0x8000 if ARCH_ZYNQMP || ARCH_VERSAL
default 0x4000 if ARC
default 0x1f000
help
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 06/11] env: kconfig: Restrict rockchip env for MMC
@ 2019-12-21 7:54 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: u-boot
Rockchip do support SPI flash as well, so there is
a possibility of using flash environment for those
use cases.
So, restrict the current env offset, size for MMC.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
env/Kconfig | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/env/Kconfig b/env/Kconfig
index ed12609f6a..9416a70022 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -488,7 +488,7 @@ config ENV_OFFSET
hex "Environment offset"
depends on ENV_IS_IN_EEPROM || ENV_IS_IN_MMC || ENV_IS_IN_NAND || \
ENV_IS_IN_SPI_FLASH
- default 0x3f8000 if ARCH_ROCKCHIP
+ default 0x3f8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
default 0x88000 if ARCH_SUNXI
default 0xE0000 if ARCH_ZYNQ
default 0x1E00000 if ARCH_ZYNQMP
@@ -511,7 +511,8 @@ config ENV_SIZE
hex "Environment Size"
default 0x40000 if ENV_IS_IN_SPI_FLASH && ARCH_ZYNQMP
default 0x20000 if ARCH_SUNXI || ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
- default 0x8000 if ARCH_ROCKCHIP || ARCH_ZYNQMP || ARCH_VERSAL
+ default 0x8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
+ default 0x8000 if ARCH_ZYNQMP || ARCH_VERSAL
default 0x4000 if ARC
default 0x1f000
help
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 07/11] env: Enable SPI flash env for rockchip
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-21 7:54 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: Simon Glass, Kever Yang, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula, Jagan Teki,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Most of the SPI flash devices in rockchip are 16MiB size.
So, keeping U-Boot proper offset start from 128MiB with 1MiB
size and then start env of 8KiB would be a compatible location
between all variants of flash sizes.
This patch add env start from 0x14000 with a size of 8KiB.
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
env/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/env/Kconfig b/env/Kconfig
index 9416a70022..1bb3e1078e 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -489,6 +489,7 @@ config ENV_OFFSET
depends on ENV_IS_IN_EEPROM || ENV_IS_IN_MMC || ENV_IS_IN_NAND || \
ENV_IS_IN_SPI_FLASH
default 0x3f8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
+ default 0x140000 if ARCH_ROCKCHIP && ENV_IS_IN_SPI_FLASH
default 0x88000 if ARCH_SUNXI
default 0xE0000 if ARCH_ZYNQ
default 0x1E00000 if ARCH_ZYNQMP
@@ -512,6 +513,7 @@ config ENV_SIZE
default 0x40000 if ENV_IS_IN_SPI_FLASH && ARCH_ZYNQMP
default 0x20000 if ARCH_SUNXI || ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
default 0x8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
+ default 0x2000 if ARCH_ROCKCHIP && ENV_IS_IN_SPI_FLASH
default 0x8000 if ARCH_ZYNQMP || ARCH_VERSAL
default 0x4000 if ARC
default 0x1f000
@@ -521,6 +523,7 @@ config ENV_SIZE
config ENV_SECT_SIZE
hex "Environment Sector-Size"
depends on ENV_IS_IN_FLASH || ENV_IS_IN_SPI_FLASH
+ default 0x2000 if ARCH_ROCKCHIP
default 0x40000 if ARCH_ZYNQMP || ARCH_VERSAL
default 0x20000 if ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
help
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 07/11] env: Enable SPI flash env for rockchip
@ 2019-12-21 7:54 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: u-boot
Most of the SPI flash devices in rockchip are 16MiB size.
So, keeping U-Boot proper offset start from 128MiB with 1MiB
size and then start env of 8KiB would be a compatible location
between all variants of flash sizes.
This patch add env start from 0x14000 with a size of 8KiB.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
env/Kconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/env/Kconfig b/env/Kconfig
index 9416a70022..1bb3e1078e 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -489,6 +489,7 @@ config ENV_OFFSET
depends on ENV_IS_IN_EEPROM || ENV_IS_IN_MMC || ENV_IS_IN_NAND || \
ENV_IS_IN_SPI_FLASH
default 0x3f8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
+ default 0x140000 if ARCH_ROCKCHIP && ENV_IS_IN_SPI_FLASH
default 0x88000 if ARCH_SUNXI
default 0xE0000 if ARCH_ZYNQ
default 0x1E00000 if ARCH_ZYNQMP
@@ -512,6 +513,7 @@ config ENV_SIZE
default 0x40000 if ENV_IS_IN_SPI_FLASH && ARCH_ZYNQMP
default 0x20000 if ARCH_SUNXI || ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
default 0x8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
+ default 0x2000 if ARCH_ROCKCHIP && ENV_IS_IN_SPI_FLASH
default 0x8000 if ARCH_ZYNQMP || ARCH_VERSAL
default 0x4000 if ARC
default 0x1f000
@@ -521,6 +523,7 @@ config ENV_SIZE
config ENV_SECT_SIZE
hex "Environment Sector-Size"
depends on ENV_IS_IN_FLASH || ENV_IS_IN_SPI_FLASH
+ default 0x2000 if ARCH_ROCKCHIP
default 0x40000 if ARCH_ZYNQMP || ARCH_VERSAL
default 0x20000 if ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
help
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 08/11] rockchip: dts: Sync ROC-RK3399-PC changes from Linux
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-21 7:54 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: Simon Glass, Kever Yang, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula, Jagan Teki,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Sync the ROC-RK3399-PC device tree changes from Linux
with below commit details:
commit <c36308abe4110e4db362d5e2ae3797834a7b1192> ("arm64: dts:
rockchip: Enable MTD Flash on rk3399-roc-pc")
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
arch/arm/dts/rk3399-roc-pc.dts | 673 +-------------------------
arch/arm/dts/rk3399-roc-pc.dtsi | 813 ++++++++++++++++++++++++++++++++
2 files changed, 816 insertions(+), 670 deletions(-)
create mode 100644 arch/arm/dts/rk3399-roc-pc.dtsi
diff --git a/arch/arm/dts/rk3399-roc-pc.dts b/arch/arm/dts/rk3399-roc-pc.dts
index 257543d069..6a909e4eef 100644
--- a/arch/arm/dts/rk3399-roc-pc.dts
+++ b/arch/arm/dts/rk3399-roc-pc.dts
@@ -4,677 +4,10 @@
*/
/dts-v1/;
-#include <dt-bindings/pwm/pwm.h>
-#include "rk3399.dtsi"
-#include "rk3399-opp.dtsi"
+#include "rk3399-roc-pc.dtsi"
/ {
model = "Firefly ROC-RK3399-PC Board";
- compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
-
- chosen {
- stdout-path = "serial2:1500000n8";
- };
-
- backlight: backlight {
- compatible = "pwm-backlight";
- pwms = <&pwm0 0 25000 0>;
- };
-
- clkin_gmac: external-gmac-clock {
- compatible = "fixed-clock";
- clock-frequency = <125000000>;
- clock-output-names = "clkin_gmac";
- #clock-cells = <0>;
- };
-
- sdio_pwrseq: sdio-pwrseq {
- compatible = "mmc-pwrseq-simple";
- clocks = <&rk808 1>;
- clock-names = "ext_clock";
- pinctrl-names = "default";
- pinctrl-0 = <&wifi_enable_h>;
-
- /*
- * On the module itself this is one of these (depending
- * on the actual card populated):
- * - SDIO_RESET_L_WL_REG_ON
- * - PDN (power down when low)
- */
- reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
- };
-
- vcc_vbus_typec0: vcc-vbus-typec0 {
- compatible = "regulator-fixed";
- regulator-name = "vcc_vbus_typec0";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- };
-
- /*
- * should be placed inside mp8859, but not until mp8859 has
- * its own dt-binding.
- */
- dc_12v: mp8859-dcdc1 {
- compatible = "regulator-fixed";
- regulator-name = "dc_12v";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <12000000>;
- regulator-max-microvolt = <12000000>;
- vin-supply = <&vcc_vbus_typec0>;
- };
-
- /* switched by pmic_sleep */
- vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
- compatible = "regulator-fixed";
- regulator-name = "vcc1v8_s3";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&vcc_1v8>;
- };
-
- vcc3v3_sys: vcc3v3-sys {
- compatible = "regulator-fixed";
- regulator-name = "vcc3v3_sys";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- vin-supply = <&vcc_sys>;
- };
-
- /* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
- vcc5v0_host: vcc5v0-host-regulator {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&vcc5v0_host_en &hub_rst>;
- regulator-name = "vcc5v0_host";
- regulator-always-on;
- vin-supply = <&vcc_sys>;
- };
-
- vcc_vbus_typec1: vcc-vbus-typec1 {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio1 RK_PB5 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&vcc_vbus_typec1_en>;
- regulator-name = "vcc_vbus_typec1";
- regulator-always-on;
- vin-supply = <&vcc_sys>;
- };
-
- vcc_sys: vcc-sys {
- compatible = "regulator-fixed";
- regulator-name = "vcc_sys";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- vin-supply = <&dc_12v>;
- };
-
- vdd_log: vdd-log {
- compatible = "pwm-regulator";
- pwms = <&pwm2 0 25000 1>;
- regulator-name = "vdd_log";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <800000>;
- regulator-max-microvolt = <1400000>;
- vin-supply = <&vcc_sys>;
- };
-};
-
-&cpu_l0 {
- cpu-supply = <&vdd_cpu_l>;
-};
-
-&cpu_l1 {
- cpu-supply = <&vdd_cpu_l>;
-};
-
-&cpu_l2 {
- cpu-supply = <&vdd_cpu_l>;
-};
-
-&cpu_l3 {
- cpu-supply = <&vdd_cpu_l>;
-};
-
-&cpu_b0 {
- cpu-supply = <&vdd_cpu_b>;
-};
-
-&cpu_b1 {
- cpu-supply = <&vdd_cpu_b>;
-};
-
-&emmc_phy {
- status = "okay";
-};
-
-&gmac {
- assigned-clocks = <&cru SCLK_RMII_SRC>;
- assigned-clock-parents = <&clkin_gmac>;
- clock_in_out = "input";
- phy-supply = <&vcc_lan>;
- phy-mode = "rgmii";
- pinctrl-names = "default";
- pinctrl-0 = <&rgmii_pins>;
- snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
- snps,reset-active-low;
- snps,reset-delays-us = <0 10000 50000>;
- tx_delay = <0x28>;
- rx_delay = <0x11>;
- status = "okay";
-};
-
-&hdmi {
- ddc-i2c-bus = <&i2c3>;
- pinctrl-names = "default";
- pinctrl-0 = <&hdmi_cec>;
- status = "okay";
-};
-
-&i2c0 {
- clock-frequency = <400000>;
- i2c-scl-rising-time-ns = <168>;
- i2c-scl-falling-time-ns = <4>;
- status = "okay";
-
- rk808: pmic@1b {
- compatible = "rockchip,rk808";
- reg = <0x1b>;
- interrupt-parent = <&gpio1>;
- interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
- #clock-cells = <1>;
- clock-output-names = "xin32k", "rk808-clkout2";
- pinctrl-names = "default";
- pinctrl-0 = <&pmic_int_l>;
- rockchip,system-power-controller;
- wakeup-source;
-
- vcc1-supply = <&vcc_sys>;
- vcc2-supply = <&vcc_sys>;
- vcc3-supply = <&vcc_sys>;
- vcc4-supply = <&vcc_sys>;
- vcc6-supply = <&vcc_sys>;
- vcc7-supply = <&vcc_sys>;
- vcc8-supply = <&vcc3v3_sys>;
- vcc9-supply = <&vcc_sys>;
- vcc10-supply = <&vcc_sys>;
- vcc11-supply = <&vcc_sys>;
- vcc12-supply = <&vcc3v3_sys>;
- vddio-supply = <&vcc1v8_pmu>;
-
- regulators {
- vdd_center: DCDC_REG1 {
- regulator-name = "vdd_center";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <750000>;
- regulator-max-microvolt = <1350000>;
- regulator-ramp-delay = <6001>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vdd_cpu_l: DCDC_REG2 {
- regulator-name = "vdd_cpu_l";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <750000>;
- regulator-max-microvolt = <1350000>;
- regulator-ramp-delay = <6001>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc_ddr: DCDC_REG3 {
- regulator-name = "vcc_ddr";
- regulator-always-on;
- regulator-boot-on;
- regulator-state-mem {
- regulator-on-in-suspend;
- };
- };
-
- vcc_1v8: DCDC_REG4 {
- regulator-name = "vcc_1v8";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <1800000>;
- };
- };
-
- vcca1v8_codec: LDO_REG1 {
- regulator-name = "vcca1v8_codec";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc1v8_hdmi: LDO_REG2 {
- regulator-name = "vcc1v8_hdmi";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc1v8_pmu: LDO_REG3 {
- regulator-name = "vcc1v8_pmu";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <1800000>;
- };
- };
-
- vcc_sdio: LDO_REG4 {
- regulator-name = "vcc_sdio";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3000000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <3000000>;
- };
- };
-
- vcca3v0_codec: LDO_REG5 {
- regulator-name = "vcca3v0_codec";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc_1v5: LDO_REG6 {
- regulator-name = "vcc_1v5";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1500000>;
- regulator-max-microvolt = <1500000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <1500000>;
- };
- };
-
- vcca0v9_hdmi: LDO_REG7 {
- regulator-name = "vcca0v9_hdmi";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <900000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc_3v0: LDO_REG8 {
- regulator-name = "vcc_3v0";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <3000000>;
- };
- };
-
- vcc3v3_s3: vcc_lan: SWITCH_REG1 {
- regulator-name = "vcc3v3_s3";
- regulator-always-on;
- regulator-boot-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc3v3_s0: SWITCH_REG2 {
- regulator-name = "vcc3v3_s0";
- regulator-always-on;
- regulator-boot-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
- };
- };
-
- vdd_cpu_b: regulator@40 {
- compatible = "silergy,syr827";
- reg = <0x40>;
- fcs,suspend-voltage-selector = <1>;
- pinctrl-names = "default";
- pinctrl-0 = <&vsel1_gpio>;
- regulator-name = "vdd_cpu_b";
- regulator-min-microvolt = <712500>;
- regulator-max-microvolt = <1500000>;
- regulator-ramp-delay = <1000>;
- regulator-always-on;
- regulator-boot-on;
- vin-supply = <&vcc_sys>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vdd_gpu: regulator@41 {
- compatible = "silergy,syr828";
- reg = <0x41>;
- fcs,suspend-voltage-selector = <1>;
- pinctrl-names = "default";
- pinctrl-0 = <&vsel2_gpio>;
- regulator-name = "vdd_gpu";
- regulator-min-microvolt = <712500>;
- regulator-max-microvolt = <1500000>;
- regulator-ramp-delay = <1000>;
- regulator-always-on;
- regulator-boot-on;
- vin-supply = <&vcc_sys>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-};
-
-&i2c1 {
- i2c-scl-rising-time-ns = <300>;
- i2c-scl-falling-time-ns = <15>;
- status = "okay";
-};
-
-&i2c3 {
- i2c-scl-rising-time-ns = <450>;
- i2c-scl-falling-time-ns = <15>;
- status = "okay";
-};
-
-&i2c4 {
- i2c-scl-rising-time-ns = <600>;
- i2c-scl-falling-time-ns = <20>;
- status = "okay";
-
- fusb1: usb-typec@22 {
- compatible = "fcs,fusb302";
- reg = <0x22>;
- interrupt-parent = <&gpio1>;
- interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&fusb1_int>;
- vbus-supply = <&vcc_vbus_typec1>;
- status = "okay";
- };
-};
-
-&i2c7 {
- i2c-scl-rising-time-ns = <600>;
- i2c-scl-falling-time-ns = <20>;
- status = "okay";
-
- fusb0: usb-typec@22 {
- compatible = "fcs,fusb302";
- reg = <0x22>;
- interrupt-parent = <&gpio1>;
- interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&fusb0_int>;
- vbus-supply = <&vcc_vbus_typec0>;
- status = "okay";
- };
-};
-
-&i2s0 {
- rockchip,playback-channels = <8>;
- rockchip,capture-channels = <8>;
- status = "okay";
-};
-
-&i2s1 {
- rockchip,playback-channels = <2>;
- rockchip,capture-channels = <2>;
- status = "okay";
-};
-
-&i2s2 {
- status = "okay";
-};
-
-&io_domains {
- audio-supply = <&vcca1v8_codec>;
- bt656-supply = <&vcc_3v0>;
- gpio1830-supply = <&vcc_3v0>;
- sdmmc-supply = <&vcc_sdio>;
- status = "okay";
-};
-
-&pmu_io_domains {
- pmu1830-supply = <&vcc_3v0>;
- status = "okay";
-};
-
-&pinctrl {
- lcd-panel {
- lcd_panel_reset: lcd-panel-reset {
- rockchip,pins = <4 RK_PD6 RK_FUNC_GPIO &pcfg_pull_up>;
- };
- };
-
- pmic {
- vsel1_gpio: vsel1-gpio {
- rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
- };
-
- vsel2_gpio: vsel2-gpio {
- rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
- };
- };
-
- sdio-pwrseq {
- wifi_enable_h: wifi-enable-h {
- rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
-
- pmic {
- pmic_int_l: pmic-int-l {
- rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
- };
- };
-
- usb2 {
- vcc5v0_host_en: vcc5v0-host-en {
- rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
- };
-
- hub_rst: hub-rst {
- rockchip,pins = <2 RK_PA4 RK_FUNC_GPIO &pcfg_output_high>;
- };
- };
-
- usb-typec {
- vcc_vbus_typec1_en: vcc-vbus-typec1-en {
- rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
-
- fusb30x {
- fusb0_int: fusb0-int {
- rockchip,pins = <1 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
- };
-
- fusb1_int: fusb1-int {
- rockchip,pins = <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
- };
- };
-};
-
-&pwm0 {
- status = "okay";
-};
-
-&pwm2 {
- status = "okay";
-};
-
-&saradc {
- vref-supply = <&vcca1v8_s3>;
- status = "okay";
-};
-
-&sdmmc {
- bus-width = <4>;
- cap-mmc-highspeed;
- cap-sd-highspeed;
- cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
- disable-wp;
- max-frequency = <150000000>;
- pinctrl-names = "default";
- pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
- status = "okay";
-};
-
-&sdhci {
- bus-width = <8>;
- mmc-hs400-1_8v;
- mmc-hs400-enhanced-strobe;
- non-removable;
- status = "okay";
-};
-
-&tcphy0 {
- status = "okay";
-};
-
-&tcphy1 {
- status = "okay";
-};
-
-&tsadc {
- /* tshut mode 0:CRU 1:GPIO */
- rockchip,hw-tshut-mode = <1>;
- /* tshut polarity 0:LOW 1:HIGH */
- rockchip,hw-tshut-polarity = <1>;
- status = "okay";
-};
-
-&u2phy0 {
- status = "okay";
-
- u2phy0_otg: otg-port {
- phy-supply = <&vcc_vbus_typec0>;
- status = "okay";
- };
-
- u2phy0_host: host-port {
- phy-supply = <&vcc5v0_host>;
- status = "okay";
- };
-};
-
-&u2phy1 {
- status = "okay";
-
- u2phy1_otg: otg-port {
- phy-supply = <&vcc_vbus_typec1>;
- status = "okay";
- };
-
- u2phy1_host: host-port {
- phy-supply = <&vcc5v0_host>;
- status = "okay";
- };
-};
-
-&uart0 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_xfer &uart0_cts>;
- status = "okay";
-};
-
-&uart2 {
- status = "okay";
-};
-
-&usb_host0_ehci {
- status = "okay";
-};
-
-&usb_host0_ohci {
- status = "okay";
-};
-
-&usb_host1_ehci {
- status = "okay";
-};
-
-&usb_host1_ohci {
- status = "okay";
-};
-
-&usbdrd3_0 {
- status = "okay";
-};
-
-&usbdrd_dwc3_0 {
- status = "okay";
-};
-
-&usbdrd3_1 {
- status = "okay";
-};
-
-&usbdrd_dwc3_1 {
- status = "okay";
- dr_mode = "host";
-};
-
-&vopb {
- status = "okay";
-};
-
-&vopb_mmu {
- status = "okay";
-};
-
-&vopl {
- status = "okay";
-};
-
-&vopl_mmu {
- status = "okay";
+ compatible = "libretech,roc-rk3399-pc", "firefly,roc-rk3399-pc",
+ "rockchip,rk3399";
};
diff --git a/arch/arm/dts/rk3399-roc-pc.dtsi b/arch/arm/dts/rk3399-roc-pc.dtsi
new file mode 100644
index 0000000000..9a1ce3a4ae
--- /dev/null
+++ b/arch/arm/dts/rk3399-roc-pc.dtsi
@@ -0,0 +1,813 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 T-Chip Intelligent Technology Co., Ltd
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ model = "Firefly ROC-RK3399-PC Board";
+ compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm0 0 25000 0>;
+ };
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <125000000>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1500000>;
+ poll-interval = <100>;
+
+ recovery {
+ label = "Recovery";
+ linux,code = <KEY_VENDOR>;
+ press-threshold-microvolt = <18000>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwr_key_l>;
+
+ power {
+ debounce-interval = <100>;
+ gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
+ label = "GPIO Key Power";
+ linux,code = <KEY_POWER>;
+ wakeup-source;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&work_led_gpio>, <&diy_led_gpio>, <&yellow_led_gpio>;
+
+ work-led {
+ label = "green:work";
+ gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ linux,default-trigger = "heartbeat";
+ };
+
+ diy-led {
+ label = "red:diy";
+ gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ linux,default-trigger = "mmc1";
+ };
+
+ yellow-led {
+ label = "yellow:yellow-led";
+ gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ linux,default-trigger = "mmc0";
+ };
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rk808 1>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable_h>;
+
+ /*
+ * On the module itself this is one of these (depending
+ * on the actual card populated):
+ * - SDIO_RESET_L_WL_REG_ON
+ * - PDN (power down when low)
+ */
+ reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
+ };
+
+ vcc_vbus_typec0: vcc-vbus-typec0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_vbus_typec0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ /*
+ * should be placed inside mp8859, but not until mp8859 has
+ * its own dt-binding.
+ */
+ dc_12v: mp8859-dcdc1 {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_12v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ vin-supply = <&vcc_vbus_typec0>;
+ };
+
+ /* switched by pmic_sleep */
+ vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc1v8_s3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_1v8>;
+ };
+
+ vcc3v0_sd: vcc3v0-sd {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio4 RK_PD6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc3v0_sd_en>;
+ regulator-name = "vcc3v0_sd";
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vcca_0v9: vcca-0v9 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcca_0v9";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ /* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
+ vcc5v0_host: vcc5v0-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_host_en &hub_rst>;
+ regulator-name = "vcc5v0_host";
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
+ vcc_vbus_typec1: vcc-vbus-typec1 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio1 RK_PB5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc_vbus_typec1_en>;
+ regulator-name = "vcc_vbus_typec1";
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
+ vcc_sys: vcc-sys {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio2 RK_PA6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc_sys_en>;
+ regulator-name = "vcc_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vdd_log: vdd-log {
+ compatible = "pwm-regulator";
+ pwms = <&pwm2 0 25000 1>;
+ regulator-name = "vdd_log";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <450000>;
+ regulator-max-microvolt = <1400000>;
+ pwm-supply = <&vcc3v3_sys>;
+ };
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+ status = "okay";
+};
+
+&gmac {
+ assigned-clocks = <&cru SCLK_RMII_SRC>;
+ assigned-clock-parents = <&clkin_gmac>;
+ clock_in_out = "input";
+ phy-supply = <&vcc_lan>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 50000>;
+ tx_delay = <0x28>;
+ rx_delay = <0x11>;
+ status = "okay";
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "okay";
+};
+
+&hdmi_sound {
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <400000>;
+ i2c-scl-rising-time-ns = <168>;
+ i2c-scl-falling-time-ns = <4>;
+ status = "okay";
+
+ rk808: pmic@1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+ #clock-cells = <1>;
+ clock-output-names = "xin32k", "rk808-clkout2";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ wakeup-source;
+
+ vcc1-supply = <&vcc3v3_sys>;
+ vcc2-supply = <&vcc3v3_sys>;
+ vcc3-supply = <&vcc3v3_sys>;
+ vcc4-supply = <&vcc3v3_sys>;
+ vcc6-supply = <&vcc3v3_sys>;
+ vcc7-supply = <&vcc3v3_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc3v3_sys>;
+ vcc10-supply = <&vcc3v3_sys>;
+ vcc11-supply = <&vcc3v3_sys>;
+ vcc12-supply = <&vcc3v3_sys>;
+ vcc13-supply = <&vcc3v3_sys>;
+ vcc14-supply = <&vcc3v3_sys>;
+ vddio-supply = <&vcc_3v0>;
+
+ regulators {
+ vdd_center: DCDC_REG1 {
+ regulator-name = "vdd_center";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_l: DCDC_REG2 {
+ regulator-name = "vdd_cpu_l";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_1v8: DCDC_REG4 {
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcca1v8_codec: LDO_REG1 {
+ regulator-name = "vcca1v8_codec";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_hdmi: LDO_REG2 {
+ regulator-name = "vcc1v8_hdmi";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_pmu: LDO_REG3 {
+ regulator-name = "vcc1v8_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_sdio: LDO_REG4 {
+ regulator-name = "vcc_sdio";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcca3v0_codec: LDO_REG5 {
+ regulator-name = "vcca3v0_codec";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v5: LDO_REG6 {
+ regulator-name = "vcc_1v5";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1500000>;
+ };
+ };
+
+ vcca0v9_hdmi: LDO_REG7 {
+ regulator-name = "vcca0v9_hdmi";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v0: LDO_REG8 {
+ regulator-name = "vcc_3v0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcc3v3_s3: vcc_lan: SWITCH_REG1 {
+ regulator-name = "vcc3v3_s3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_s0: SWITCH_REG2 {
+ regulator-name = "vcc3v3_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+
+ vdd_cpu_b: regulator@40 {
+ compatible = "silergy,syr827";
+ reg = <0x40>;
+ fcs,suspend-voltage-selector = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vsel1_gpio>;
+ regulator-name = "vdd_cpu_b";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc3v3_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: regulator@41 {
+ compatible = "silergy,syr828";
+ reg = <0x41>;
+ fcs,suspend-voltage-selector = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vsel2_gpio>;
+ regulator-name = "vdd_gpu";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ vin-supply = <&vcc3v3_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&i2c1 {
+ i2c-scl-rising-time-ns = <300>;
+ i2c-scl-falling-time-ns = <15>;
+ status = "okay";
+};
+
+&i2c3 {
+ i2c-scl-rising-time-ns = <450>;
+ i2c-scl-falling-time-ns = <15>;
+ status = "okay";
+};
+
+&i2c4 {
+ i2c-scl-rising-time-ns = <600>;
+ i2c-scl-falling-time-ns = <20>;
+ status = "okay";
+
+ fusb1: usb-typec@22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&fusb1_int>;
+ vbus-supply = <&vcc_vbus_typec1>;
+ status = "okay";
+ };
+};
+
+&i2c7 {
+ i2c-scl-rising-time-ns = <600>;
+ i2c-scl-falling-time-ns = <20>;
+ status = "okay";
+
+ fusb0: usb-typec@22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&fusb0_int>;
+ vbus-supply = <&vcc_vbus_typec0>;
+ status = "okay";
+ };
+};
+
+&i2s0 {
+ rockchip,playback-channels = <8>;
+ rockchip,capture-channels = <8>;
+ status = "okay";
+};
+
+&i2s1 {
+ rockchip,playback-channels = <2>;
+ rockchip,capture-channels = <2>;
+ status = "okay";
+};
+
+&i2s2 {
+ status = "okay";
+};
+
+&io_domains {
+ audio-supply = <&vcca1v8_codec>;
+ bt656-supply = <&vcc_3v0>;
+ gpio1830-supply = <&vcc_3v0>;
+ sdmmc-supply = <&vcc_sdio>;
+ status = "okay";
+};
+
+&pmu_io_domains {
+ pmu1830-supply = <&vcc_3v0>;
+ status = "okay";
+};
+
+&pinctrl {
+ buttons {
+ pwr_key_l: pwr-key-l {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ lcd-panel {
+ lcd_panel_reset: lcd-panel-reset {
+ rockchip,pins = <4 RK_PD5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ leds {
+ diy_led_gpio: diy_led-gpio {
+ rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ work_led_gpio: work_led-gpio {
+ rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ yellow_led_gpio: yellow_led-gpio {
+ rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ vsel1_gpio: vsel1-gpio {
+ rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ vsel2_gpio: vsel2-gpio {
+ rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ sdio-pwrseq {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ sdmmc {
+ vcc3v0_sd_en: vcc3v0-sd-en {
+ rockchip,pins = <4 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ usb2 {
+ vcc5v0_host_en: vcc5v0-host-en {
+ rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ vcc_sys_en: vcc-sys-en {
+ rockchip,pins = <2 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ hub_rst: hub-rst {
+ rockchip,pins = <2 RK_PA4 RK_FUNC_GPIO &pcfg_output_high>;
+ };
+ };
+
+ usb-typec {
+ vcc_vbus_typec1_en: vcc-vbus-typec1-en {
+ rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ fusb30x {
+ fusb0_int: fusb0-int {
+ rockchip,pins = <1 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ fusb1_int: fusb1-int {
+ rockchip,pins = <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcca1v8_s3>;
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ max-frequency = <150000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc3v0_sd>;
+ vqmmc-supply = <&vcc_sdio>;
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&spi1 {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ };
+};
+
+&tcphy0 {
+ status = "okay";
+};
+
+&tcphy1 {
+ status = "okay";
+};
+
+&tsadc {
+ /* tshut mode 0:CRU 1:GPIO */
+ rockchip,hw-tshut-mode = <1>;
+ /* tshut polarity 0:LOW 1:HIGH */
+ rockchip,hw-tshut-polarity = <1>;
+ status = "okay";
+};
+
+&u2phy0 {
+ status = "okay";
+
+ u2phy0_otg: otg-port {
+ phy-supply = <&vcc_vbus_typec0>;
+ status = "okay";
+ };
+
+ u2phy0_host: host-port {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+ };
+};
+
+&u2phy1 {
+ status = "okay";
+
+ u2phy1_otg: otg-port {
+ phy-supply = <&vcc_vbus_typec1>;
+ status = "okay";
+ };
+
+ u2phy1_host: host-port {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_cts>;
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&usbdrd3_0 {
+ status = "okay";
+};
+
+&usbdrd_dwc3_0 {
+ status = "okay";
+};
+
+&usbdrd3_1 {
+ status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+ status = "okay";
+ dr_mode = "host";
+};
+
+&vopb {
+ status = "okay";
+};
+
+&vopb_mmu {
+ status = "okay";
+};
+
+&vopl {
+ status = "okay";
+};
+
+&vopl_mmu {
+ status = "okay";
+};
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 08/11] rockchip: dts: Sync ROC-RK3399-PC changes from Linux
@ 2019-12-21 7:54 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: u-boot
Sync the ROC-RK3399-PC device tree changes from Linux
with below commit details:
commit <c36308abe4110e4db362d5e2ae3797834a7b1192> ("arm64: dts:
rockchip: Enable MTD Flash on rk3399-roc-pc")
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm/dts/rk3399-roc-pc.dts | 673 +-------------------------
arch/arm/dts/rk3399-roc-pc.dtsi | 813 ++++++++++++++++++++++++++++++++
2 files changed, 816 insertions(+), 670 deletions(-)
create mode 100644 arch/arm/dts/rk3399-roc-pc.dtsi
diff --git a/arch/arm/dts/rk3399-roc-pc.dts b/arch/arm/dts/rk3399-roc-pc.dts
index 257543d069..6a909e4eef 100644
--- a/arch/arm/dts/rk3399-roc-pc.dts
+++ b/arch/arm/dts/rk3399-roc-pc.dts
@@ -4,677 +4,10 @@
*/
/dts-v1/;
-#include <dt-bindings/pwm/pwm.h>
-#include "rk3399.dtsi"
-#include "rk3399-opp.dtsi"
+#include "rk3399-roc-pc.dtsi"
/ {
model = "Firefly ROC-RK3399-PC Board";
- compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
-
- chosen {
- stdout-path = "serial2:1500000n8";
- };
-
- backlight: backlight {
- compatible = "pwm-backlight";
- pwms = <&pwm0 0 25000 0>;
- };
-
- clkin_gmac: external-gmac-clock {
- compatible = "fixed-clock";
- clock-frequency = <125000000>;
- clock-output-names = "clkin_gmac";
- #clock-cells = <0>;
- };
-
- sdio_pwrseq: sdio-pwrseq {
- compatible = "mmc-pwrseq-simple";
- clocks = <&rk808 1>;
- clock-names = "ext_clock";
- pinctrl-names = "default";
- pinctrl-0 = <&wifi_enable_h>;
-
- /*
- * On the module itself this is one of these (depending
- * on the actual card populated):
- * - SDIO_RESET_L_WL_REG_ON
- * - PDN (power down when low)
- */
- reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
- };
-
- vcc_vbus_typec0: vcc-vbus-typec0 {
- compatible = "regulator-fixed";
- regulator-name = "vcc_vbus_typec0";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- };
-
- /*
- * should be placed inside mp8859, but not until mp8859 has
- * its own dt-binding.
- */
- dc_12v: mp8859-dcdc1 {
- compatible = "regulator-fixed";
- regulator-name = "dc_12v";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <12000000>;
- regulator-max-microvolt = <12000000>;
- vin-supply = <&vcc_vbus_typec0>;
- };
-
- /* switched by pmic_sleep */
- vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
- compatible = "regulator-fixed";
- regulator-name = "vcc1v8_s3";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- vin-supply = <&vcc_1v8>;
- };
-
- vcc3v3_sys: vcc3v3-sys {
- compatible = "regulator-fixed";
- regulator-name = "vcc3v3_sys";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- vin-supply = <&vcc_sys>;
- };
-
- /* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
- vcc5v0_host: vcc5v0-host-regulator {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&vcc5v0_host_en &hub_rst>;
- regulator-name = "vcc5v0_host";
- regulator-always-on;
- vin-supply = <&vcc_sys>;
- };
-
- vcc_vbus_typec1: vcc-vbus-typec1 {
- compatible = "regulator-fixed";
- enable-active-high;
- gpio = <&gpio1 RK_PB5 GPIO_ACTIVE_HIGH>;
- pinctrl-names = "default";
- pinctrl-0 = <&vcc_vbus_typec1_en>;
- regulator-name = "vcc_vbus_typec1";
- regulator-always-on;
- vin-supply = <&vcc_sys>;
- };
-
- vcc_sys: vcc-sys {
- compatible = "regulator-fixed";
- regulator-name = "vcc_sys";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- vin-supply = <&dc_12v>;
- };
-
- vdd_log: vdd-log {
- compatible = "pwm-regulator";
- pwms = <&pwm2 0 25000 1>;
- regulator-name = "vdd_log";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <800000>;
- regulator-max-microvolt = <1400000>;
- vin-supply = <&vcc_sys>;
- };
-};
-
-&cpu_l0 {
- cpu-supply = <&vdd_cpu_l>;
-};
-
-&cpu_l1 {
- cpu-supply = <&vdd_cpu_l>;
-};
-
-&cpu_l2 {
- cpu-supply = <&vdd_cpu_l>;
-};
-
-&cpu_l3 {
- cpu-supply = <&vdd_cpu_l>;
-};
-
-&cpu_b0 {
- cpu-supply = <&vdd_cpu_b>;
-};
-
-&cpu_b1 {
- cpu-supply = <&vdd_cpu_b>;
-};
-
-&emmc_phy {
- status = "okay";
-};
-
-&gmac {
- assigned-clocks = <&cru SCLK_RMII_SRC>;
- assigned-clock-parents = <&clkin_gmac>;
- clock_in_out = "input";
- phy-supply = <&vcc_lan>;
- phy-mode = "rgmii";
- pinctrl-names = "default";
- pinctrl-0 = <&rgmii_pins>;
- snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
- snps,reset-active-low;
- snps,reset-delays-us = <0 10000 50000>;
- tx_delay = <0x28>;
- rx_delay = <0x11>;
- status = "okay";
-};
-
-&hdmi {
- ddc-i2c-bus = <&i2c3>;
- pinctrl-names = "default";
- pinctrl-0 = <&hdmi_cec>;
- status = "okay";
-};
-
-&i2c0 {
- clock-frequency = <400000>;
- i2c-scl-rising-time-ns = <168>;
- i2c-scl-falling-time-ns = <4>;
- status = "okay";
-
- rk808: pmic at 1b {
- compatible = "rockchip,rk808";
- reg = <0x1b>;
- interrupt-parent = <&gpio1>;
- interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
- #clock-cells = <1>;
- clock-output-names = "xin32k", "rk808-clkout2";
- pinctrl-names = "default";
- pinctrl-0 = <&pmic_int_l>;
- rockchip,system-power-controller;
- wakeup-source;
-
- vcc1-supply = <&vcc_sys>;
- vcc2-supply = <&vcc_sys>;
- vcc3-supply = <&vcc_sys>;
- vcc4-supply = <&vcc_sys>;
- vcc6-supply = <&vcc_sys>;
- vcc7-supply = <&vcc_sys>;
- vcc8-supply = <&vcc3v3_sys>;
- vcc9-supply = <&vcc_sys>;
- vcc10-supply = <&vcc_sys>;
- vcc11-supply = <&vcc_sys>;
- vcc12-supply = <&vcc3v3_sys>;
- vddio-supply = <&vcc1v8_pmu>;
-
- regulators {
- vdd_center: DCDC_REG1 {
- regulator-name = "vdd_center";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <750000>;
- regulator-max-microvolt = <1350000>;
- regulator-ramp-delay = <6001>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vdd_cpu_l: DCDC_REG2 {
- regulator-name = "vdd_cpu_l";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <750000>;
- regulator-max-microvolt = <1350000>;
- regulator-ramp-delay = <6001>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc_ddr: DCDC_REG3 {
- regulator-name = "vcc_ddr";
- regulator-always-on;
- regulator-boot-on;
- regulator-state-mem {
- regulator-on-in-suspend;
- };
- };
-
- vcc_1v8: DCDC_REG4 {
- regulator-name = "vcc_1v8";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <1800000>;
- };
- };
-
- vcca1v8_codec: LDO_REG1 {
- regulator-name = "vcca1v8_codec";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc1v8_hdmi: LDO_REG2 {
- regulator-name = "vcc1v8_hdmi";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc1v8_pmu: LDO_REG3 {
- regulator-name = "vcc1v8_pmu";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <1800000>;
- };
- };
-
- vcc_sdio: LDO_REG4 {
- regulator-name = "vcc_sdio";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3000000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <3000000>;
- };
- };
-
- vcca3v0_codec: LDO_REG5 {
- regulator-name = "vcca3v0_codec";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc_1v5: LDO_REG6 {
- regulator-name = "vcc_1v5";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1500000>;
- regulator-max-microvolt = <1500000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <1500000>;
- };
- };
-
- vcca0v9_hdmi: LDO_REG7 {
- regulator-name = "vcca0v9_hdmi";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <900000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc_3v0: LDO_REG8 {
- regulator-name = "vcc_3v0";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- regulator-state-mem {
- regulator-on-in-suspend;
- regulator-suspend-microvolt = <3000000>;
- };
- };
-
- vcc3v3_s3: vcc_lan: SWITCH_REG1 {
- regulator-name = "vcc3v3_s3";
- regulator-always-on;
- regulator-boot-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcc3v3_s0: SWITCH_REG2 {
- regulator-name = "vcc3v3_s0";
- regulator-always-on;
- regulator-boot-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
- };
- };
-
- vdd_cpu_b: regulator at 40 {
- compatible = "silergy,syr827";
- reg = <0x40>;
- fcs,suspend-voltage-selector = <1>;
- pinctrl-names = "default";
- pinctrl-0 = <&vsel1_gpio>;
- regulator-name = "vdd_cpu_b";
- regulator-min-microvolt = <712500>;
- regulator-max-microvolt = <1500000>;
- regulator-ramp-delay = <1000>;
- regulator-always-on;
- regulator-boot-on;
- vin-supply = <&vcc_sys>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vdd_gpu: regulator at 41 {
- compatible = "silergy,syr828";
- reg = <0x41>;
- fcs,suspend-voltage-selector = <1>;
- pinctrl-names = "default";
- pinctrl-0 = <&vsel2_gpio>;
- regulator-name = "vdd_gpu";
- regulator-min-microvolt = <712500>;
- regulator-max-microvolt = <1500000>;
- regulator-ramp-delay = <1000>;
- regulator-always-on;
- regulator-boot-on;
- vin-supply = <&vcc_sys>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-};
-
-&i2c1 {
- i2c-scl-rising-time-ns = <300>;
- i2c-scl-falling-time-ns = <15>;
- status = "okay";
-};
-
-&i2c3 {
- i2c-scl-rising-time-ns = <450>;
- i2c-scl-falling-time-ns = <15>;
- status = "okay";
-};
-
-&i2c4 {
- i2c-scl-rising-time-ns = <600>;
- i2c-scl-falling-time-ns = <20>;
- status = "okay";
-
- fusb1: usb-typec at 22 {
- compatible = "fcs,fusb302";
- reg = <0x22>;
- interrupt-parent = <&gpio1>;
- interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&fusb1_int>;
- vbus-supply = <&vcc_vbus_typec1>;
- status = "okay";
- };
-};
-
-&i2c7 {
- i2c-scl-rising-time-ns = <600>;
- i2c-scl-falling-time-ns = <20>;
- status = "okay";
-
- fusb0: usb-typec at 22 {
- compatible = "fcs,fusb302";
- reg = <0x22>;
- interrupt-parent = <&gpio1>;
- interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&fusb0_int>;
- vbus-supply = <&vcc_vbus_typec0>;
- status = "okay";
- };
-};
-
-&i2s0 {
- rockchip,playback-channels = <8>;
- rockchip,capture-channels = <8>;
- status = "okay";
-};
-
-&i2s1 {
- rockchip,playback-channels = <2>;
- rockchip,capture-channels = <2>;
- status = "okay";
-};
-
-&i2s2 {
- status = "okay";
-};
-
-&io_domains {
- audio-supply = <&vcca1v8_codec>;
- bt656-supply = <&vcc_3v0>;
- gpio1830-supply = <&vcc_3v0>;
- sdmmc-supply = <&vcc_sdio>;
- status = "okay";
-};
-
-&pmu_io_domains {
- pmu1830-supply = <&vcc_3v0>;
- status = "okay";
-};
-
-&pinctrl {
- lcd-panel {
- lcd_panel_reset: lcd-panel-reset {
- rockchip,pins = <4 RK_PD6 RK_FUNC_GPIO &pcfg_pull_up>;
- };
- };
-
- pmic {
- vsel1_gpio: vsel1-gpio {
- rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
- };
-
- vsel2_gpio: vsel2-gpio {
- rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
- };
- };
-
- sdio-pwrseq {
- wifi_enable_h: wifi-enable-h {
- rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
-
- pmic {
- pmic_int_l: pmic-int-l {
- rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
- };
- };
-
- usb2 {
- vcc5v0_host_en: vcc5v0-host-en {
- rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
- };
-
- hub_rst: hub-rst {
- rockchip,pins = <2 RK_PA4 RK_FUNC_GPIO &pcfg_output_high>;
- };
- };
-
- usb-typec {
- vcc_vbus_typec1_en: vcc-vbus-typec1-en {
- rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
- };
- };
-
- fusb30x {
- fusb0_int: fusb0-int {
- rockchip,pins = <1 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
- };
-
- fusb1_int: fusb1-int {
- rockchip,pins = <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
- };
- };
-};
-
-&pwm0 {
- status = "okay";
-};
-
-&pwm2 {
- status = "okay";
-};
-
-&saradc {
- vref-supply = <&vcca1v8_s3>;
- status = "okay";
-};
-
-&sdmmc {
- bus-width = <4>;
- cap-mmc-highspeed;
- cap-sd-highspeed;
- cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
- disable-wp;
- max-frequency = <150000000>;
- pinctrl-names = "default";
- pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
- status = "okay";
-};
-
-&sdhci {
- bus-width = <8>;
- mmc-hs400-1_8v;
- mmc-hs400-enhanced-strobe;
- non-removable;
- status = "okay";
-};
-
-&tcphy0 {
- status = "okay";
-};
-
-&tcphy1 {
- status = "okay";
-};
-
-&tsadc {
- /* tshut mode 0:CRU 1:GPIO */
- rockchip,hw-tshut-mode = <1>;
- /* tshut polarity 0:LOW 1:HIGH */
- rockchip,hw-tshut-polarity = <1>;
- status = "okay";
-};
-
-&u2phy0 {
- status = "okay";
-
- u2phy0_otg: otg-port {
- phy-supply = <&vcc_vbus_typec0>;
- status = "okay";
- };
-
- u2phy0_host: host-port {
- phy-supply = <&vcc5v0_host>;
- status = "okay";
- };
-};
-
-&u2phy1 {
- status = "okay";
-
- u2phy1_otg: otg-port {
- phy-supply = <&vcc_vbus_typec1>;
- status = "okay";
- };
-
- u2phy1_host: host-port {
- phy-supply = <&vcc5v0_host>;
- status = "okay";
- };
-};
-
-&uart0 {
- pinctrl-names = "default";
- pinctrl-0 = <&uart0_xfer &uart0_cts>;
- status = "okay";
-};
-
-&uart2 {
- status = "okay";
-};
-
-&usb_host0_ehci {
- status = "okay";
-};
-
-&usb_host0_ohci {
- status = "okay";
-};
-
-&usb_host1_ehci {
- status = "okay";
-};
-
-&usb_host1_ohci {
- status = "okay";
-};
-
-&usbdrd3_0 {
- status = "okay";
-};
-
-&usbdrd_dwc3_0 {
- status = "okay";
-};
-
-&usbdrd3_1 {
- status = "okay";
-};
-
-&usbdrd_dwc3_1 {
- status = "okay";
- dr_mode = "host";
-};
-
-&vopb {
- status = "okay";
-};
-
-&vopb_mmu {
- status = "okay";
-};
-
-&vopl {
- status = "okay";
-};
-
-&vopl_mmu {
- status = "okay";
+ compatible = "libretech,roc-rk3399-pc", "firefly,roc-rk3399-pc",
+ "rockchip,rk3399";
};
diff --git a/arch/arm/dts/rk3399-roc-pc.dtsi b/arch/arm/dts/rk3399-roc-pc.dtsi
new file mode 100644
index 0000000000..9a1ce3a4ae
--- /dev/null
+++ b/arch/arm/dts/rk3399-roc-pc.dtsi
@@ -0,0 +1,813 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2017 T-Chip Intelligent Technology Co., Ltd
+ */
+
+/dts-v1/;
+#include <dt-bindings/input/linux-event-codes.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3399.dtsi"
+#include "rk3399-opp.dtsi"
+
+/ {
+ model = "Firefly ROC-RK3399-PC Board";
+ compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm0 0 25000 0>;
+ };
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <125000000>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1500000>;
+ poll-interval = <100>;
+
+ recovery {
+ label = "Recovery";
+ linux,code = <KEY_VENDOR>;
+ press-threshold-microvolt = <18000>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ autorepeat;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwr_key_l>;
+
+ power {
+ debounce-interval = <100>;
+ gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
+ label = "GPIO Key Power";
+ linux,code = <KEY_POWER>;
+ wakeup-source;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&work_led_gpio>, <&diy_led_gpio>, <&yellow_led_gpio>;
+
+ work-led {
+ label = "green:work";
+ gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ linux,default-trigger = "heartbeat";
+ };
+
+ diy-led {
+ label = "red:diy";
+ gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ linux,default-trigger = "mmc1";
+ };
+
+ yellow-led {
+ label = "yellow:yellow-led";
+ gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ linux,default-trigger = "mmc0";
+ };
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rk808 1>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable_h>;
+
+ /*
+ * On the module itself this is one of these (depending
+ * on the actual card populated):
+ * - SDIO_RESET_L_WL_REG_ON
+ * - PDN (power down when low)
+ */
+ reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
+ };
+
+ vcc_vbus_typec0: vcc-vbus-typec0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_vbus_typec0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ /*
+ * should be placed inside mp8859, but not until mp8859 has
+ * its own dt-binding.
+ */
+ dc_12v: mp8859-dcdc1 {
+ compatible = "regulator-fixed";
+ regulator-name = "dc_12v";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ vin-supply = <&vcc_vbus_typec0>;
+ };
+
+ /* switched by pmic_sleep */
+ vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc1v8_s3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_1v8>;
+ };
+
+ vcc3v0_sd: vcc3v0-sd {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio4 RK_PD6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc3v0_sd_en>;
+ regulator-name = "vcc3v0_sd";
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vcca_0v9: vcca-0v9 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcca_0v9";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ /* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
+ vcc5v0_host: vcc5v0-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_host_en &hub_rst>;
+ regulator-name = "vcc5v0_host";
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
+ vcc_vbus_typec1: vcc-vbus-typec1 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio1 RK_PB5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc_vbus_typec1_en>;
+ regulator-name = "vcc_vbus_typec1";
+ regulator-always-on;
+ vin-supply = <&vcc_sys>;
+ };
+
+ vcc_sys: vcc-sys {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio2 RK_PA6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc_sys_en>;
+ regulator-name = "vcc_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_12v>;
+ };
+
+ vdd_log: vdd-log {
+ compatible = "pwm-regulator";
+ pwms = <&pwm2 0 25000 1>;
+ regulator-name = "vdd_log";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <450000>;
+ regulator-max-microvolt = <1400000>;
+ pwm-supply = <&vcc3v3_sys>;
+ };
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+ status = "okay";
+};
+
+&gmac {
+ assigned-clocks = <&cru SCLK_RMII_SRC>;
+ assigned-clock-parents = <&clkin_gmac>;
+ clock_in_out = "input";
+ phy-supply = <&vcc_lan>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 50000>;
+ tx_delay = <0x28>;
+ rx_delay = <0x11>;
+ status = "okay";
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
+&hdmi {
+ ddc-i2c-bus = <&i2c3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_cec>;
+ status = "okay";
+};
+
+&hdmi_sound {
+ status = "okay";
+};
+
+&i2c0 {
+ clock-frequency = <400000>;
+ i2c-scl-rising-time-ns = <168>;
+ i2c-scl-falling-time-ns = <4>;
+ status = "okay";
+
+ rk808: pmic at 1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+ #clock-cells = <1>;
+ clock-output-names = "xin32k", "rk808-clkout2";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ wakeup-source;
+
+ vcc1-supply = <&vcc3v3_sys>;
+ vcc2-supply = <&vcc3v3_sys>;
+ vcc3-supply = <&vcc3v3_sys>;
+ vcc4-supply = <&vcc3v3_sys>;
+ vcc6-supply = <&vcc3v3_sys>;
+ vcc7-supply = <&vcc3v3_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc3v3_sys>;
+ vcc10-supply = <&vcc3v3_sys>;
+ vcc11-supply = <&vcc3v3_sys>;
+ vcc12-supply = <&vcc3v3_sys>;
+ vcc13-supply = <&vcc3v3_sys>;
+ vcc14-supply = <&vcc3v3_sys>;
+ vddio-supply = <&vcc_3v0>;
+
+ regulators {
+ vdd_center: DCDC_REG1 {
+ regulator-name = "vdd_center";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_l: DCDC_REG2 {
+ regulator-name = "vdd_cpu_l";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_1v8: DCDC_REG4 {
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcca1v8_codec: LDO_REG1 {
+ regulator-name = "vcca1v8_codec";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_hdmi: LDO_REG2 {
+ regulator-name = "vcc1v8_hdmi";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_pmu: LDO_REG3 {
+ regulator-name = "vcc1v8_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_sdio: LDO_REG4 {
+ regulator-name = "vcc_sdio";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcca3v0_codec: LDO_REG5 {
+ regulator-name = "vcca3v0_codec";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v5: LDO_REG6 {
+ regulator-name = "vcc_1v5";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1500000>;
+ };
+ };
+
+ vcca0v9_hdmi: LDO_REG7 {
+ regulator-name = "vcca0v9_hdmi";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v0: LDO_REG8 {
+ regulator-name = "vcc_3v0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcc3v3_s3: vcc_lan: SWITCH_REG1 {
+ regulator-name = "vcc3v3_s3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_s0: SWITCH_REG2 {
+ regulator-name = "vcc3v3_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+
+ vdd_cpu_b: regulator at 40 {
+ compatible = "silergy,syr827";
+ reg = <0x40>;
+ fcs,suspend-voltage-selector = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vsel1_gpio>;
+ regulator-name = "vdd_cpu_b";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc3v3_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: regulator at 41 {
+ compatible = "silergy,syr828";
+ reg = <0x41>;
+ fcs,suspend-voltage-selector = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vsel2_gpio>;
+ regulator-name = "vdd_gpu";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ vin-supply = <&vcc3v3_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+};
+
+&i2c1 {
+ i2c-scl-rising-time-ns = <300>;
+ i2c-scl-falling-time-ns = <15>;
+ status = "okay";
+};
+
+&i2c3 {
+ i2c-scl-rising-time-ns = <450>;
+ i2c-scl-falling-time-ns = <15>;
+ status = "okay";
+};
+
+&i2c4 {
+ i2c-scl-rising-time-ns = <600>;
+ i2c-scl-falling-time-ns = <20>;
+ status = "okay";
+
+ fusb1: usb-typec at 22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&fusb1_int>;
+ vbus-supply = <&vcc_vbus_typec1>;
+ status = "okay";
+ };
+};
+
+&i2c7 {
+ i2c-scl-rising-time-ns = <600>;
+ i2c-scl-falling-time-ns = <20>;
+ status = "okay";
+
+ fusb0: usb-typec at 22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&fusb0_int>;
+ vbus-supply = <&vcc_vbus_typec0>;
+ status = "okay";
+ };
+};
+
+&i2s0 {
+ rockchip,playback-channels = <8>;
+ rockchip,capture-channels = <8>;
+ status = "okay";
+};
+
+&i2s1 {
+ rockchip,playback-channels = <2>;
+ rockchip,capture-channels = <2>;
+ status = "okay";
+};
+
+&i2s2 {
+ status = "okay";
+};
+
+&io_domains {
+ audio-supply = <&vcca1v8_codec>;
+ bt656-supply = <&vcc_3v0>;
+ gpio1830-supply = <&vcc_3v0>;
+ sdmmc-supply = <&vcc_sdio>;
+ status = "okay";
+};
+
+&pmu_io_domains {
+ pmu1830-supply = <&vcc_3v0>;
+ status = "okay";
+};
+
+&pinctrl {
+ buttons {
+ pwr_key_l: pwr-key-l {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ lcd-panel {
+ lcd_panel_reset: lcd-panel-reset {
+ rockchip,pins = <4 RK_PD5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ leds {
+ diy_led_gpio: diy_led-gpio {
+ rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ work_led_gpio: work_led-gpio {
+ rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ yellow_led_gpio: yellow_led-gpio {
+ rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ vsel1_gpio: vsel1-gpio {
+ rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ vsel2_gpio: vsel2-gpio {
+ rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ sdio-pwrseq {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ sdmmc {
+ vcc3v0_sd_en: vcc3v0-sd-en {
+ rockchip,pins = <4 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ usb2 {
+ vcc5v0_host_en: vcc5v0-host-en {
+ rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ vcc_sys_en: vcc-sys-en {
+ rockchip,pins = <2 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ hub_rst: hub-rst {
+ rockchip,pins = <2 RK_PA4 RK_FUNC_GPIO &pcfg_output_high>;
+ };
+ };
+
+ usb-typec {
+ vcc_vbus_typec1_en: vcc-vbus-typec1-en {
+ rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ fusb30x {
+ fusb0_int: fusb0-int {
+ rockchip,pins = <1 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+
+ fusb1_int: fusb1-int {
+ rockchip,pins = <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcca1v8_s3>;
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ max-frequency = <150000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc3v0_sd>;
+ vqmmc-supply = <&vcc_sdio>;
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+&spi1 {
+ status = "okay";
+
+ flash at 0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <10000000>;
+ };
+};
+
+&tcphy0 {
+ status = "okay";
+};
+
+&tcphy1 {
+ status = "okay";
+};
+
+&tsadc {
+ /* tshut mode 0:CRU 1:GPIO */
+ rockchip,hw-tshut-mode = <1>;
+ /* tshut polarity 0:LOW 1:HIGH */
+ rockchip,hw-tshut-polarity = <1>;
+ status = "okay";
+};
+
+&u2phy0 {
+ status = "okay";
+
+ u2phy0_otg: otg-port {
+ phy-supply = <&vcc_vbus_typec0>;
+ status = "okay";
+ };
+
+ u2phy0_host: host-port {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+ };
+};
+
+&u2phy1 {
+ status = "okay";
+
+ u2phy1_otg: otg-port {
+ phy-supply = <&vcc_vbus_typec1>;
+ status = "okay";
+ };
+
+ u2phy1_host: host-port {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_cts>;
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&usbdrd3_0 {
+ status = "okay";
+};
+
+&usbdrd_dwc3_0 {
+ status = "okay";
+};
+
+&usbdrd3_1 {
+ status = "okay";
+};
+
+&usbdrd_dwc3_1 {
+ status = "okay";
+ dr_mode = "host";
+};
+
+&vopb {
+ status = "okay";
+};
+
+&vopb_mmu {
+ status = "okay";
+};
+
+&vopl {
+ status = "okay";
+};
+
+&vopl_mmu {
+ status = "okay";
+};
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 09/11] roc-pc-rk3399: Enable SPI Flash
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-21 7:54 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: Simon Glass, Kever Yang, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula, Jagan Teki,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Enable winbond SPI flash for ROC-PC-RK3399 board.
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 4 ++++
configs/roc-pc-rk3399_defconfig | 2 ++
2 files changed, 6 insertions(+)
diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
index 77d5cf5d3c..5746442981 100644
--- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
@@ -7,6 +7,10 @@
#include "rk3399-sdram-lpddr4-100.dtsi"
/ {
+ aliases {
+ spi0 = &spi1;
+ };
+
chosen {
u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
};
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
index 305baa712c..f37a7bda00 100644
--- a/configs/roc-pc-rk3399_defconfig
+++ b/configs/roc-pc-rk3399_defconfig
@@ -42,6 +42,8 @@ CONFIG_RAM_RK3399_LPDDR4=y
CONFIG_BAUDRATE=1500000
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYSRESET=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_ROCKCHIP_SPI=y
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_DWC3=y
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 09/11] roc-pc-rk3399: Enable SPI Flash
@ 2019-12-21 7:54 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: u-boot
Enable winbond SPI flash for ROC-PC-RK3399 board.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 4 ++++
configs/roc-pc-rk3399_defconfig | 2 ++
2 files changed, 6 insertions(+)
diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
index 77d5cf5d3c..5746442981 100644
--- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
@@ -7,6 +7,10 @@
#include "rk3399-sdram-lpddr4-100.dtsi"
/ {
+ aliases {
+ spi0 = &spi1;
+ };
+
chosen {
u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
};
diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
index 305baa712c..f37a7bda00 100644
--- a/configs/roc-pc-rk3399_defconfig
+++ b/configs/roc-pc-rk3399_defconfig
@@ -42,6 +42,8 @@ CONFIG_RAM_RK3399_LPDDR4=y
CONFIG_BAUDRATE=1500000
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYSRESET=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_ROCKCHIP_SPI=y
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_DWC3=y
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 10/11] rockpro-rk3399: Enable SPI Flash
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-21 7:54 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: Simon Glass, Kever Yang, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula, Jagan Teki,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Enable winbond SPI flash for ROC-PC-RK3399 board.
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 ++++
configs/rockpro64-rk3399_defconfig | 2 ++
2 files changed, 6 insertions(+)
diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
index 4648513ea9..deaa3efd39 100644
--- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -6,6 +6,10 @@
#include "rk3399-u-boot.dtsi"
#include "rk3399-sdram-lpddr4-100.dtsi"
/ {
+ aliases {
+ spi0 = &spi1;
+ };
+
chosen {
u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
};
diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
index 49e27c91cb..6a50ec7dbc 100644
--- a/configs/rockpro64-rk3399_defconfig
+++ b/configs/rockpro64-rk3399_defconfig
@@ -46,6 +46,8 @@ CONFIG_RAM_RK3399_LPDDR4=y
CONFIG_BAUDRATE=1500000
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYSRESET=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_ROCKCHIP_SPI=y
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_DWC3=y
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 10/11] rockpro-rk3399: Enable SPI Flash
@ 2019-12-21 7:54 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: u-boot
Enable winbond SPI flash for ROC-PC-RK3399 board.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 ++++
configs/rockpro64-rk3399_defconfig | 2 ++
2 files changed, 6 insertions(+)
diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
index 4648513ea9..deaa3efd39 100644
--- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -6,6 +6,10 @@
#include "rk3399-u-boot.dtsi"
#include "rk3399-sdram-lpddr4-100.dtsi"
/ {
+ aliases {
+ spi0 = &spi1;
+ };
+
chosen {
u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
};
diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
index 49e27c91cb..6a50ec7dbc 100644
--- a/configs/rockpro64-rk3399_defconfig
+++ b/configs/rockpro64-rk3399_defconfig
@@ -46,6 +46,8 @@ CONFIG_RAM_RK3399_LPDDR4=y
CONFIG_BAUDRATE=1500000
CONFIG_DEBUG_UART_SHIFT=2
CONFIG_SYSRESET=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_ROCKCHIP_SPI=y
CONFIG_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_DWC3=y
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 11/11] roc-rk3399-pc: Add SPI boot support
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-21 7:54 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: Simon Glass, Kever Yang, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula, Jagan Teki,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Add SPI boot support for ROC-RK3399-PC board.
This would add separate config file for SPI along
with dts changes.
Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
---
arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 12 ++++-
board/rockchip/evb_rk3399/MAINTAINERS | 2 +
configs/roc-pc-rk3399-spi_defconfig | 62 ++++++++++++++++++++++++++
3 files changed, 75 insertions(+), 1 deletion(-)
create mode 100644 configs/roc-pc-rk3399-spi_defconfig
diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
index 5746442981..6e43c7c71b 100644
--- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
@@ -11,8 +11,18 @@
spi0 = &spi1;
};
+ config {
+ u-boot,spl-payload-offset = <0x40000>; /* @ 256KB */
+ };
+
chosen {
- u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
+ u-boot,spl-boot-order = "same-as-spl", &spi_flash, &sdhci, &sdmmc;
+ };
+};
+
+&spi1 {
+ spi_flash: flash@0 {
+ u-boot,dm-pre-reloc;
};
};
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index eab4c4c525..8de6ec88f1 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -57,8 +57,10 @@ F: arch/arm/dts/rk3399-orangepi-u-boot.dtsi
ROC-RK3399-PC
M: Levin Du <djw-Efosm3t9Qi2Pt1CcHtbs0g@public.gmane.org>
+M: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
S: Maintained
F: configs/roc-pc-rk3399_defconfig
+F: configs/roc-pc-rk3399-spi_defconfig
F: arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
ROCK-PI-4
diff --git a/configs/roc-pc-rk3399-spi_defconfig b/configs/roc-pc-rk3399-spi_defconfig
new file mode 100644
index 0000000000..1fdfb10101
--- /dev/null
+++ b/configs/roc-pc-rk3399-spi_defconfig
@@ -0,0 +1,62 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_MMC_SUPPORT is not set
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SPL_TEXT_BASE=0xff8c2000
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-roc-pc"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_RAM_RK3399_LPDDR4=y
+CONFIG_BAUDRATE=1500000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_ROCKCHIP_SPI=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_ERRNO_STR=y
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* [PATCH 11/11] roc-rk3399-pc: Add SPI boot support
@ 2019-12-21 7:54 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-21 7:54 UTC (permalink / raw)
To: u-boot
Add SPI boot support for ROC-RK3399-PC board.
This would add separate config file for SPI along
with dts changes.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 12 ++++-
board/rockchip/evb_rk3399/MAINTAINERS | 2 +
configs/roc-pc-rk3399-spi_defconfig | 62 ++++++++++++++++++++++++++
3 files changed, 75 insertions(+), 1 deletion(-)
create mode 100644 configs/roc-pc-rk3399-spi_defconfig
diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
index 5746442981..6e43c7c71b 100644
--- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
@@ -11,8 +11,18 @@
spi0 = &spi1;
};
+ config {
+ u-boot,spl-payload-offset = <0x40000>; /* @ 256KB */
+ };
+
chosen {
- u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
+ u-boot,spl-boot-order = "same-as-spl", &spi_flash, &sdhci, &sdmmc;
+ };
+};
+
+&spi1 {
+ spi_flash: flash at 0 {
+ u-boot,dm-pre-reloc;
};
};
diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
index eab4c4c525..8de6ec88f1 100644
--- a/board/rockchip/evb_rk3399/MAINTAINERS
+++ b/board/rockchip/evb_rk3399/MAINTAINERS
@@ -57,8 +57,10 @@ F: arch/arm/dts/rk3399-orangepi-u-boot.dtsi
ROC-RK3399-PC
M: Levin Du <djw@t-chip.com.cn>
+M: Jagan Teki <jagan@amarulasolutions.com>
S: Maintained
F: configs/roc-pc-rk3399_defconfig
+F: configs/roc-pc-rk3399-spi_defconfig
F: arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
ROCK-PI-4
diff --git a/configs/roc-pc-rk3399-spi_defconfig b/configs/roc-pc-rk3399-spi_defconfig
new file mode 100644
index 0000000000..1fdfb10101
--- /dev/null
+++ b/configs/roc-pc-rk3399-spi_defconfig
@@ -0,0 +1,62 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x00200000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_DEBUG_UART_BASE=0xFF1A0000
+CONFIG_DEBUG_UART_CLOCK=24000000
+CONFIG_DEBUG_UART=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_MMC_SUPPORT is not set
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI_SUPPORT=y
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SPL_TEXT_BASE=0xff8c2000
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-roc-pc"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_DM_ETH=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_REGULATOR_RK8XX=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_RAM_RK3399_LPDDR4=y
+CONFIG_BAUDRATE=1500000
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_ROCKCHIP_SPI=y
+CONFIG_USB=y
+CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_XHCI_DWC3=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
+CONFIG_USB_HOST_ETHER=y
+CONFIG_USB_ETHER_ASIX=y
+CONFIG_USB_ETHER_ASIX88179=y
+CONFIG_USB_ETHER_MCS7830=y
+CONFIG_USB_ETHER_RTL8152=y
+CONFIG_USB_ETHER_SMSC95XX=y
+CONFIG_ERRNO_STR=y
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related [flat|nested] 91+ messages in thread
* Re: [PATCH 01/11] spi: rk: Limit transfers to (64K - 1) bytes
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-23 2:30 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-23 2:30 UTC (permalink / raw)
To: Jagan Teki, Simon Glass, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 2019/12/21 下午3:54, Jagan Teki wrote:
> The Rockchip SPI controller's length register only supports 16-bits,
> yielding a maximum length of 64KiB (the CTRLR1 register holds "length -
> 1"). Trying to transfer more than that (e.g., with a large SPI flash
> read) will cause the driver to hang.
>
> Now, it seems that while theoretically we should be able to program
> CTRLR1 with 0xffff, and get a 64KiB transfer, but that also seems to
> cause the core to choke, so stick with a maximum of 64K - 1 bytes --
> i.e., 0xffff.
>
> Note, that the size is further divided into 'minus 1' while writing
> into CTRLR1.
>
> This change fixed two different read issues,
>
> 1. sf read failure when with > 0x10000
>
> 2. Boot from SPI flash failed during spi_flash_read call in
> common/spl/spl_spi.c
>
> Observed and Tested in
> - Rockpro64 with Gigadevice flash
> - ROC-RK3399-PC with Winbond flash
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> drivers/spi/rk_spi.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/rk_spi.c b/drivers/spi/rk_spi.c
> index c04535ac44..95eeb8307a 100644
> --- a/drivers/spi/rk_spi.c
> +++ b/drivers/spi/rk_spi.c
> @@ -27,6 +27,12 @@
> /* Change to 1 to output registers at the start of each transaction */
> #define DEBUG_RK_SPI 0
>
> +/*
> + * ctrlr1 is 16-bits, so we should support lengths of 0xffff + 1. However,
> + * the controller seems to hang when given 0x10000, so stick with this for now.
> + */
> +#define ROCKCHIP_SPI_MAX_TRANLEN 0xffff
> +
> struct rockchip_spi_params {
> /* RXFIFO overruns and TXFIFO underruns stop the master clock */
> bool master_manages_fifo;
> @@ -367,7 +373,7 @@ static inline int rockchip_spi_16bit_reader(struct udevice *dev,
> * represented in CTRLR1.
> */
> if (data && data->master_manages_fifo)
> - max_chunk_size = 0x10000;
> + max_chunk_size = ROCKCHIP_SPI_MAX_TRANLEN;
>
> // rockchip_spi_configure(dev, mode, size)
> rkspi_enable_chip(regs, false);
> @@ -451,7 +457,7 @@ static int rockchip_spi_xfer(struct udevice *dev, unsigned int bitlen,
>
> /* This is the original 8bit reader/writer code */
> while (len > 0) {
> - int todo = min(len, 0x10000);
> + int todo = min(len, ROCKCHIP_SPI_MAX_TRANLEN);
>
> rkspi_enable_chip(regs, false);
> writel(todo - 1, ®s->ctrlr1);
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 01/11] spi: rk: Limit transfers to (64K - 1) bytes
@ 2019-12-23 2:30 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-23 2:30 UTC (permalink / raw)
To: u-boot
On 2019/12/21 下午3:54, Jagan Teki wrote:
> The Rockchip SPI controller's length register only supports 16-bits,
> yielding a maximum length of 64KiB (the CTRLR1 register holds "length -
> 1"). Trying to transfer more than that (e.g., with a large SPI flash
> read) will cause the driver to hang.
>
> Now, it seems that while theoretically we should be able to program
> CTRLR1 with 0xffff, and get a 64KiB transfer, but that also seems to
> cause the core to choke, so stick with a maximum of 64K - 1 bytes --
> i.e., 0xffff.
>
> Note, that the size is further divided into 'minus 1' while writing
> into CTRLR1.
>
> This change fixed two different read issues,
>
> 1. sf read failure when with > 0x10000
>
> 2. Boot from SPI flash failed during spi_flash_read call in
> common/spl/spl_spi.c
>
> Observed and Tested in
> - Rockpro64 with Gigadevice flash
> - ROC-RK3399-PC with Winbond flash
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> drivers/spi/rk_spi.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/spi/rk_spi.c b/drivers/spi/rk_spi.c
> index c04535ac44..95eeb8307a 100644
> --- a/drivers/spi/rk_spi.c
> +++ b/drivers/spi/rk_spi.c
> @@ -27,6 +27,12 @@
> /* Change to 1 to output registers at the start of each transaction */
> #define DEBUG_RK_SPI 0
>
> +/*
> + * ctrlr1 is 16-bits, so we should support lengths of 0xffff + 1. However,
> + * the controller seems to hang when given 0x10000, so stick with this for now.
> + */
> +#define ROCKCHIP_SPI_MAX_TRANLEN 0xffff
> +
> struct rockchip_spi_params {
> /* RXFIFO overruns and TXFIFO underruns stop the master clock */
> bool master_manages_fifo;
> @@ -367,7 +373,7 @@ static inline int rockchip_spi_16bit_reader(struct udevice *dev,
> * represented in CTRLR1.
> */
> if (data && data->master_manages_fifo)
> - max_chunk_size = 0x10000;
> + max_chunk_size = ROCKCHIP_SPI_MAX_TRANLEN;
>
> // rockchip_spi_configure(dev, mode, size)
> rkspi_enable_chip(regs, false);
> @@ -451,7 +457,7 @@ static int rockchip_spi_xfer(struct udevice *dev, unsigned int bitlen,
>
> /* This is the original 8bit reader/writer code */
> while (len > 0) {
> - int todo = min(len, 0x10000);
> + int todo = min(len, ROCKCHIP_SPI_MAX_TRANLEN);
>
> rkspi_enable_chip(regs, false);
> writel(todo - 1, ®s->ctrlr1);
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 07/11] env: Enable SPI flash env for rockchip
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-23 2:34 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-23 2:34 UTC (permalink / raw)
To: Jagan Teki, Simon Glass, Philipp Tomsich
Cc: u-boot, linux-amarula, linux-rockchip
Jagan,
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Most of the SPI flash devices in rockchip are 16MiB size.
>
> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> size and then start env of 8KiB would be a compatible location
> between all variants of flash sizes.
>
> This patch add env start from 0x14000 with a size of 8KiB.
What's the space map in SPI flash suppose to be? Including
tpl/spl/u-boot.itb
I would prefer to use 128KiB-8KiB as the env start address, we'd better
to avoid the
risk of overlap between the env space and the firmware space.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> env/Kconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/env/Kconfig b/env/Kconfig
> index 9416a70022..1bb3e1078e 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -489,6 +489,7 @@ config ENV_OFFSET
> depends on ENV_IS_IN_EEPROM || ENV_IS_IN_MMC || ENV_IS_IN_NAND || \
> ENV_IS_IN_SPI_FLASH
> default 0x3f8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
> + default 0x140000 if ARCH_ROCKCHIP && ENV_IS_IN_SPI_FLASH
Is this 0x140000 or 0x14000?
Thanks,
- Kever
> default 0x88000 if ARCH_SUNXI
> default 0xE0000 if ARCH_ZYNQ
> default 0x1E00000 if ARCH_ZYNQMP
> @@ -512,6 +513,7 @@ config ENV_SIZE
> default 0x40000 if ENV_IS_IN_SPI_FLASH && ARCH_ZYNQMP
> default 0x20000 if ARCH_SUNXI || ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
> default 0x8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
> + default 0x2000 if ARCH_ROCKCHIP && ENV_IS_IN_SPI_FLASH
> default 0x8000 if ARCH_ZYNQMP || ARCH_VERSAL
> default 0x4000 if ARC
> default 0x1f000
> @@ -521,6 +523,7 @@ config ENV_SIZE
> config ENV_SECT_SIZE
> hex "Environment Sector-Size"
> depends on ENV_IS_IN_FLASH || ENV_IS_IN_SPI_FLASH
> + default 0x2000 if ARCH_ROCKCHIP
> default 0x40000 if ARCH_ZYNQMP || ARCH_VERSAL
> default 0x20000 if ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
> help
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 07/11] env: Enable SPI flash env for rockchip
@ 2019-12-23 2:34 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-23 2:34 UTC (permalink / raw)
To: u-boot
Jagan,
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Most of the SPI flash devices in rockchip are 16MiB size.
>
> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> size and then start env of 8KiB would be a compatible location
> between all variants of flash sizes.
>
> This patch add env start from 0x14000 with a size of 8KiB.
What's the space map in SPI flash suppose to be? Including
tpl/spl/u-boot.itb
I would prefer to use 128KiB-8KiB as the env start address, we'd better
to avoid the
risk of overlap between the env space and the firmware space.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> env/Kconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/env/Kconfig b/env/Kconfig
> index 9416a70022..1bb3e1078e 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -489,6 +489,7 @@ config ENV_OFFSET
> depends on ENV_IS_IN_EEPROM || ENV_IS_IN_MMC || ENV_IS_IN_NAND || \
> ENV_IS_IN_SPI_FLASH
> default 0x3f8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
> + default 0x140000 if ARCH_ROCKCHIP && ENV_IS_IN_SPI_FLASH
Is this 0x140000 or 0x14000?
Thanks,
- Kever
> default 0x88000 if ARCH_SUNXI
> default 0xE0000 if ARCH_ZYNQ
> default 0x1E00000 if ARCH_ZYNQMP
> @@ -512,6 +513,7 @@ config ENV_SIZE
> default 0x40000 if ENV_IS_IN_SPI_FLASH && ARCH_ZYNQMP
> default 0x20000 if ARCH_SUNXI || ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
> default 0x8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
> + default 0x2000 if ARCH_ROCKCHIP && ENV_IS_IN_SPI_FLASH
> default 0x8000 if ARCH_ZYNQMP || ARCH_VERSAL
> default 0x4000 if ARC
> default 0x1f000
> @@ -521,6 +523,7 @@ config ENV_SIZE
> config ENV_SECT_SIZE
> hex "Environment Sector-Size"
> depends on ENV_IS_IN_FLASH || ENV_IS_IN_SPI_FLASH
> + default 0x2000 if ARCH_ROCKCHIP
> default 0x40000 if ARCH_ZYNQMP || ARCH_VERSAL
> default 0x20000 if ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
> help
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 01/11] spi: rk: Limit transfers to (64K - 1) bytes
2019-12-23 2:30 ` Kever Yang
@ 2019-12-27 5:55 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-27 5:55 UTC (permalink / raw)
To: Kever Yang; +Cc: U-Boot-Denx, linux-amarula, open list:ARM/Rockchip SoC...
On Mon, Dec 23, 2019 at 8:00 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>
>
> On 2019/12/21 下午3:54, Jagan Teki wrote:
> > The Rockchip SPI controller's length register only supports 16-bits,
> > yielding a maximum length of 64KiB (the CTRLR1 register holds "length -
> > 1"). Trying to transfer more than that (e.g., with a large SPI flash
> > read) will cause the driver to hang.
> >
> > Now, it seems that while theoretically we should be able to program
> > CTRLR1 with 0xffff, and get a 64KiB transfer, but that also seems to
> > cause the core to choke, so stick with a maximum of 64K - 1 bytes --
> > i.e., 0xffff.
> >
> > Note, that the size is further divided into 'minus 1' while writing
> > into CTRLR1.
> >
> > This change fixed two different read issues,
> >
> > 1. sf read failure when with > 0x10000
> >
> > 2. Boot from SPI flash failed during spi_flash_read call in
> > common/spl/spl_spi.c
> >
> > Observed and Tested in
> > - Rockpro64 with Gigadevice flash
> > - ROC-RK3399-PC with Winbond flash
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>
> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Applied to u-boot-spi/master
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 01/11] spi: rk: Limit transfers to (64K - 1) bytes
@ 2019-12-27 5:55 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-27 5:55 UTC (permalink / raw)
To: u-boot
On Mon, Dec 23, 2019 at 8:00 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>
>
> On 2019/12/21 下午3:54, Jagan Teki wrote:
> > The Rockchip SPI controller's length register only supports 16-bits,
> > yielding a maximum length of 64KiB (the CTRLR1 register holds "length -
> > 1"). Trying to transfer more than that (e.g., with a large SPI flash
> > read) will cause the driver to hang.
> >
> > Now, it seems that while theoretically we should be able to program
> > CTRLR1 with 0xffff, and get a 64KiB transfer, but that also seems to
> > cause the core to choke, so stick with a maximum of 64K - 1 bytes --
> > i.e., 0xffff.
> >
> > Note, that the size is further divided into 'minus 1' while writing
> > into CTRLR1.
> >
> > This change fixed two different read issues,
> >
> > 1. sf read failure when with > 0x10000
> >
> > 2. Boot from SPI flash failed during spi_flash_read call in
> > common/spl/spl_spi.c
> >
> > Observed and Tested in
> > - Rockpro64 with Gigadevice flash
> > - ROC-RK3399-PC with Winbond flash
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
>
> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Applied to u-boot-spi/master
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 07/11] env: Enable SPI flash env for rockchip
2019-12-23 2:34 ` Kever Yang
@ 2019-12-27 6:50 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-27 6:50 UTC (permalink / raw)
To: Kever Yang; +Cc: U-Boot-Denx, linux-amarula, open list:ARM/Rockchip SoC...
Hi Kever,
On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>
> Jagan,
>
>
> On 2019/12/21 下午3:54, Jagan Teki wrote:
> > Most of the SPI flash devices in rockchip are 16MiB size.
> >
> > So, keeping U-Boot proper offset start from 128MiB with 1MiB
> > size and then start env of 8KiB would be a compatible location
> > between all variants of flash sizes.
> >
> > This patch add env start from 0x14000 with a size of 8KiB.
>
> What's the space map in SPI flash suppose to be? Including
> tpl/spl/u-boot.itb
>
> I would prefer to use 128KiB-8KiB as the env start address, we'd better
> to avoid the
>
> risk of overlap between the env space and the firmware space.
Here is the 16MiB flash layout, I have used. I can see the loader1
(tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
space for it. and 8K env after loader2(u-boot). let me know your
thoughts?
0x0 - 0x8000, 32K => reserved/loader1
0x8000 - 0x40000, 224K => loader1
0x40000 - 0x140000, 1M => loader2
0x140000 - 0x142000, 8K => env
0x142000 - 0x842000, 7M => kernel
0x842000 - 0x853800, 100K => dtb
0x853800 - => root
Jagan.
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 07/11] env: Enable SPI flash env for rockchip
@ 2019-12-27 6:50 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-27 6:50 UTC (permalink / raw)
To: u-boot
Hi Kever,
On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>
> Jagan,
>
>
> On 2019/12/21 下午3:54, Jagan Teki wrote:
> > Most of the SPI flash devices in rockchip are 16MiB size.
> >
> > So, keeping U-Boot proper offset start from 128MiB with 1MiB
> > size and then start env of 8KiB would be a compatible location
> > between all variants of flash sizes.
> >
> > This patch add env start from 0x14000 with a size of 8KiB.
>
> What's the space map in SPI flash suppose to be? Including
> tpl/spl/u-boot.itb
>
> I would prefer to use 128KiB-8KiB as the env start address, we'd better
> to avoid the
>
> risk of overlap between the env space and the firmware space.
Here is the 16MiB flash layout, I have used. I can see the loader1
(tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
space for it. and 8K env after loader2(u-boot). let me know your
thoughts?
0x0 - 0x8000, 32K => reserved/loader1
0x8000 - 0x40000, 224K => loader1
0x40000 - 0x140000, 1M => loader2
0x140000 - 0x142000, 8K => env
0x142000 - 0x842000, 7M => kernel
0x842000 - 0x853800, 100K => dtb
0x853800 - => root
Jagan.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 07/11] env: Enable SPI flash env for rockchip
2019-12-27 6:50 ` Jagan Teki
@ 2019-12-27 10:02 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-27 10:02 UTC (permalink / raw)
To: Jagan Teki; +Cc: U-Boot-Denx, linux-amarula, open list:ARM/Rockchip SoC...
On 2019/12/27 下午2:50, Jagan Teki wrote:
> Hi Kever,
>
> On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>> Jagan,
>>
>>
>> On 2019/12/21 下午3:54, Jagan Teki wrote:
>>> Most of the SPI flash devices in rockchip are 16MiB size.
>>>
>>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
>>> size and then start env of 8KiB would be a compatible location
>>> between all variants of flash sizes.
>>>
>>> This patch add env start from 0x14000 with a size of 8KiB.
>> What's the space map in SPI flash suppose to be? Including
>> tpl/spl/u-boot.itb
>>
>> I would prefer to use 128KiB-8KiB as the env start address, we'd better
>> to avoid the
>>
>> risk of overlap between the env space and the firmware space.
> Here is the 16MiB flash layout, I have used. I can see the loader1
> (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> space for it. and 8K env after loader2(u-boot). let me know your
> thoughts?
>
> 0x0 - 0x8000, 32K => reserved/loader1
> 0x8000 - 0x40000, 224K => loader1
> 0x40000 - 0x140000, 1M => loader2
> 0x140000 - 0x142000, 8K => env
> 0x142000 - 0x842000, 7M => kernel
> 0x842000 - 0x853800, 100K => dtb
spi NOR need 4KB as erase size, so this may need update , other item
looks ok.
Thanks,
- Kever
> 0x853800 - => root
>
> Jagan.
>
>
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 07/11] env: Enable SPI flash env for rockchip
@ 2019-12-27 10:02 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-27 10:02 UTC (permalink / raw)
To: u-boot
On 2019/12/27 下午2:50, Jagan Teki wrote:
> Hi Kever,
>
> On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>> Jagan,
>>
>>
>> On 2019/12/21 下午3:54, Jagan Teki wrote:
>>> Most of the SPI flash devices in rockchip are 16MiB size.
>>>
>>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
>>> size and then start env of 8KiB would be a compatible location
>>> between all variants of flash sizes.
>>>
>>> This patch add env start from 0x14000 with a size of 8KiB.
>> What's the space map in SPI flash suppose to be? Including
>> tpl/spl/u-boot.itb
>>
>> I would prefer to use 128KiB-8KiB as the env start address, we'd better
>> to avoid the
>>
>> risk of overlap between the env space and the firmware space.
> Here is the 16MiB flash layout, I have used. I can see the loader1
> (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> space for it. and 8K env after loader2(u-boot). let me know your
> thoughts?
>
> 0x0 - 0x8000, 32K => reserved/loader1
> 0x8000 - 0x40000, 224K => loader1
> 0x40000 - 0x140000, 1M => loader2
> 0x140000 - 0x142000, 8K => env
> 0x142000 - 0x842000, 7M => kernel
> 0x842000 - 0x853800, 100K => dtb
spi NOR need 4KB as erase size, so this may need update , other item
looks ok.
Thanks,
- Kever
> 0x853800 - => root
>
> Jagan.
>
>
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 07/11] env: Enable SPI flash env for rockchip
2019-12-27 10:02 ` Kever Yang
@ 2019-12-27 10:10 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-27 10:10 UTC (permalink / raw)
To: Kever Yang; +Cc: U-Boot-Denx, linux-amarula, open list:ARM/Rockchip SoC...
Hi Kever,
On Fri, Dec 27, 2019 at 3:33 PM Kever Yang <kever.yang@rock-chips.com> wrote:
>
>
> On 2019/12/27 下午2:50, Jagan Teki wrote:
> > Hi Kever,
> >
> > On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
> >> Jagan,
> >>
> >>
> >> On 2019/12/21 下午3:54, Jagan Teki wrote:
> >>> Most of the SPI flash devices in rockchip are 16MiB size.
> >>>
> >>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> >>> size and then start env of 8KiB would be a compatible location
> >>> between all variants of flash sizes.
> >>>
> >>> This patch add env start from 0x14000 with a size of 8KiB.
> >> What's the space map in SPI flash suppose to be? Including
> >> tpl/spl/u-boot.itb
> >>
> >> I would prefer to use 128KiB-8KiB as the env start address, we'd better
> >> to avoid the
> >>
> >> risk of overlap between the env space and the firmware space.
> > Here is the 16MiB flash layout, I have used. I can see the loader1
> > (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> > space for it. and 8K env after loader2(u-boot). let me know your
> > thoughts?
> >
> > 0x0 - 0x8000, 32K => reserved/loader1
> > 0x8000 - 0x40000, 224K => loader1
> > 0x40000 - 0x140000, 1M => loader2
> > 0x140000 - 0x142000, 8K => env
> > 0x142000 - 0x842000, 7M => kernel
> > 0x842000 - 0x853800, 100K => dtb
>
> spi NOR need 4KB as erase size, so this may need update , other item
> looks ok.
Correct, but this indeed doesn't effect env offset and size. May be I
can document it for future reference.
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 07/11] env: Enable SPI flash env for rockchip
@ 2019-12-27 10:10 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-27 10:10 UTC (permalink / raw)
To: u-boot
Hi Kever,
On Fri, Dec 27, 2019 at 3:33 PM Kever Yang <kever.yang@rock-chips.com> wrote:
>
>
> On 2019/12/27 下午2:50, Jagan Teki wrote:
> > Hi Kever,
> >
> > On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
> >> Jagan,
> >>
> >>
> >> On 2019/12/21 下午3:54, Jagan Teki wrote:
> >>> Most of the SPI flash devices in rockchip are 16MiB size.
> >>>
> >>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> >>> size and then start env of 8KiB would be a compatible location
> >>> between all variants of flash sizes.
> >>>
> >>> This patch add env start from 0x14000 with a size of 8KiB.
> >> What's the space map in SPI flash suppose to be? Including
> >> tpl/spl/u-boot.itb
> >>
> >> I would prefer to use 128KiB-8KiB as the env start address, we'd better
> >> to avoid the
> >>
> >> risk of overlap between the env space and the firmware space.
> > Here is the 16MiB flash layout, I have used. I can see the loader1
> > (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> > space for it. and 8K env after loader2(u-boot). let me know your
> > thoughts?
> >
> > 0x0 - 0x8000, 32K => reserved/loader1
> > 0x8000 - 0x40000, 224K => loader1
> > 0x40000 - 0x140000, 1M => loader2
> > 0x140000 - 0x142000, 8K => env
> > 0x142000 - 0x842000, 7M => kernel
> > 0x842000 - 0x853800, 100K => dtb
>
> spi NOR need 4KB as erase size, so this may need update , other item
> looks ok.
Correct, but this indeed doesn't effect env offset and size. May be I
can document it for future reference.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 07/11] env: Enable SPI flash env for rockchip
2019-12-27 6:50 ` Jagan Teki
@ 2019-12-27 10:30 ` Soeren Moch
-1 siblings, 0 replies; 91+ messages in thread
From: Soeren Moch @ 2019-12-27 10:30 UTC (permalink / raw)
To: Jagan Teki, Kever Yang
Cc: U-Boot-Denx, linux-amarula, open list:ARM/Rockchip SoC...
Hi!
On 27.12.19 07:50, Jagan Teki wrote:
> Hi Kever,
>
> On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>>
>> Jagan,
>>
>>
>> On 2019/12/21 下午3:54, Jagan Teki wrote:
>>> Most of the SPI flash devices in rockchip are 16MiB size.
>>>
>>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
>>> size and then start env of 8KiB would be a compatible location
>>> between all variants of flash sizes.
>>>
>>> This patch add env start from 0x14000 with a size of 8KiB.
>>
>> What's the space map in SPI flash suppose to be? Including
>> tpl/spl/u-boot.itb
>>
>> I would prefer to use 128KiB-8KiB as the env start address, we'd better
>> to avoid the
>>
>> risk of overlap between the env space and the firmware space.
>
> Here is the 16MiB flash layout, I have used. I can see the loader1
> (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> space for it. and 8K env after loader2(u-boot). let me know your
> thoughts?
Why we cannot use the same layout as what is defined for SD/eMMC:
http://opensource.rock-chips.com/wiki_Partitions
>
> 0x0 - 0x8000, 32K => reserved/loader1
> 0x8000 - 0x40000, 224K => loader1
> 0x40000 - 0x140000, 1M => loader2
> 0x140000 - 0x142000, 8K => env
> 0x142000 - 0x842000, 7M => kernel
> 0x842000 - 0x853800, 100K => dtb
> 0x853800 - => root
These small loader1/loader2 partitions may byte us later when newer
u-boot versions only will fit for SD and not for SPI anymore.
The reserved space for kernel is already too small for normal kernel
builds today, not to mention a root filesystem.
Are there any use cases where somebody needs to place boot and root
partitions on SPI flash?
Regards,
Soeren
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 07/11] env: Enable SPI flash env for rockchip
@ 2019-12-27 10:30 ` Soeren Moch
0 siblings, 0 replies; 91+ messages in thread
From: Soeren Moch @ 2019-12-27 10:30 UTC (permalink / raw)
To: u-boot
Hi!
On 27.12.19 07:50, Jagan Teki wrote:
> Hi Kever,
>
> On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>>
>> Jagan,
>>
>>
>> On 2019/12/21 下午3:54, Jagan Teki wrote:
>>> Most of the SPI flash devices in rockchip are 16MiB size.
>>>
>>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
>>> size and then start env of 8KiB would be a compatible location
>>> between all variants of flash sizes.
>>>
>>> This patch add env start from 0x14000 with a size of 8KiB.
>>
>> What's the space map in SPI flash suppose to be? Including
>> tpl/spl/u-boot.itb
>>
>> I would prefer to use 128KiB-8KiB as the env start address, we'd better
>> to avoid the
>>
>> risk of overlap between the env space and the firmware space.
>
> Here is the 16MiB flash layout, I have used. I can see the loader1
> (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> space for it. and 8K env after loader2(u-boot). let me know your
> thoughts?
Why we cannot use the same layout as what is defined for SD/eMMC:
http://opensource.rock-chips.com/wiki_Partitions
>
> 0x0 - 0x8000, 32K => reserved/loader1
> 0x8000 - 0x40000, 224K => loader1
> 0x40000 - 0x140000, 1M => loader2
> 0x140000 - 0x142000, 8K => env
> 0x142000 - 0x842000, 7M => kernel
> 0x842000 - 0x853800, 100K => dtb
> 0x853800 - => root
These small loader1/loader2 partitions may byte us later when newer
u-boot versions only will fit for SD and not for SPI anymore.
The reserved space for kernel is already too small for normal kernel
builds today, not to mention a root filesystem.
Are there any use cases where somebody needs to place boot and root
partitions on SPI flash?
Regards,
Soeren
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 07/11] env: Enable SPI flash env for rockchip
2019-12-27 10:30 ` Soeren Moch
@ 2019-12-27 12:04 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-27 12:04 UTC (permalink / raw)
To: Soeren Moch; +Cc: U-Boot-Denx, linux-amarula, open list:ARM/Rockchip SoC...
On Fri, Dec 27, 2019 at 4:00 PM Soeren Moch <smoch@web.de> wrote:
>
> Hi!
>
> On 27.12.19 07:50, Jagan Teki wrote:
> > Hi Kever,
> >
> > On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
> >>
> >> Jagan,
> >>
> >>
> >> On 2019/12/21 下午3:54, Jagan Teki wrote:
> >>> Most of the SPI flash devices in rockchip are 16MiB size.
> >>>
> >>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> >>> size and then start env of 8KiB would be a compatible location
> >>> between all variants of flash sizes.
> >>>
> >>> This patch add env start from 0x14000 with a size of 8KiB.
> >>
> >> What's the space map in SPI flash suppose to be? Including
> >> tpl/spl/u-boot.itb
> >>
> >> I would prefer to use 128KiB-8KiB as the env start address, we'd better
> >> to avoid the
> >>
> >> risk of overlap between the env space and the firmware space.
> >
> > Here is the 16MiB flash layout, I have used. I can see the loader1
> > (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> > space for it. and 8K env after loader2(u-boot). let me know your
> > thoughts?
>
> Why we cannot use the same layout as what is defined for SD/eMMC:
> http://opensource.rock-chips.com/wiki_Partitions
>
>
>
> >
> > 0x0 - 0x8000, 32K => reserved/loader1
> > 0x8000 - 0x40000, 224K => loader1
> > 0x40000 - 0x140000, 1M => loader2
> > 0x140000 - 0x142000, 8K => env
> > 0x142000 - 0x842000, 7M => kernel
> > 0x842000 - 0x853800, 100K => dtb
> > 0x853800 - => root
>
> These small loader1/loader2 partitions may byte us later when newer
> u-boot versions only will fit for SD and not for SPI anymore.
Yes, the initial idea is to reuse the existing SD layout but the SPI
flash is limited in size, and it is further limited in rk3399 boards
(rockpro64, roc-rk3399-pc..). which is 16MiB. So reusing half of the
flash size will occupy for till loader2 in SD scheme.
>
> The reserved space for kernel is already too small for normal kernel
> builds today, not to mention a root filesystem.
>
> Are there any use cases where somebody needs to place boot and root
> partitions on SPI flash?
So, explained above due to size limitation the respective blocks like
kernel, root (we can say initrd) are indeed less-sized partitions.
Moreover SPI flash is not a suitable storage for rootfs in rockchip,
since the boot order start from SPI flash usually board would boot
from flash and then look for SD, eMMC, PCIe NVM for loading big chunk
rootfs.
More or less the idea of above flash layout is to fit properly
with-in-the size boundaries and indeed for small initramfs systems.
Jagan.
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 07/11] env: Enable SPI flash env for rockchip
@ 2019-12-27 12:04 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-27 12:04 UTC (permalink / raw)
To: u-boot
On Fri, Dec 27, 2019 at 4:00 PM Soeren Moch <smoch@web.de> wrote:
>
> Hi!
>
> On 27.12.19 07:50, Jagan Teki wrote:
> > Hi Kever,
> >
> > On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
> >>
> >> Jagan,
> >>
> >>
> >> On 2019/12/21 下午3:54, Jagan Teki wrote:
> >>> Most of the SPI flash devices in rockchip are 16MiB size.
> >>>
> >>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> >>> size and then start env of 8KiB would be a compatible location
> >>> between all variants of flash sizes.
> >>>
> >>> This patch add env start from 0x14000 with a size of 8KiB.
> >>
> >> What's the space map in SPI flash suppose to be? Including
> >> tpl/spl/u-boot.itb
> >>
> >> I would prefer to use 128KiB-8KiB as the env start address, we'd better
> >> to avoid the
> >>
> >> risk of overlap between the env space and the firmware space.
> >
> > Here is the 16MiB flash layout, I have used. I can see the loader1
> > (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> > space for it. and 8K env after loader2(u-boot). let me know your
> > thoughts?
>
> Why we cannot use the same layout as what is defined for SD/eMMC:
> http://opensource.rock-chips.com/wiki_Partitions
>
>
>
> >
> > 0x0 - 0x8000, 32K => reserved/loader1
> > 0x8000 - 0x40000, 224K => loader1
> > 0x40000 - 0x140000, 1M => loader2
> > 0x140000 - 0x142000, 8K => env
> > 0x142000 - 0x842000, 7M => kernel
> > 0x842000 - 0x853800, 100K => dtb
> > 0x853800 - => root
>
> These small loader1/loader2 partitions may byte us later when newer
> u-boot versions only will fit for SD and not for SPI anymore.
Yes, the initial idea is to reuse the existing SD layout but the SPI
flash is limited in size, and it is further limited in rk3399 boards
(rockpro64, roc-rk3399-pc..). which is 16MiB. So reusing half of the
flash size will occupy for till loader2 in SD scheme.
>
> The reserved space for kernel is already too small for normal kernel
> builds today, not to mention a root filesystem.
>
> Are there any use cases where somebody needs to place boot and root
> partitions on SPI flash?
So, explained above due to size limitation the respective blocks like
kernel, root (we can say initrd) are indeed less-sized partitions.
Moreover SPI flash is not a suitable storage for rootfs in rockchip,
since the boot order start from SPI flash usually board would boot
from flash and then look for SD, eMMC, PCIe NVM for loading big chunk
rootfs.
More or less the idea of above flash layout is to fit properly
with-in-the size boundaries and indeed for small initramfs systems.
Jagan.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 07/11] env: Enable SPI flash env for rockchip
2019-12-27 12:04 ` Jagan Teki
@ 2019-12-27 13:19 ` Soeren Moch
-1 siblings, 0 replies; 91+ messages in thread
From: Soeren Moch @ 2019-12-27 13:19 UTC (permalink / raw)
To: Jagan Teki; +Cc: U-Boot-Denx, linux-amarula, open list:ARM/Rockchip SoC...
On 27.12.19 13:04, Jagan Teki wrote:
> On Fri, Dec 27, 2019 at 4:00 PM Soeren Moch <smoch@web.de> wrote:
>> Hi!
>>
>> On 27.12.19 07:50, Jagan Teki wrote:
>>> Hi Kever,
>>>
>>> On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>>>> Jagan,
>>>>
>>>>
>>>> On 2019/12/21 下午3:54, Jagan Teki wrote:
>>>>> Most of the SPI flash devices in rockchip are 16MiB size.
>>>>>
>>>>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
>>>>> size and then start env of 8KiB would be a compatible location
>>>>> between all variants of flash sizes.
>>>>>
>>>>> This patch add env start from 0x14000 with a size of 8KiB.
>>>> What's the space map in SPI flash suppose to be? Including
>>>> tpl/spl/u-boot.itb
>>>>
>>>> I would prefer to use 128KiB-8KiB as the env start address, we'd better
>>>> to avoid the
>>>>
>>>> risk of overlap between the env space and the firmware space.
>>> Here is the 16MiB flash layout, I have used. I can see the loader1
>>> (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
>>> space for it. and 8K env after loader2(u-boot). let me know your
>>> thoughts?
>> Why we cannot use the same layout as what is defined for SD/eMMC:
>> http://opensource.rock-chips.com/wiki_Partitions
>>
>>
>>
>>> 0x0 - 0x8000, 32K => reserved/loader1
>>> 0x8000 - 0x40000, 224K => loader1
>>> 0x40000 - 0x140000, 1M => loader2
>>> 0x140000 - 0x142000, 8K => env
>>> 0x142000 - 0x842000, 7M => kernel
>>> 0x842000 - 0x853800, 100K => dtb
>>> 0x853800 - => root
>> These small loader1/loader2 partitions may byte us later when newer
>> u-boot versions only will fit for SD and not for SPI anymore.
> Yes, the initial idea is to reuse the existing SD layout but the SPI
> flash is limited in size, and it is further limited in rk3399 boards
> (rockpro64, roc-rk3399-pc..). which is 16MiB. So reusing half of the
> flash size will occupy for till loader2 in SD scheme.
Exactly. On my RockPro64 SPI flash size is 16MiB. This covers everything
up to "boot", especially loader1, loader2, and U-Boot ENV. Probably the
SPI on these boards is sized this way to exactly match this use case.
What should be the advantage of only using half of the available memory?
>> The reserved space for kernel is already too small for normal kernel
>> builds today, not to mention a root filesystem.
>>
>> Are there any use cases where somebody needs to place boot and root
>> partitions on SPI flash?
> So, explained above due to size limitation the respective blocks like
> kernel, root (we can say initrd) are indeed less-sized partitions.
> Moreover SPI flash is not a suitable storage for rootfs in rockchip,
> since the boot order start from SPI flash usually board would boot
> from flash and then look for SD, eMMC, PCIe NVM for loading big chunk
> rootfs.
>
> More or less the idea of above flash layout is to fit properly
> with-in-the size boundaries and indeed for small initramfs systems.
We use distroboot in the defconfigs of these boards, so no separate
space for kernel or initrd is required in (raw) flash, these blobs are
always loaded from the boot partition instead.
Besides that, kernels for my RockPro64 are bigger (12MiB - 20MiB) than
the availbale space in SPI anyway, with additional ~5MiB for initrd.
My use case for SPI would be to store u-boot+SPL+TPL+ATF+environment
there, so that I can use a single combined root+boot partition on a SD
card / USB disk.
So I think the easiest, least confusing, and future-proof SPI partition
scheme would be to use exactly what is defined already for SD/eMMC.
Soeren
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 07/11] env: Enable SPI flash env for rockchip
@ 2019-12-27 13:19 ` Soeren Moch
0 siblings, 0 replies; 91+ messages in thread
From: Soeren Moch @ 2019-12-27 13:19 UTC (permalink / raw)
To: u-boot
On 27.12.19 13:04, Jagan Teki wrote:
> On Fri, Dec 27, 2019 at 4:00 PM Soeren Moch <smoch@web.de> wrote:
>> Hi!
>>
>> On 27.12.19 07:50, Jagan Teki wrote:
>>> Hi Kever,
>>>
>>> On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>>>> Jagan,
>>>>
>>>>
>>>> On 2019/12/21 下午3:54, Jagan Teki wrote:
>>>>> Most of the SPI flash devices in rockchip are 16MiB size.
>>>>>
>>>>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
>>>>> size and then start env of 8KiB would be a compatible location
>>>>> between all variants of flash sizes.
>>>>>
>>>>> This patch add env start from 0x14000 with a size of 8KiB.
>>>> What's the space map in SPI flash suppose to be? Including
>>>> tpl/spl/u-boot.itb
>>>>
>>>> I would prefer to use 128KiB-8KiB as the env start address, we'd better
>>>> to avoid the
>>>>
>>>> risk of overlap between the env space and the firmware space.
>>> Here is the 16MiB flash layout, I have used. I can see the loader1
>>> (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
>>> space for it. and 8K env after loader2(u-boot). let me know your
>>> thoughts?
>> Why we cannot use the same layout as what is defined for SD/eMMC:
>> http://opensource.rock-chips.com/wiki_Partitions
>>
>>
>>
>>> 0x0 - 0x8000, 32K => reserved/loader1
>>> 0x8000 - 0x40000, 224K => loader1
>>> 0x40000 - 0x140000, 1M => loader2
>>> 0x140000 - 0x142000, 8K => env
>>> 0x142000 - 0x842000, 7M => kernel
>>> 0x842000 - 0x853800, 100K => dtb
>>> 0x853800 - => root
>> These small loader1/loader2 partitions may byte us later when newer
>> u-boot versions only will fit for SD and not for SPI anymore.
> Yes, the initial idea is to reuse the existing SD layout but the SPI
> flash is limited in size, and it is further limited in rk3399 boards
> (rockpro64, roc-rk3399-pc..). which is 16MiB. So reusing half of the
> flash size will occupy for till loader2 in SD scheme.
Exactly. On my RockPro64 SPI flash size is 16MiB. This covers everything
up to "boot", especially loader1, loader2, and U-Boot ENV. Probably the
SPI on these boards is sized this way to exactly match this use case.
What should be the advantage of only using half of the available memory?
>> The reserved space for kernel is already too small for normal kernel
>> builds today, not to mention a root filesystem.
>>
>> Are there any use cases where somebody needs to place boot and root
>> partitions on SPI flash?
> So, explained above due to size limitation the respective blocks like
> kernel, root (we can say initrd) are indeed less-sized partitions.
> Moreover SPI flash is not a suitable storage for rootfs in rockchip,
> since the boot order start from SPI flash usually board would boot
> from flash and then look for SD, eMMC, PCIe NVM for loading big chunk
> rootfs.
>
> More or less the idea of above flash layout is to fit properly
> with-in-the size boundaries and indeed for small initramfs systems.
We use distroboot in the defconfigs of these boards, so no separate
space for kernel or initrd is required in (raw) flash, these blobs are
always loaded from the boot partition instead.
Besides that, kernels for my RockPro64 are bigger (12MiB - 20MiB) than
the availbale space in SPI anyway, with additional ~5MiB for initrd.
My use case for SPI would be to store u-boot+SPL+TPL+ATF+environment
there, so that I can use a single combined root+boot partition on a SD
card / USB disk.
So I think the easiest, least confusing, and future-proof SPI partition
scheme would be to use exactly what is defined already for SD/eMMC.
Soeren
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 07/11] env: Enable SPI flash env for rockchip
2019-12-27 13:19 ` Soeren Moch
@ 2019-12-28 12:08 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-28 12:08 UTC (permalink / raw)
To: Soeren Moch
Cc: U-Boot-Denx, linux-amarula, Kever Yang, open list:ARM/Rockchip SoC...
On Fri, Dec 27, 2019 at 6:49 PM Soeren Moch <smoch@web.de> wrote:
>
>
>
> On 27.12.19 13:04, Jagan Teki wrote:
> > On Fri, Dec 27, 2019 at 4:00 PM Soeren Moch <smoch@web.de> wrote:
> >> Hi!
> >>
> >> On 27.12.19 07:50, Jagan Teki wrote:
> >>> Hi Kever,
> >>>
> >>> On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
> >>>> Jagan,
> >>>>
> >>>>
> >>>> On 2019/12/21 下午3:54, Jagan Teki wrote:
> >>>>> Most of the SPI flash devices in rockchip are 16MiB size.
> >>>>>
> >>>>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> >>>>> size and then start env of 8KiB would be a compatible location
> >>>>> between all variants of flash sizes.
> >>>>>
> >>>>> This patch add env start from 0x14000 with a size of 8KiB.
> >>>> What's the space map in SPI flash suppose to be? Including
> >>>> tpl/spl/u-boot.itb
> >>>>
> >>>> I would prefer to use 128KiB-8KiB as the env start address, we'd better
> >>>> to avoid the
> >>>>
> >>>> risk of overlap between the env space and the firmware space.
> >>> Here is the 16MiB flash layout, I have used. I can see the loader1
> >>> (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> >>> space for it. and 8K env after loader2(u-boot). let me know your
> >>> thoughts?
> >> Why we cannot use the same layout as what is defined for SD/eMMC:
> >> http://opensource.rock-chips.com/wiki_Partitions
> >>
> >>
> >>
> >>> 0x0 - 0x8000, 32K => reserved/loader1
> >>> 0x8000 - 0x40000, 224K => loader1
> >>> 0x40000 - 0x140000, 1M => loader2
> >>> 0x140000 - 0x142000, 8K => env
> >>> 0x142000 - 0x842000, 7M => kernel
> >>> 0x842000 - 0x853800, 100K => dtb
> >>> 0x853800 - => root
> >> These small loader1/loader2 partitions may byte us later when newer
> >> u-boot versions only will fit for SD and not for SPI anymore.
> > Yes, the initial idea is to reuse the existing SD layout but the SPI
> > flash is limited in size, and it is further limited in rk3399 boards
> > (rockpro64, roc-rk3399-pc..). which is 16MiB. So reusing half of the
> > flash size will occupy for till loader2 in SD scheme.
> Exactly. On my RockPro64 SPI flash size is 16MiB. This covers everything
> up to "boot", especially loader1, loader2, and U-Boot ENV. Probably the
> SPI on these boards is sized this way to exactly match this use case.
> What should be the advantage of only using half of the available memory?
To make small systems to full use of Flash. unlike distros, the
embedded systems that run just with initramfs. Or any update mechanism
in systems to make flash boot as an update agent and SD or other
mediums as main systems.
> >> The reserved space for kernel is already too small for normal kernel
> >> builds today, not to mention a root filesystem.
> >>
> >> Are there any use cases where somebody needs to place boot and root
> >> partitions on SPI flash?
> > So, explained above due to size limitation the respective blocks like
> > kernel, root (we can say initrd) are indeed less-sized partitions.
> > Moreover SPI flash is not a suitable storage for rootfs in rockchip,
> > since the boot order start from SPI flash usually board would boot
> > from flash and then look for SD, eMMC, PCIe NVM for loading big chunk
> > rootfs.
> >
> > More or less the idea of above flash layout is to fit properly
> > with-in-the size boundaries and indeed for small initramfs systems.
> We use distroboot in the defconfigs of these boards, so no separate
> space for kernel or initrd is required in (raw) flash, these blobs are
> always loaded from the boot partition instead.
> Besides that, kernels for my RockPro64 are bigger (12MiB - 20MiB) than
> the availbale space in SPI anyway, with additional ~5MiB for initrd.
As I explained above. So, we can skip Linux, rootfs from flash and
make use of flash layout that compatible between all systems. what is
the issue with that other than future proof with SD layout.
I understand your point, but each and every storage medium can have
it's own usage to make use of full system running. So the partition
layout would depend on the size and file systems but it shouldn't
depend on particular software usage, IMHO.
>
> My use case for SPI would be to store u-boot+SPL+TPL+ATF+environment
> there, so that I can use a single combined root+boot partition on a SD
> card / USB disk.
> So I think the easiest, least confusing, and future-proof SPI partition
> scheme would be to use exactly what is defined already for SD/eMMC.
Less confused in terms of maintenance and easy to understand but it
may not be used for some corner cases like smaller systems.
Jagan.
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 07/11] env: Enable SPI flash env for rockchip
@ 2019-12-28 12:08 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-28 12:08 UTC (permalink / raw)
To: u-boot
On Fri, Dec 27, 2019 at 6:49 PM Soeren Moch <smoch@web.de> wrote:
>
>
>
> On 27.12.19 13:04, Jagan Teki wrote:
> > On Fri, Dec 27, 2019 at 4:00 PM Soeren Moch <smoch@web.de> wrote:
> >> Hi!
> >>
> >> On 27.12.19 07:50, Jagan Teki wrote:
> >>> Hi Kever,
> >>>
> >>> On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
> >>>> Jagan,
> >>>>
> >>>>
> >>>> On 2019/12/21 下午3:54, Jagan Teki wrote:
> >>>>> Most of the SPI flash devices in rockchip are 16MiB size.
> >>>>>
> >>>>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> >>>>> size and then start env of 8KiB would be a compatible location
> >>>>> between all variants of flash sizes.
> >>>>>
> >>>>> This patch add env start from 0x14000 with a size of 8KiB.
> >>>> What's the space map in SPI flash suppose to be? Including
> >>>> tpl/spl/u-boot.itb
> >>>>
> >>>> I would prefer to use 128KiB-8KiB as the env start address, we'd better
> >>>> to avoid the
> >>>>
> >>>> risk of overlap between the env space and the firmware space.
> >>> Here is the 16MiB flash layout, I have used. I can see the loader1
> >>> (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
> >>> space for it. and 8K env after loader2(u-boot). let me know your
> >>> thoughts?
> >> Why we cannot use the same layout as what is defined for SD/eMMC:
> >> http://opensource.rock-chips.com/wiki_Partitions
> >>
> >>
> >>
> >>> 0x0 - 0x8000, 32K => reserved/loader1
> >>> 0x8000 - 0x40000, 224K => loader1
> >>> 0x40000 - 0x140000, 1M => loader2
> >>> 0x140000 - 0x142000, 8K => env
> >>> 0x142000 - 0x842000, 7M => kernel
> >>> 0x842000 - 0x853800, 100K => dtb
> >>> 0x853800 - => root
> >> These small loader1/loader2 partitions may byte us later when newer
> >> u-boot versions only will fit for SD and not for SPI anymore.
> > Yes, the initial idea is to reuse the existing SD layout but the SPI
> > flash is limited in size, and it is further limited in rk3399 boards
> > (rockpro64, roc-rk3399-pc..). which is 16MiB. So reusing half of the
> > flash size will occupy for till loader2 in SD scheme.
> Exactly. On my RockPro64 SPI flash size is 16MiB. This covers everything
> up to "boot", especially loader1, loader2, and U-Boot ENV. Probably the
> SPI on these boards is sized this way to exactly match this use case.
> What should be the advantage of only using half of the available memory?
To make small systems to full use of Flash. unlike distros, the
embedded systems that run just with initramfs. Or any update mechanism
in systems to make flash boot as an update agent and SD or other
mediums as main systems.
> >> The reserved space for kernel is already too small for normal kernel
> >> builds today, not to mention a root filesystem.
> >>
> >> Are there any use cases where somebody needs to place boot and root
> >> partitions on SPI flash?
> > So, explained above due to size limitation the respective blocks like
> > kernel, root (we can say initrd) are indeed less-sized partitions.
> > Moreover SPI flash is not a suitable storage for rootfs in rockchip,
> > since the boot order start from SPI flash usually board would boot
> > from flash and then look for SD, eMMC, PCIe NVM for loading big chunk
> > rootfs.
> >
> > More or less the idea of above flash layout is to fit properly
> > with-in-the size boundaries and indeed for small initramfs systems.
> We use distroboot in the defconfigs of these boards, so no separate
> space for kernel or initrd is required in (raw) flash, these blobs are
> always loaded from the boot partition instead.
> Besides that, kernels for my RockPro64 are bigger (12MiB - 20MiB) than
> the availbale space in SPI anyway, with additional ~5MiB for initrd.
As I explained above. So, we can skip Linux, rootfs from flash and
make use of flash layout that compatible between all systems. what is
the issue with that other than future proof with SD layout.
I understand your point, but each and every storage medium can have
it's own usage to make use of full system running. So the partition
layout would depend on the size and file systems but it shouldn't
depend on particular software usage, IMHO.
>
> My use case for SPI would be to store u-boot+SPL+TPL+ATF+environment
> there, so that I can use a single combined root+boot partition on a SD
> card / USB disk.
> So I think the easiest, least confusing, and future-proof SPI partition
> scheme would be to use exactly what is defined already for SD/eMMC.
Less confused in terms of maintenance and easy to understand but it
may not be used for some corner cases like smaller systems.
Jagan.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 07/11] env: Enable SPI flash env for rockchip
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-30 2:59 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 2:59 UTC (permalink / raw)
To: Jagan Teki, Simon Glass, Philipp Tomsich
Cc: u-boot, linux-amarula, linux-rockchip
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Most of the SPI flash devices in rockchip are 16MiB size.
>
> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> size and then start env of 8KiB would be a compatible location
> between all variants of flash sizes.
>
> This patch add env start from 0x14000 with a size of 8KiB.
You can add my review tag after update this 0x140000 typo.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> env/Kconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/env/Kconfig b/env/Kconfig
> index 9416a70022..1bb3e1078e 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -489,6 +489,7 @@ config ENV_OFFSET
> depends on ENV_IS_IN_EEPROM || ENV_IS_IN_MMC || ENV_IS_IN_NAND || \
> ENV_IS_IN_SPI_FLASH
> default 0x3f8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
> + default 0x140000 if ARCH_ROCKCHIP && ENV_IS_IN_SPI_FLASH
> default 0x88000 if ARCH_SUNXI
> default 0xE0000 if ARCH_ZYNQ
> default 0x1E00000 if ARCH_ZYNQMP
> @@ -512,6 +513,7 @@ config ENV_SIZE
> default 0x40000 if ENV_IS_IN_SPI_FLASH && ARCH_ZYNQMP
> default 0x20000 if ARCH_SUNXI || ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
> default 0x8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
> + default 0x2000 if ARCH_ROCKCHIP && ENV_IS_IN_SPI_FLASH
> default 0x8000 if ARCH_ZYNQMP || ARCH_VERSAL
> default 0x4000 if ARC
> default 0x1f000
> @@ -521,6 +523,7 @@ config ENV_SIZE
> config ENV_SECT_SIZE
> hex "Environment Sector-Size"
> depends on ENV_IS_IN_FLASH || ENV_IS_IN_SPI_FLASH
> + default 0x2000 if ARCH_ROCKCHIP
> default 0x40000 if ARCH_ZYNQMP || ARCH_VERSAL
> default 0x20000 if ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
> help
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 07/11] env: Enable SPI flash env for rockchip
@ 2019-12-30 2:59 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 2:59 UTC (permalink / raw)
To: u-boot
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Most of the SPI flash devices in rockchip are 16MiB size.
>
> So, keeping U-Boot proper offset start from 128MiB with 1MiB
> size and then start env of 8KiB would be a compatible location
> between all variants of flash sizes.
>
> This patch add env start from 0x14000 with a size of 8KiB.
You can add my review tag after update this 0x140000 typo.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> env/Kconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/env/Kconfig b/env/Kconfig
> index 9416a70022..1bb3e1078e 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -489,6 +489,7 @@ config ENV_OFFSET
> depends on ENV_IS_IN_EEPROM || ENV_IS_IN_MMC || ENV_IS_IN_NAND || \
> ENV_IS_IN_SPI_FLASH
> default 0x3f8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
> + default 0x140000 if ARCH_ROCKCHIP && ENV_IS_IN_SPI_FLASH
> default 0x88000 if ARCH_SUNXI
> default 0xE0000 if ARCH_ZYNQ
> default 0x1E00000 if ARCH_ZYNQMP
> @@ -512,6 +513,7 @@ config ENV_SIZE
> default 0x40000 if ENV_IS_IN_SPI_FLASH && ARCH_ZYNQMP
> default 0x20000 if ARCH_SUNXI || ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
> default 0x8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
> + default 0x2000 if ARCH_ROCKCHIP && ENV_IS_IN_SPI_FLASH
> default 0x8000 if ARCH_ZYNQMP || ARCH_VERSAL
> default 0x4000 if ARC
> default 0x1f000
> @@ -521,6 +523,7 @@ config ENV_SIZE
> config ENV_SECT_SIZE
> hex "Environment Sector-Size"
> depends on ENV_IS_IN_FLASH || ENV_IS_IN_SPI_FLASH
> + default 0x2000 if ARCH_ROCKCHIP
> default 0x40000 if ARCH_ZYNQMP || ARCH_VERSAL
> default 0x20000 if ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
> help
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 08/11] rockchip: dts: Sync ROC-RK3399-PC changes from Linux
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-30 3:00 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:00 UTC (permalink / raw)
To: Jagan Teki, Simon Glass, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Sync the ROC-RK3399-PC device tree changes from Linux
> with below commit details:
>
> commit <c36308abe4110e4db362d5e2ae3797834a7b1192> ("arm64: dts:
> rockchip: Enable MTD Flash on rk3399-roc-pc")
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> arch/arm/dts/rk3399-roc-pc.dts | 673 +-------------------------
> arch/arm/dts/rk3399-roc-pc.dtsi | 813 ++++++++++++++++++++++++++++++++
> 2 files changed, 816 insertions(+), 670 deletions(-)
> create mode 100644 arch/arm/dts/rk3399-roc-pc.dtsi
>
> diff --git a/arch/arm/dts/rk3399-roc-pc.dts b/arch/arm/dts/rk3399-roc-pc.dts
> index 257543d069..6a909e4eef 100644
> --- a/arch/arm/dts/rk3399-roc-pc.dts
> +++ b/arch/arm/dts/rk3399-roc-pc.dts
> @@ -4,677 +4,10 @@
> */
>
> /dts-v1/;
> -#include <dt-bindings/pwm/pwm.h>
> -#include "rk3399.dtsi"
> -#include "rk3399-opp.dtsi"
> +#include "rk3399-roc-pc.dtsi"
>
> / {
> model = "Firefly ROC-RK3399-PC Board";
> - compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
> -
> - chosen {
> - stdout-path = "serial2:1500000n8";
> - };
> -
> - backlight: backlight {
> - compatible = "pwm-backlight";
> - pwms = <&pwm0 0 25000 0>;
> - };
> -
> - clkin_gmac: external-gmac-clock {
> - compatible = "fixed-clock";
> - clock-frequency = <125000000>;
> - clock-output-names = "clkin_gmac";
> - #clock-cells = <0>;
> - };
> -
> - sdio_pwrseq: sdio-pwrseq {
> - compatible = "mmc-pwrseq-simple";
> - clocks = <&rk808 1>;
> - clock-names = "ext_clock";
> - pinctrl-names = "default";
> - pinctrl-0 = <&wifi_enable_h>;
> -
> - /*
> - * On the module itself this is one of these (depending
> - * on the actual card populated):
> - * - SDIO_RESET_L_WL_REG_ON
> - * - PDN (power down when low)
> - */
> - reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
> - };
> -
> - vcc_vbus_typec0: vcc-vbus-typec0 {
> - compatible = "regulator-fixed";
> - regulator-name = "vcc_vbus_typec0";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <5000000>;
> - regulator-max-microvolt = <5000000>;
> - };
> -
> - /*
> - * should be placed inside mp8859, but not until mp8859 has
> - * its own dt-binding.
> - */
> - dc_12v: mp8859-dcdc1 {
> - compatible = "regulator-fixed";
> - regulator-name = "dc_12v";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <12000000>;
> - regulator-max-microvolt = <12000000>;
> - vin-supply = <&vcc_vbus_typec0>;
> - };
> -
> - /* switched by pmic_sleep */
> - vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
> - compatible = "regulator-fixed";
> - regulator-name = "vcc1v8_s3";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - vin-supply = <&vcc_1v8>;
> - };
> -
> - vcc3v3_sys: vcc3v3-sys {
> - compatible = "regulator-fixed";
> - regulator-name = "vcc3v3_sys";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - vin-supply = <&vcc_sys>;
> - };
> -
> - /* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
> - vcc5v0_host: vcc5v0-host-regulator {
> - compatible = "regulator-fixed";
> - enable-active-high;
> - gpio = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&vcc5v0_host_en &hub_rst>;
> - regulator-name = "vcc5v0_host";
> - regulator-always-on;
> - vin-supply = <&vcc_sys>;
> - };
> -
> - vcc_vbus_typec1: vcc-vbus-typec1 {
> - compatible = "regulator-fixed";
> - enable-active-high;
> - gpio = <&gpio1 RK_PB5 GPIO_ACTIVE_HIGH>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&vcc_vbus_typec1_en>;
> - regulator-name = "vcc_vbus_typec1";
> - regulator-always-on;
> - vin-supply = <&vcc_sys>;
> - };
> -
> - vcc_sys: vcc-sys {
> - compatible = "regulator-fixed";
> - regulator-name = "vcc_sys";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <5000000>;
> - regulator-max-microvolt = <5000000>;
> - vin-supply = <&dc_12v>;
> - };
> -
> - vdd_log: vdd-log {
> - compatible = "pwm-regulator";
> - pwms = <&pwm2 0 25000 1>;
> - regulator-name = "vdd_log";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <800000>;
> - regulator-max-microvolt = <1400000>;
> - vin-supply = <&vcc_sys>;
> - };
> -};
> -
> -&cpu_l0 {
> - cpu-supply = <&vdd_cpu_l>;
> -};
> -
> -&cpu_l1 {
> - cpu-supply = <&vdd_cpu_l>;
> -};
> -
> -&cpu_l2 {
> - cpu-supply = <&vdd_cpu_l>;
> -};
> -
> -&cpu_l3 {
> - cpu-supply = <&vdd_cpu_l>;
> -};
> -
> -&cpu_b0 {
> - cpu-supply = <&vdd_cpu_b>;
> -};
> -
> -&cpu_b1 {
> - cpu-supply = <&vdd_cpu_b>;
> -};
> -
> -&emmc_phy {
> - status = "okay";
> -};
> -
> -&gmac {
> - assigned-clocks = <&cru SCLK_RMII_SRC>;
> - assigned-clock-parents = <&clkin_gmac>;
> - clock_in_out = "input";
> - phy-supply = <&vcc_lan>;
> - phy-mode = "rgmii";
> - pinctrl-names = "default";
> - pinctrl-0 = <&rgmii_pins>;
> - snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
> - snps,reset-active-low;
> - snps,reset-delays-us = <0 10000 50000>;
> - tx_delay = <0x28>;
> - rx_delay = <0x11>;
> - status = "okay";
> -};
> -
> -&hdmi {
> - ddc-i2c-bus = <&i2c3>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&hdmi_cec>;
> - status = "okay";
> -};
> -
> -&i2c0 {
> - clock-frequency = <400000>;
> - i2c-scl-rising-time-ns = <168>;
> - i2c-scl-falling-time-ns = <4>;
> - status = "okay";
> -
> - rk808: pmic@1b {
> - compatible = "rockchip,rk808";
> - reg = <0x1b>;
> - interrupt-parent = <&gpio1>;
> - interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
> - #clock-cells = <1>;
> - clock-output-names = "xin32k", "rk808-clkout2";
> - pinctrl-names = "default";
> - pinctrl-0 = <&pmic_int_l>;
> - rockchip,system-power-controller;
> - wakeup-source;
> -
> - vcc1-supply = <&vcc_sys>;
> - vcc2-supply = <&vcc_sys>;
> - vcc3-supply = <&vcc_sys>;
> - vcc4-supply = <&vcc_sys>;
> - vcc6-supply = <&vcc_sys>;
> - vcc7-supply = <&vcc_sys>;
> - vcc8-supply = <&vcc3v3_sys>;
> - vcc9-supply = <&vcc_sys>;
> - vcc10-supply = <&vcc_sys>;
> - vcc11-supply = <&vcc_sys>;
> - vcc12-supply = <&vcc3v3_sys>;
> - vddio-supply = <&vcc1v8_pmu>;
> -
> - regulators {
> - vdd_center: DCDC_REG1 {
> - regulator-name = "vdd_center";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <750000>;
> - regulator-max-microvolt = <1350000>;
> - regulator-ramp-delay = <6001>;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vdd_cpu_l: DCDC_REG2 {
> - regulator-name = "vdd_cpu_l";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <750000>;
> - regulator-max-microvolt = <1350000>;
> - regulator-ramp-delay = <6001>;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vcc_ddr: DCDC_REG3 {
> - regulator-name = "vcc_ddr";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - };
> - };
> -
> - vcc_1v8: DCDC_REG4 {
> - regulator-name = "vcc_1v8";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1800000>;
> - };
> - };
> -
> - vcca1v8_codec: LDO_REG1 {
> - regulator-name = "vcca1v8_codec";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vcc1v8_hdmi: LDO_REG2 {
> - regulator-name = "vcc1v8_hdmi";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vcc1v8_pmu: LDO_REG3 {
> - regulator-name = "vcc1v8_pmu";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1800000>;
> - };
> - };
> -
> - vcc_sdio: LDO_REG4 {
> - regulator-name = "vcc_sdio";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <3000000>;
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <3000000>;
> - };
> - };
> -
> - vcca3v0_codec: LDO_REG5 {
> - regulator-name = "vcca3v0_codec";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <3000000>;
> - regulator-max-microvolt = <3000000>;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vcc_1v5: LDO_REG6 {
> - regulator-name = "vcc_1v5";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1500000>;
> - regulator-max-microvolt = <1500000>;
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1500000>;
> - };
> - };
> -
> - vcca0v9_hdmi: LDO_REG7 {
> - regulator-name = "vcca0v9_hdmi";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <900000>;
> - regulator-max-microvolt = <900000>;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vcc_3v0: LDO_REG8 {
> - regulator-name = "vcc_3v0";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <3000000>;
> - regulator-max-microvolt = <3000000>;
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <3000000>;
> - };
> - };
> -
> - vcc3v3_s3: vcc_lan: SWITCH_REG1 {
> - regulator-name = "vcc3v3_s3";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vcc3v3_s0: SWITCH_REG2 {
> - regulator-name = "vcc3v3_s0";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> - };
> - };
> -
> - vdd_cpu_b: regulator@40 {
> - compatible = "silergy,syr827";
> - reg = <0x40>;
> - fcs,suspend-voltage-selector = <1>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&vsel1_gpio>;
> - regulator-name = "vdd_cpu_b";
> - regulator-min-microvolt = <712500>;
> - regulator-max-microvolt = <1500000>;
> - regulator-ramp-delay = <1000>;
> - regulator-always-on;
> - regulator-boot-on;
> - vin-supply = <&vcc_sys>;
> -
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vdd_gpu: regulator@41 {
> - compatible = "silergy,syr828";
> - reg = <0x41>;
> - fcs,suspend-voltage-selector = <1>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&vsel2_gpio>;
> - regulator-name = "vdd_gpu";
> - regulator-min-microvolt = <712500>;
> - regulator-max-microvolt = <1500000>;
> - regulator-ramp-delay = <1000>;
> - regulator-always-on;
> - regulator-boot-on;
> - vin-supply = <&vcc_sys>;
> -
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -};
> -
> -&i2c1 {
> - i2c-scl-rising-time-ns = <300>;
> - i2c-scl-falling-time-ns = <15>;
> - status = "okay";
> -};
> -
> -&i2c3 {
> - i2c-scl-rising-time-ns = <450>;
> - i2c-scl-falling-time-ns = <15>;
> - status = "okay";
> -};
> -
> -&i2c4 {
> - i2c-scl-rising-time-ns = <600>;
> - i2c-scl-falling-time-ns = <20>;
> - status = "okay";
> -
> - fusb1: usb-typec@22 {
> - compatible = "fcs,fusb302";
> - reg = <0x22>;
> - interrupt-parent = <&gpio1>;
> - interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&fusb1_int>;
> - vbus-supply = <&vcc_vbus_typec1>;
> - status = "okay";
> - };
> -};
> -
> -&i2c7 {
> - i2c-scl-rising-time-ns = <600>;
> - i2c-scl-falling-time-ns = <20>;
> - status = "okay";
> -
> - fusb0: usb-typec@22 {
> - compatible = "fcs,fusb302";
> - reg = <0x22>;
> - interrupt-parent = <&gpio1>;
> - interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&fusb0_int>;
> - vbus-supply = <&vcc_vbus_typec0>;
> - status = "okay";
> - };
> -};
> -
> -&i2s0 {
> - rockchip,playback-channels = <8>;
> - rockchip,capture-channels = <8>;
> - status = "okay";
> -};
> -
> -&i2s1 {
> - rockchip,playback-channels = <2>;
> - rockchip,capture-channels = <2>;
> - status = "okay";
> -};
> -
> -&i2s2 {
> - status = "okay";
> -};
> -
> -&io_domains {
> - audio-supply = <&vcca1v8_codec>;
> - bt656-supply = <&vcc_3v0>;
> - gpio1830-supply = <&vcc_3v0>;
> - sdmmc-supply = <&vcc_sdio>;
> - status = "okay";
> -};
> -
> -&pmu_io_domains {
> - pmu1830-supply = <&vcc_3v0>;
> - status = "okay";
> -};
> -
> -&pinctrl {
> - lcd-panel {
> - lcd_panel_reset: lcd-panel-reset {
> - rockchip,pins = <4 RK_PD6 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> - };
> -
> - pmic {
> - vsel1_gpio: vsel1-gpio {
> - rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
> - };
> -
> - vsel2_gpio: vsel2-gpio {
> - rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
> - };
> - };
> -
> - sdio-pwrseq {
> - wifi_enable_h: wifi-enable-h {
> - rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
> - };
> - };
> -
> - pmic {
> - pmic_int_l: pmic-int-l {
> - rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> - };
> -
> - usb2 {
> - vcc5v0_host_en: vcc5v0-host-en {
> - rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
> - };
> -
> - hub_rst: hub-rst {
> - rockchip,pins = <2 RK_PA4 RK_FUNC_GPIO &pcfg_output_high>;
> - };
> - };
> -
> - usb-typec {
> - vcc_vbus_typec1_en: vcc-vbus-typec1-en {
> - rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
> - };
> - };
> -
> - fusb30x {
> - fusb0_int: fusb0-int {
> - rockchip,pins = <1 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> -
> - fusb1_int: fusb1-int {
> - rockchip,pins = <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> - };
> -};
> -
> -&pwm0 {
> - status = "okay";
> -};
> -
> -&pwm2 {
> - status = "okay";
> -};
> -
> -&saradc {
> - vref-supply = <&vcca1v8_s3>;
> - status = "okay";
> -};
> -
> -&sdmmc {
> - bus-width = <4>;
> - cap-mmc-highspeed;
> - cap-sd-highspeed;
> - cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
> - disable-wp;
> - max-frequency = <150000000>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
> - status = "okay";
> -};
> -
> -&sdhci {
> - bus-width = <8>;
> - mmc-hs400-1_8v;
> - mmc-hs400-enhanced-strobe;
> - non-removable;
> - status = "okay";
> -};
> -
> -&tcphy0 {
> - status = "okay";
> -};
> -
> -&tcphy1 {
> - status = "okay";
> -};
> -
> -&tsadc {
> - /* tshut mode 0:CRU 1:GPIO */
> - rockchip,hw-tshut-mode = <1>;
> - /* tshut polarity 0:LOW 1:HIGH */
> - rockchip,hw-tshut-polarity = <1>;
> - status = "okay";
> -};
> -
> -&u2phy0 {
> - status = "okay";
> -
> - u2phy0_otg: otg-port {
> - phy-supply = <&vcc_vbus_typec0>;
> - status = "okay";
> - };
> -
> - u2phy0_host: host-port {
> - phy-supply = <&vcc5v0_host>;
> - status = "okay";
> - };
> -};
> -
> -&u2phy1 {
> - status = "okay";
> -
> - u2phy1_otg: otg-port {
> - phy-supply = <&vcc_vbus_typec1>;
> - status = "okay";
> - };
> -
> - u2phy1_host: host-port {
> - phy-supply = <&vcc5v0_host>;
> - status = "okay";
> - };
> -};
> -
> -&uart0 {
> - pinctrl-names = "default";
> - pinctrl-0 = <&uart0_xfer &uart0_cts>;
> - status = "okay";
> -};
> -
> -&uart2 {
> - status = "okay";
> -};
> -
> -&usb_host0_ehci {
> - status = "okay";
> -};
> -
> -&usb_host0_ohci {
> - status = "okay";
> -};
> -
> -&usb_host1_ehci {
> - status = "okay";
> -};
> -
> -&usb_host1_ohci {
> - status = "okay";
> -};
> -
> -&usbdrd3_0 {
> - status = "okay";
> -};
> -
> -&usbdrd_dwc3_0 {
> - status = "okay";
> -};
> -
> -&usbdrd3_1 {
> - status = "okay";
> -};
> -
> -&usbdrd_dwc3_1 {
> - status = "okay";
> - dr_mode = "host";
> -};
> -
> -&vopb {
> - status = "okay";
> -};
> -
> -&vopb_mmu {
> - status = "okay";
> -};
> -
> -&vopl {
> - status = "okay";
> -};
> -
> -&vopl_mmu {
> - status = "okay";
> + compatible = "libretech,roc-rk3399-pc", "firefly,roc-rk3399-pc",
> + "rockchip,rk3399";
> };
> diff --git a/arch/arm/dts/rk3399-roc-pc.dtsi b/arch/arm/dts/rk3399-roc-pc.dtsi
> new file mode 100644
> index 0000000000..9a1ce3a4ae
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-roc-pc.dtsi
> @@ -0,0 +1,813 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2017 T-Chip Intelligent Technology Co., Ltd
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include <dt-bindings/pwm/pwm.h>
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + model = "Firefly ROC-RK3399-PC Board";
> + compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
> +
> + chosen {
> + stdout-path = "serial2:1500000n8";
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm0 0 25000 0>;
> + };
> +
> + clkin_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "clkin_gmac";
> + #clock-cells = <0>;
> + };
> +
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = <&saradc 1>;
> + io-channel-names = "buttons";
> + keyup-threshold-microvolt = <1500000>;
> + poll-interval = <100>;
> +
> + recovery {
> + label = "Recovery";
> + linux,code = <KEY_VENDOR>;
> + press-threshold-microvolt = <18000>;
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwr_key_l>;
> +
> + power {
> + debounce-interval = <100>;
> + gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
> + label = "GPIO Key Power";
> + linux,code = <KEY_POWER>;
> + wakeup-source;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&work_led_gpio>, <&diy_led_gpio>, <&yellow_led_gpio>;
> +
> + work-led {
> + label = "green:work";
> + gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + linux,default-trigger = "heartbeat";
> + };
> +
> + diy-led {
> + label = "red:diy";
> + gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "mmc1";
> + };
> +
> + yellow-led {
> + label = "yellow:yellow-led";
> + gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "mmc0";
> + };
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = <&rk808 1>;
> + clock-names = "ext_clock";
> + pinctrl-names = "default";
> + pinctrl-0 = <&wifi_enable_h>;
> +
> + /*
> + * On the module itself this is one of these (depending
> + * on the actual card populated):
> + * - SDIO_RESET_L_WL_REG_ON
> + * - PDN (power down when low)
> + */
> + reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
> + };
> +
> + vcc_vbus_typec0: vcc-vbus-typec0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_vbus_typec0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + };
> +
> + /*
> + * should be placed inside mp8859, but not until mp8859 has
> + * its own dt-binding.
> + */
> + dc_12v: mp8859-dcdc1 {
> + compatible = "regulator-fixed";
> + regulator-name = "dc_12v";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <12000000>;
> + regulator-max-microvolt = <12000000>;
> + vin-supply = <&vcc_vbus_typec0>;
> + };
> +
> + /* switched by pmic_sleep */
> + vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc1v8_s3";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vcc_1v8>;
> + };
> +
> + vcc3v0_sd: vcc3v0-sd {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio4 RK_PD6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc3v0_sd_en>;
> + regulator-name = "vcc3v0_sd";
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + vin-supply = <&vcc3v3_sys>;
> + };
> +
> + vcc3v3_sys: vcc3v3-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&dc_12v>;
> + };
> +
> + vcca_0v9: vcca-0v9 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcca_0v9";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> + vin-supply = <&vcc3v3_sys>;
> + };
> +
> + /* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
> + vcc5v0_host: vcc5v0-host-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc5v0_host_en &hub_rst>;
> + regulator-name = "vcc5v0_host";
> + regulator-always-on;
> + vin-supply = <&vcc_sys>;
> + };
> +
> + vcc_vbus_typec1: vcc-vbus-typec1 {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio1 RK_PB5 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc_vbus_typec1_en>;
> + regulator-name = "vcc_vbus_typec1";
> + regulator-always-on;
> + vin-supply = <&vcc_sys>;
> + };
> +
> + vcc_sys: vcc-sys {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio2 RK_PA6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc_sys_en>;
> + regulator-name = "vcc_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&dc_12v>;
> + };
> +
> + vdd_log: vdd-log {
> + compatible = "pwm-regulator";
> + pwms = <&pwm2 0 25000 1>;
> + regulator-name = "vdd_log";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <450000>;
> + regulator-max-microvolt = <1400000>;
> + pwm-supply = <&vcc3v3_sys>;
> + };
> +};
> +
> +&cpu_l0 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l1 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l2 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l3 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_b0 {
> + cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&cpu_b1 {
> + cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&emmc_phy {
> + status = "okay";
> +};
> +
> +&gmac {
> + assigned-clocks = <&cru SCLK_RMII_SRC>;
> + assigned-clock-parents = <&clkin_gmac>;
> + clock_in_out = "input";
> + phy-supply = <&vcc_lan>;
> + phy-mode = "rgmii";
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii_pins>;
> + snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
> + snps,reset-active-low;
> + snps,reset-delays-us = <0 10000 50000>;
> + tx_delay = <0x28>;
> + rx_delay = <0x11>;
> + status = "okay";
> +};
> +
> +&gpu {
> + mali-supply = <&vdd_gpu>;
> + status = "okay";
> +};
> +
> +&hdmi {
> + ddc-i2c-bus = <&i2c3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&hdmi_cec>;
> + status = "okay";
> +};
> +
> +&hdmi_sound {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + clock-frequency = <400000>;
> + i2c-scl-rising-time-ns = <168>;
> + i2c-scl-falling-time-ns = <4>;
> + status = "okay";
> +
> + rk808: pmic@1b {
> + compatible = "rockchip,rk808";
> + reg = <0x1b>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
> + #clock-cells = <1>;
> + clock-output-names = "xin32k", "rk808-clkout2";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_int_l>;
> + rockchip,system-power-controller;
> + wakeup-source;
> +
> + vcc1-supply = <&vcc3v3_sys>;
> + vcc2-supply = <&vcc3v3_sys>;
> + vcc3-supply = <&vcc3v3_sys>;
> + vcc4-supply = <&vcc3v3_sys>;
> + vcc6-supply = <&vcc3v3_sys>;
> + vcc7-supply = <&vcc3v3_sys>;
> + vcc8-supply = <&vcc3v3_sys>;
> + vcc9-supply = <&vcc3v3_sys>;
> + vcc10-supply = <&vcc3v3_sys>;
> + vcc11-supply = <&vcc3v3_sys>;
> + vcc12-supply = <&vcc3v3_sys>;
> + vcc13-supply = <&vcc3v3_sys>;
> + vcc14-supply = <&vcc3v3_sys>;
> + vddio-supply = <&vcc_3v0>;
> +
> + regulators {
> + vdd_center: DCDC_REG1 {
> + regulator-name = "vdd_center";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <6001>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdd_cpu_l: DCDC_REG2 {
> + regulator-name = "vdd_cpu_l";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <6001>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-name = "vcc_ddr";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc_1v8: DCDC_REG4 {
> + regulator-name = "vcc_1v8";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcca1v8_codec: LDO_REG1 {
> + regulator-name = "vcca1v8_codec";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc1v8_hdmi: LDO_REG2 {
> + regulator-name = "vcc1v8_hdmi";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc1v8_pmu: LDO_REG3 {
> + regulator-name = "vcc1v8_pmu";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcc_sdio: LDO_REG4 {
> + regulator-name = "vcc_sdio";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3000000>;
> + };
> + };
> +
> + vcca3v0_codec: LDO_REG5 {
> + regulator-name = "vcca3v0_codec";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_1v5: LDO_REG6 {
> + regulator-name = "vcc_1v5";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1500000>;
> + };
> + };
> +
> + vcca0v9_hdmi: LDO_REG7 {
> + regulator-name = "vcca0v9_hdmi";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_3v0: LDO_REG8 {
> + regulator-name = "vcc_3v0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3000000>;
> + };
> + };
> +
> + vcc3v3_s3: vcc_lan: SWITCH_REG1 {
> + regulator-name = "vcc3v3_s3";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc3v3_s0: SWITCH_REG2 {
> + regulator-name = "vcc3v3_s0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> + };
> + };
> +
> + vdd_cpu_b: regulator@40 {
> + compatible = "silergy,syr827";
> + reg = <0x40>;
> + fcs,suspend-voltage-selector = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vsel1_gpio>;
> + regulator-name = "vdd_cpu_b";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1500000>;
> + regulator-ramp-delay = <1000>;
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <&vcc3v3_sys>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdd_gpu: regulator@41 {
> + compatible = "silergy,syr828";
> + reg = <0x41>;
> + fcs,suspend-voltage-selector = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vsel2_gpio>;
> + regulator-name = "vdd_gpu";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1500000>;
> + regulator-ramp-delay = <1000>;
> + vin-supply = <&vcc3v3_sys>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +};
> +
> +&i2c1 {
> + i2c-scl-rising-time-ns = <300>;
> + i2c-scl-falling-time-ns = <15>;
> + status = "okay";
> +};
> +
> +&i2c3 {
> + i2c-scl-rising-time-ns = <450>;
> + i2c-scl-falling-time-ns = <15>;
> + status = "okay";
> +};
> +
> +&i2c4 {
> + i2c-scl-rising-time-ns = <600>;
> + i2c-scl-falling-time-ns = <20>;
> + status = "okay";
> +
> + fusb1: usb-typec@22 {
> + compatible = "fcs,fusb302";
> + reg = <0x22>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&fusb1_int>;
> + vbus-supply = <&vcc_vbus_typec1>;
> + status = "okay";
> + };
> +};
> +
> +&i2c7 {
> + i2c-scl-rising-time-ns = <600>;
> + i2c-scl-falling-time-ns = <20>;
> + status = "okay";
> +
> + fusb0: usb-typec@22 {
> + compatible = "fcs,fusb302";
> + reg = <0x22>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&fusb0_int>;
> + vbus-supply = <&vcc_vbus_typec0>;
> + status = "okay";
> + };
> +};
> +
> +&i2s0 {
> + rockchip,playback-channels = <8>;
> + rockchip,capture-channels = <8>;
> + status = "okay";
> +};
> +
> +&i2s1 {
> + rockchip,playback-channels = <2>;
> + rockchip,capture-channels = <2>;
> + status = "okay";
> +};
> +
> +&i2s2 {
> + status = "okay";
> +};
> +
> +&io_domains {
> + audio-supply = <&vcca1v8_codec>;
> + bt656-supply = <&vcc_3v0>;
> + gpio1830-supply = <&vcc_3v0>;
> + sdmmc-supply = <&vcc_sdio>;
> + status = "okay";
> +};
> +
> +&pmu_io_domains {
> + pmu1830-supply = <&vcc_3v0>;
> + status = "okay";
> +};
> +
> +&pinctrl {
> + buttons {
> + pwr_key_l: pwr-key-l {
> + rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + lcd-panel {
> + lcd_panel_reset: lcd-panel-reset {
> + rockchip,pins = <4 RK_PD5 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + leds {
> + diy_led_gpio: diy_led-gpio {
> + rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + work_led_gpio: work_led-gpio {
> + rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + yellow_led_gpio: yellow_led-gpio {
> + rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + vsel1_gpio: vsel1-gpio {
> + rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> +
> + vsel2_gpio: vsel2-gpio {
> + rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> + };
> +
> + sdio-pwrseq {
> + wifi_enable_h: wifi-enable-h {
> + rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + sdmmc {
> + vcc3v0_sd_en: vcc3v0-sd-en {
> + rockchip,pins = <4 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + pmic_int_l: pmic-int-l {
> + rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + usb2 {
> + vcc5v0_host_en: vcc5v0-host-en {
> + rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + vcc_sys_en: vcc-sys-en {
> + rockchip,pins = <2 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + hub_rst: hub-rst {
> + rockchip,pins = <2 RK_PA4 RK_FUNC_GPIO &pcfg_output_high>;
> + };
> + };
> +
> + usb-typec {
> + vcc_vbus_typec1_en: vcc-vbus-typec1-en {
> + rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + fusb30x {
> + fusb0_int: fusb0-int {
> + rockchip,pins = <1 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> +
> + fusb1_int: fusb1-int {
> + rockchip,pins = <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +};
> +
> +&pwm0 {
> + status = "okay";
> +};
> +
> +&pwm2 {
> + status = "okay";
> +};
> +
> +&saradc {
> + vref-supply = <&vcca1v8_s3>;
> + status = "okay";
> +};
> +
> +&sdmmc {
> + bus-width = <4>;
> + cap-sd-highspeed;
> + cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
> + disable-wp;
> + max-frequency = <150000000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
> + sd-uhs-sdr104;
> + vmmc-supply = <&vcc3v0_sd>;
> + vqmmc-supply = <&vcc_sdio>;
> + status = "okay";
> +};
> +
> +&sdhci {
> + bus-width = <8>;
> + non-removable;
> + status = "okay";
> +};
> +
> +&spi1 {
> + status = "okay";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <10000000>;
> + };
> +};
> +
> +&tcphy0 {
> + status = "okay";
> +};
> +
> +&tcphy1 {
> + status = "okay";
> +};
> +
> +&tsadc {
> + /* tshut mode 0:CRU 1:GPIO */
> + rockchip,hw-tshut-mode = <1>;
> + /* tshut polarity 0:LOW 1:HIGH */
> + rockchip,hw-tshut-polarity = <1>;
> + status = "okay";
> +};
> +
> +&u2phy0 {
> + status = "okay";
> +
> + u2phy0_otg: otg-port {
> + phy-supply = <&vcc_vbus_typec0>;
> + status = "okay";
> + };
> +
> + u2phy0_host: host-port {
> + phy-supply = <&vcc5v0_host>;
> + status = "okay";
> + };
> +};
> +
> +&u2phy1 {
> + status = "okay";
> +
> + u2phy1_otg: otg-port {
> + phy-supply = <&vcc_vbus_typec1>;
> + status = "okay";
> + };
> +
> + u2phy1_host: host-port {
> + phy-supply = <&vcc5v0_host>;
> + status = "okay";
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_xfer &uart0_cts>;
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&usb_host0_ehci {
> + status = "okay";
> +};
> +
> +&usb_host0_ohci {
> + status = "okay";
> +};
> +
> +&usb_host1_ehci {
> + status = "okay";
> +};
> +
> +&usb_host1_ohci {
> + status = "okay";
> +};
> +
> +&usbdrd3_0 {
> + status = "okay";
> +};
> +
> +&usbdrd_dwc3_0 {
> + status = "okay";
> +};
> +
> +&usbdrd3_1 {
> + status = "okay";
> +};
> +
> +&usbdrd_dwc3_1 {
> + status = "okay";
> + dr_mode = "host";
> +};
> +
> +&vopb {
> + status = "okay";
> +};
> +
> +&vopb_mmu {
> + status = "okay";
> +};
> +
> +&vopl {
> + status = "okay";
> +};
> +
> +&vopl_mmu {
> + status = "okay";
> +};
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 08/11] rockchip: dts: Sync ROC-RK3399-PC changes from Linux
@ 2019-12-30 3:00 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:00 UTC (permalink / raw)
To: u-boot
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Sync the ROC-RK3399-PC device tree changes from Linux
> with below commit details:
>
> commit <c36308abe4110e4db362d5e2ae3797834a7b1192> ("arm64: dts:
> rockchip: Enable MTD Flash on rk3399-roc-pc")
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> arch/arm/dts/rk3399-roc-pc.dts | 673 +-------------------------
> arch/arm/dts/rk3399-roc-pc.dtsi | 813 ++++++++++++++++++++++++++++++++
> 2 files changed, 816 insertions(+), 670 deletions(-)
> create mode 100644 arch/arm/dts/rk3399-roc-pc.dtsi
>
> diff --git a/arch/arm/dts/rk3399-roc-pc.dts b/arch/arm/dts/rk3399-roc-pc.dts
> index 257543d069..6a909e4eef 100644
> --- a/arch/arm/dts/rk3399-roc-pc.dts
> +++ b/arch/arm/dts/rk3399-roc-pc.dts
> @@ -4,677 +4,10 @@
> */
>
> /dts-v1/;
> -#include <dt-bindings/pwm/pwm.h>
> -#include "rk3399.dtsi"
> -#include "rk3399-opp.dtsi"
> +#include "rk3399-roc-pc.dtsi"
>
> / {
> model = "Firefly ROC-RK3399-PC Board";
> - compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
> -
> - chosen {
> - stdout-path = "serial2:1500000n8";
> - };
> -
> - backlight: backlight {
> - compatible = "pwm-backlight";
> - pwms = <&pwm0 0 25000 0>;
> - };
> -
> - clkin_gmac: external-gmac-clock {
> - compatible = "fixed-clock";
> - clock-frequency = <125000000>;
> - clock-output-names = "clkin_gmac";
> - #clock-cells = <0>;
> - };
> -
> - sdio_pwrseq: sdio-pwrseq {
> - compatible = "mmc-pwrseq-simple";
> - clocks = <&rk808 1>;
> - clock-names = "ext_clock";
> - pinctrl-names = "default";
> - pinctrl-0 = <&wifi_enable_h>;
> -
> - /*
> - * On the module itself this is one of these (depending
> - * on the actual card populated):
> - * - SDIO_RESET_L_WL_REG_ON
> - * - PDN (power down when low)
> - */
> - reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
> - };
> -
> - vcc_vbus_typec0: vcc-vbus-typec0 {
> - compatible = "regulator-fixed";
> - regulator-name = "vcc_vbus_typec0";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <5000000>;
> - regulator-max-microvolt = <5000000>;
> - };
> -
> - /*
> - * should be placed inside mp8859, but not until mp8859 has
> - * its own dt-binding.
> - */
> - dc_12v: mp8859-dcdc1 {
> - compatible = "regulator-fixed";
> - regulator-name = "dc_12v";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <12000000>;
> - regulator-max-microvolt = <12000000>;
> - vin-supply = <&vcc_vbus_typec0>;
> - };
> -
> - /* switched by pmic_sleep */
> - vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
> - compatible = "regulator-fixed";
> - regulator-name = "vcc1v8_s3";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - vin-supply = <&vcc_1v8>;
> - };
> -
> - vcc3v3_sys: vcc3v3-sys {
> - compatible = "regulator-fixed";
> - regulator-name = "vcc3v3_sys";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - vin-supply = <&vcc_sys>;
> - };
> -
> - /* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
> - vcc5v0_host: vcc5v0-host-regulator {
> - compatible = "regulator-fixed";
> - enable-active-high;
> - gpio = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&vcc5v0_host_en &hub_rst>;
> - regulator-name = "vcc5v0_host";
> - regulator-always-on;
> - vin-supply = <&vcc_sys>;
> - };
> -
> - vcc_vbus_typec1: vcc-vbus-typec1 {
> - compatible = "regulator-fixed";
> - enable-active-high;
> - gpio = <&gpio1 RK_PB5 GPIO_ACTIVE_HIGH>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&vcc_vbus_typec1_en>;
> - regulator-name = "vcc_vbus_typec1";
> - regulator-always-on;
> - vin-supply = <&vcc_sys>;
> - };
> -
> - vcc_sys: vcc-sys {
> - compatible = "regulator-fixed";
> - regulator-name = "vcc_sys";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <5000000>;
> - regulator-max-microvolt = <5000000>;
> - vin-supply = <&dc_12v>;
> - };
> -
> - vdd_log: vdd-log {
> - compatible = "pwm-regulator";
> - pwms = <&pwm2 0 25000 1>;
> - regulator-name = "vdd_log";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <800000>;
> - regulator-max-microvolt = <1400000>;
> - vin-supply = <&vcc_sys>;
> - };
> -};
> -
> -&cpu_l0 {
> - cpu-supply = <&vdd_cpu_l>;
> -};
> -
> -&cpu_l1 {
> - cpu-supply = <&vdd_cpu_l>;
> -};
> -
> -&cpu_l2 {
> - cpu-supply = <&vdd_cpu_l>;
> -};
> -
> -&cpu_l3 {
> - cpu-supply = <&vdd_cpu_l>;
> -};
> -
> -&cpu_b0 {
> - cpu-supply = <&vdd_cpu_b>;
> -};
> -
> -&cpu_b1 {
> - cpu-supply = <&vdd_cpu_b>;
> -};
> -
> -&emmc_phy {
> - status = "okay";
> -};
> -
> -&gmac {
> - assigned-clocks = <&cru SCLK_RMII_SRC>;
> - assigned-clock-parents = <&clkin_gmac>;
> - clock_in_out = "input";
> - phy-supply = <&vcc_lan>;
> - phy-mode = "rgmii";
> - pinctrl-names = "default";
> - pinctrl-0 = <&rgmii_pins>;
> - snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
> - snps,reset-active-low;
> - snps,reset-delays-us = <0 10000 50000>;
> - tx_delay = <0x28>;
> - rx_delay = <0x11>;
> - status = "okay";
> -};
> -
> -&hdmi {
> - ddc-i2c-bus = <&i2c3>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&hdmi_cec>;
> - status = "okay";
> -};
> -
> -&i2c0 {
> - clock-frequency = <400000>;
> - i2c-scl-rising-time-ns = <168>;
> - i2c-scl-falling-time-ns = <4>;
> - status = "okay";
> -
> - rk808: pmic at 1b {
> - compatible = "rockchip,rk808";
> - reg = <0x1b>;
> - interrupt-parent = <&gpio1>;
> - interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
> - #clock-cells = <1>;
> - clock-output-names = "xin32k", "rk808-clkout2";
> - pinctrl-names = "default";
> - pinctrl-0 = <&pmic_int_l>;
> - rockchip,system-power-controller;
> - wakeup-source;
> -
> - vcc1-supply = <&vcc_sys>;
> - vcc2-supply = <&vcc_sys>;
> - vcc3-supply = <&vcc_sys>;
> - vcc4-supply = <&vcc_sys>;
> - vcc6-supply = <&vcc_sys>;
> - vcc7-supply = <&vcc_sys>;
> - vcc8-supply = <&vcc3v3_sys>;
> - vcc9-supply = <&vcc_sys>;
> - vcc10-supply = <&vcc_sys>;
> - vcc11-supply = <&vcc_sys>;
> - vcc12-supply = <&vcc3v3_sys>;
> - vddio-supply = <&vcc1v8_pmu>;
> -
> - regulators {
> - vdd_center: DCDC_REG1 {
> - regulator-name = "vdd_center";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <750000>;
> - regulator-max-microvolt = <1350000>;
> - regulator-ramp-delay = <6001>;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vdd_cpu_l: DCDC_REG2 {
> - regulator-name = "vdd_cpu_l";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <750000>;
> - regulator-max-microvolt = <1350000>;
> - regulator-ramp-delay = <6001>;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vcc_ddr: DCDC_REG3 {
> - regulator-name = "vcc_ddr";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - };
> - };
> -
> - vcc_1v8: DCDC_REG4 {
> - regulator-name = "vcc_1v8";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1800000>;
> - };
> - };
> -
> - vcca1v8_codec: LDO_REG1 {
> - regulator-name = "vcca1v8_codec";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vcc1v8_hdmi: LDO_REG2 {
> - regulator-name = "vcc1v8_hdmi";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vcc1v8_pmu: LDO_REG3 {
> - regulator-name = "vcc1v8_pmu";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1800000>;
> - };
> - };
> -
> - vcc_sdio: LDO_REG4 {
> - regulator-name = "vcc_sdio";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <3000000>;
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <3000000>;
> - };
> - };
> -
> - vcca3v0_codec: LDO_REG5 {
> - regulator-name = "vcca3v0_codec";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <3000000>;
> - regulator-max-microvolt = <3000000>;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vcc_1v5: LDO_REG6 {
> - regulator-name = "vcc_1v5";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1500000>;
> - regulator-max-microvolt = <1500000>;
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1500000>;
> - };
> - };
> -
> - vcca0v9_hdmi: LDO_REG7 {
> - regulator-name = "vcca0v9_hdmi";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <900000>;
> - regulator-max-microvolt = <900000>;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vcc_3v0: LDO_REG8 {
> - regulator-name = "vcc_3v0";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <3000000>;
> - regulator-max-microvolt = <3000000>;
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <3000000>;
> - };
> - };
> -
> - vcc3v3_s3: vcc_lan: SWITCH_REG1 {
> - regulator-name = "vcc3v3_s3";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vcc3v3_s0: SWITCH_REG2 {
> - regulator-name = "vcc3v3_s0";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> - };
> - };
> -
> - vdd_cpu_b: regulator at 40 {
> - compatible = "silergy,syr827";
> - reg = <0x40>;
> - fcs,suspend-voltage-selector = <1>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&vsel1_gpio>;
> - regulator-name = "vdd_cpu_b";
> - regulator-min-microvolt = <712500>;
> - regulator-max-microvolt = <1500000>;
> - regulator-ramp-delay = <1000>;
> - regulator-always-on;
> - regulator-boot-on;
> - vin-supply = <&vcc_sys>;
> -
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vdd_gpu: regulator at 41 {
> - compatible = "silergy,syr828";
> - reg = <0x41>;
> - fcs,suspend-voltage-selector = <1>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&vsel2_gpio>;
> - regulator-name = "vdd_gpu";
> - regulator-min-microvolt = <712500>;
> - regulator-max-microvolt = <1500000>;
> - regulator-ramp-delay = <1000>;
> - regulator-always-on;
> - regulator-boot-on;
> - vin-supply = <&vcc_sys>;
> -
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -};
> -
> -&i2c1 {
> - i2c-scl-rising-time-ns = <300>;
> - i2c-scl-falling-time-ns = <15>;
> - status = "okay";
> -};
> -
> -&i2c3 {
> - i2c-scl-rising-time-ns = <450>;
> - i2c-scl-falling-time-ns = <15>;
> - status = "okay";
> -};
> -
> -&i2c4 {
> - i2c-scl-rising-time-ns = <600>;
> - i2c-scl-falling-time-ns = <20>;
> - status = "okay";
> -
> - fusb1: usb-typec at 22 {
> - compatible = "fcs,fusb302";
> - reg = <0x22>;
> - interrupt-parent = <&gpio1>;
> - interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&fusb1_int>;
> - vbus-supply = <&vcc_vbus_typec1>;
> - status = "okay";
> - };
> -};
> -
> -&i2c7 {
> - i2c-scl-rising-time-ns = <600>;
> - i2c-scl-falling-time-ns = <20>;
> - status = "okay";
> -
> - fusb0: usb-typec at 22 {
> - compatible = "fcs,fusb302";
> - reg = <0x22>;
> - interrupt-parent = <&gpio1>;
> - interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&fusb0_int>;
> - vbus-supply = <&vcc_vbus_typec0>;
> - status = "okay";
> - };
> -};
> -
> -&i2s0 {
> - rockchip,playback-channels = <8>;
> - rockchip,capture-channels = <8>;
> - status = "okay";
> -};
> -
> -&i2s1 {
> - rockchip,playback-channels = <2>;
> - rockchip,capture-channels = <2>;
> - status = "okay";
> -};
> -
> -&i2s2 {
> - status = "okay";
> -};
> -
> -&io_domains {
> - audio-supply = <&vcca1v8_codec>;
> - bt656-supply = <&vcc_3v0>;
> - gpio1830-supply = <&vcc_3v0>;
> - sdmmc-supply = <&vcc_sdio>;
> - status = "okay";
> -};
> -
> -&pmu_io_domains {
> - pmu1830-supply = <&vcc_3v0>;
> - status = "okay";
> -};
> -
> -&pinctrl {
> - lcd-panel {
> - lcd_panel_reset: lcd-panel-reset {
> - rockchip,pins = <4 RK_PD6 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> - };
> -
> - pmic {
> - vsel1_gpio: vsel1-gpio {
> - rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
> - };
> -
> - vsel2_gpio: vsel2-gpio {
> - rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
> - };
> - };
> -
> - sdio-pwrseq {
> - wifi_enable_h: wifi-enable-h {
> - rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
> - };
> - };
> -
> - pmic {
> - pmic_int_l: pmic-int-l {
> - rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> - };
> -
> - usb2 {
> - vcc5v0_host_en: vcc5v0-host-en {
> - rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
> - };
> -
> - hub_rst: hub-rst {
> - rockchip,pins = <2 RK_PA4 RK_FUNC_GPIO &pcfg_output_high>;
> - };
> - };
> -
> - usb-typec {
> - vcc_vbus_typec1_en: vcc-vbus-typec1-en {
> - rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
> - };
> - };
> -
> - fusb30x {
> - fusb0_int: fusb0-int {
> - rockchip,pins = <1 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> -
> - fusb1_int: fusb1-int {
> - rockchip,pins = <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> - };
> -};
> -
> -&pwm0 {
> - status = "okay";
> -};
> -
> -&pwm2 {
> - status = "okay";
> -};
> -
> -&saradc {
> - vref-supply = <&vcca1v8_s3>;
> - status = "okay";
> -};
> -
> -&sdmmc {
> - bus-width = <4>;
> - cap-mmc-highspeed;
> - cap-sd-highspeed;
> - cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
> - disable-wp;
> - max-frequency = <150000000>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
> - status = "okay";
> -};
> -
> -&sdhci {
> - bus-width = <8>;
> - mmc-hs400-1_8v;
> - mmc-hs400-enhanced-strobe;
> - non-removable;
> - status = "okay";
> -};
> -
> -&tcphy0 {
> - status = "okay";
> -};
> -
> -&tcphy1 {
> - status = "okay";
> -};
> -
> -&tsadc {
> - /* tshut mode 0:CRU 1:GPIO */
> - rockchip,hw-tshut-mode = <1>;
> - /* tshut polarity 0:LOW 1:HIGH */
> - rockchip,hw-tshut-polarity = <1>;
> - status = "okay";
> -};
> -
> -&u2phy0 {
> - status = "okay";
> -
> - u2phy0_otg: otg-port {
> - phy-supply = <&vcc_vbus_typec0>;
> - status = "okay";
> - };
> -
> - u2phy0_host: host-port {
> - phy-supply = <&vcc5v0_host>;
> - status = "okay";
> - };
> -};
> -
> -&u2phy1 {
> - status = "okay";
> -
> - u2phy1_otg: otg-port {
> - phy-supply = <&vcc_vbus_typec1>;
> - status = "okay";
> - };
> -
> - u2phy1_host: host-port {
> - phy-supply = <&vcc5v0_host>;
> - status = "okay";
> - };
> -};
> -
> -&uart0 {
> - pinctrl-names = "default";
> - pinctrl-0 = <&uart0_xfer &uart0_cts>;
> - status = "okay";
> -};
> -
> -&uart2 {
> - status = "okay";
> -};
> -
> -&usb_host0_ehci {
> - status = "okay";
> -};
> -
> -&usb_host0_ohci {
> - status = "okay";
> -};
> -
> -&usb_host1_ehci {
> - status = "okay";
> -};
> -
> -&usb_host1_ohci {
> - status = "okay";
> -};
> -
> -&usbdrd3_0 {
> - status = "okay";
> -};
> -
> -&usbdrd_dwc3_0 {
> - status = "okay";
> -};
> -
> -&usbdrd3_1 {
> - status = "okay";
> -};
> -
> -&usbdrd_dwc3_1 {
> - status = "okay";
> - dr_mode = "host";
> -};
> -
> -&vopb {
> - status = "okay";
> -};
> -
> -&vopb_mmu {
> - status = "okay";
> -};
> -
> -&vopl {
> - status = "okay";
> -};
> -
> -&vopl_mmu {
> - status = "okay";
> + compatible = "libretech,roc-rk3399-pc", "firefly,roc-rk3399-pc",
> + "rockchip,rk3399";
> };
> diff --git a/arch/arm/dts/rk3399-roc-pc.dtsi b/arch/arm/dts/rk3399-roc-pc.dtsi
> new file mode 100644
> index 0000000000..9a1ce3a4ae
> --- /dev/null
> +++ b/arch/arm/dts/rk3399-roc-pc.dtsi
> @@ -0,0 +1,813 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2017 T-Chip Intelligent Technology Co., Ltd
> + */
> +
> +/dts-v1/;
> +#include <dt-bindings/input/linux-event-codes.h>
> +#include <dt-bindings/pwm/pwm.h>
> +#include "rk3399.dtsi"
> +#include "rk3399-opp.dtsi"
> +
> +/ {
> + model = "Firefly ROC-RK3399-PC Board";
> + compatible = "firefly,roc-rk3399-pc", "rockchip,rk3399";
> +
> + chosen {
> + stdout-path = "serial2:1500000n8";
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm0 0 25000 0>;
> + };
> +
> + clkin_gmac: external-gmac-clock {
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "clkin_gmac";
> + #clock-cells = <0>;
> + };
> +
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = <&saradc 1>;
> + io-channel-names = "buttons";
> + keyup-threshold-microvolt = <1500000>;
> + poll-interval = <100>;
> +
> + recovery {
> + label = "Recovery";
> + linux,code = <KEY_VENDOR>;
> + press-threshold-microvolt = <18000>;
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwr_key_l>;
> +
> + power {
> + debounce-interval = <100>;
> + gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_LOW>;
> + label = "GPIO Key Power";
> + linux,code = <KEY_POWER>;
> + wakeup-source;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&work_led_gpio>, <&diy_led_gpio>, <&yellow_led_gpio>;
> +
> + work-led {
> + label = "green:work";
> + gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + linux,default-trigger = "heartbeat";
> + };
> +
> + diy-led {
> + label = "red:diy";
> + gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "mmc1";
> + };
> +
> + yellow-led {
> + label = "yellow:yellow-led";
> + gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + linux,default-trigger = "mmc0";
> + };
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = <&rk808 1>;
> + clock-names = "ext_clock";
> + pinctrl-names = "default";
> + pinctrl-0 = <&wifi_enable_h>;
> +
> + /*
> + * On the module itself this is one of these (depending
> + * on the actual card populated):
> + * - SDIO_RESET_L_WL_REG_ON
> + * - PDN (power down when low)
> + */
> + reset-gpios = <&gpio0 RK_PB2 GPIO_ACTIVE_LOW>;
> + };
> +
> + vcc_vbus_typec0: vcc-vbus-typec0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_vbus_typec0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + };
> +
> + /*
> + * should be placed inside mp8859, but not until mp8859 has
> + * its own dt-binding.
> + */
> + dc_12v: mp8859-dcdc1 {
> + compatible = "regulator-fixed";
> + regulator-name = "dc_12v";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <12000000>;
> + regulator-max-microvolt = <12000000>;
> + vin-supply = <&vcc_vbus_typec0>;
> + };
> +
> + /* switched by pmic_sleep */
> + vcc1v8_s3: vcca1v8_s3: vcc1v8-s3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc1v8_s3";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + vin-supply = <&vcc_1v8>;
> + };
> +
> + vcc3v0_sd: vcc3v0-sd {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio4 RK_PD6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc3v0_sd_en>;
> + regulator-name = "vcc3v0_sd";
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + vin-supply = <&vcc3v3_sys>;
> + };
> +
> + vcc3v3_sys: vcc3v3-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&dc_12v>;
> + };
> +
> + vcca_0v9: vcca-0v9 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcca_0v9";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> + vin-supply = <&vcc3v3_sys>;
> + };
> +
> + /* Actually 3 regulators (host0, 1, 2) controlled by the same gpio */
> + vcc5v0_host: vcc5v0-host-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc5v0_host_en &hub_rst>;
> + regulator-name = "vcc5v0_host";
> + regulator-always-on;
> + vin-supply = <&vcc_sys>;
> + };
> +
> + vcc_vbus_typec1: vcc-vbus-typec1 {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio1 RK_PB5 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc_vbus_typec1_en>;
> + regulator-name = "vcc_vbus_typec1";
> + regulator-always-on;
> + vin-supply = <&vcc_sys>;
> + };
> +
> + vcc_sys: vcc-sys {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio2 RK_PA6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc_sys_en>;
> + regulator-name = "vcc_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&dc_12v>;
> + };
> +
> + vdd_log: vdd-log {
> + compatible = "pwm-regulator";
> + pwms = <&pwm2 0 25000 1>;
> + regulator-name = "vdd_log";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <450000>;
> + regulator-max-microvolt = <1400000>;
> + pwm-supply = <&vcc3v3_sys>;
> + };
> +};
> +
> +&cpu_l0 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l1 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l2 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_l3 {
> + cpu-supply = <&vdd_cpu_l>;
> +};
> +
> +&cpu_b0 {
> + cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&cpu_b1 {
> + cpu-supply = <&vdd_cpu_b>;
> +};
> +
> +&emmc_phy {
> + status = "okay";
> +};
> +
> +&gmac {
> + assigned-clocks = <&cru SCLK_RMII_SRC>;
> + assigned-clock-parents = <&clkin_gmac>;
> + clock_in_out = "input";
> + phy-supply = <&vcc_lan>;
> + phy-mode = "rgmii";
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii_pins>;
> + snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
> + snps,reset-active-low;
> + snps,reset-delays-us = <0 10000 50000>;
> + tx_delay = <0x28>;
> + rx_delay = <0x11>;
> + status = "okay";
> +};
> +
> +&gpu {
> + mali-supply = <&vdd_gpu>;
> + status = "okay";
> +};
> +
> +&hdmi {
> + ddc-i2c-bus = <&i2c3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&hdmi_cec>;
> + status = "okay";
> +};
> +
> +&hdmi_sound {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + clock-frequency = <400000>;
> + i2c-scl-rising-time-ns = <168>;
> + i2c-scl-falling-time-ns = <4>;
> + status = "okay";
> +
> + rk808: pmic at 1b {
> + compatible = "rockchip,rk808";
> + reg = <0x1b>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
> + #clock-cells = <1>;
> + clock-output-names = "xin32k", "rk808-clkout2";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_int_l>;
> + rockchip,system-power-controller;
> + wakeup-source;
> +
> + vcc1-supply = <&vcc3v3_sys>;
> + vcc2-supply = <&vcc3v3_sys>;
> + vcc3-supply = <&vcc3v3_sys>;
> + vcc4-supply = <&vcc3v3_sys>;
> + vcc6-supply = <&vcc3v3_sys>;
> + vcc7-supply = <&vcc3v3_sys>;
> + vcc8-supply = <&vcc3v3_sys>;
> + vcc9-supply = <&vcc3v3_sys>;
> + vcc10-supply = <&vcc3v3_sys>;
> + vcc11-supply = <&vcc3v3_sys>;
> + vcc12-supply = <&vcc3v3_sys>;
> + vcc13-supply = <&vcc3v3_sys>;
> + vcc14-supply = <&vcc3v3_sys>;
> + vddio-supply = <&vcc_3v0>;
> +
> + regulators {
> + vdd_center: DCDC_REG1 {
> + regulator-name = "vdd_center";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <6001>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdd_cpu_l: DCDC_REG2 {
> + regulator-name = "vdd_cpu_l";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <750000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <6001>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-name = "vcc_ddr";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc_1v8: DCDC_REG4 {
> + regulator-name = "vcc_1v8";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcca1v8_codec: LDO_REG1 {
> + regulator-name = "vcca1v8_codec";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc1v8_hdmi: LDO_REG2 {
> + regulator-name = "vcc1v8_hdmi";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc1v8_pmu: LDO_REG3 {
> + regulator-name = "vcc1v8_pmu";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcc_sdio: LDO_REG4 {
> + regulator-name = "vcc_sdio";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3000000>;
> + };
> + };
> +
> + vcca3v0_codec: LDO_REG5 {
> + regulator-name = "vcca3v0_codec";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_1v5: LDO_REG6 {
> + regulator-name = "vcc_1v5";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <1500000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1500000>;
> + };
> + };
> +
> + vcca0v9_hdmi: LDO_REG7 {
> + regulator-name = "vcca0v9_hdmi";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_3v0: LDO_REG8 {
> + regulator-name = "vcc_3v0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3000000>;
> + };
> + };
> +
> + vcc3v3_s3: vcc_lan: SWITCH_REG1 {
> + regulator-name = "vcc3v3_s3";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc3v3_s0: SWITCH_REG2 {
> + regulator-name = "vcc3v3_s0";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> + };
> + };
> +
> + vdd_cpu_b: regulator at 40 {
> + compatible = "silergy,syr827";
> + reg = <0x40>;
> + fcs,suspend-voltage-selector = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vsel1_gpio>;
> + regulator-name = "vdd_cpu_b";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1500000>;
> + regulator-ramp-delay = <1000>;
> + regulator-always-on;
> + regulator-boot-on;
> + vin-supply = <&vcc3v3_sys>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdd_gpu: regulator at 41 {
> + compatible = "silergy,syr828";
> + reg = <0x41>;
> + fcs,suspend-voltage-selector = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vsel2_gpio>;
> + regulator-name = "vdd_gpu";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1500000>;
> + regulator-ramp-delay = <1000>;
> + vin-supply = <&vcc3v3_sys>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +};
> +
> +&i2c1 {
> + i2c-scl-rising-time-ns = <300>;
> + i2c-scl-falling-time-ns = <15>;
> + status = "okay";
> +};
> +
> +&i2c3 {
> + i2c-scl-rising-time-ns = <450>;
> + i2c-scl-falling-time-ns = <15>;
> + status = "okay";
> +};
> +
> +&i2c4 {
> + i2c-scl-rising-time-ns = <600>;
> + i2c-scl-falling-time-ns = <20>;
> + status = "okay";
> +
> + fusb1: usb-typec at 22 {
> + compatible = "fcs,fusb302";
> + reg = <0x22>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&fusb1_int>;
> + vbus-supply = <&vcc_vbus_typec1>;
> + status = "okay";
> + };
> +};
> +
> +&i2c7 {
> + i2c-scl-rising-time-ns = <600>;
> + i2c-scl-falling-time-ns = <20>;
> + status = "okay";
> +
> + fusb0: usb-typec at 22 {
> + compatible = "fcs,fusb302";
> + reg = <0x22>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&fusb0_int>;
> + vbus-supply = <&vcc_vbus_typec0>;
> + status = "okay";
> + };
> +};
> +
> +&i2s0 {
> + rockchip,playback-channels = <8>;
> + rockchip,capture-channels = <8>;
> + status = "okay";
> +};
> +
> +&i2s1 {
> + rockchip,playback-channels = <2>;
> + rockchip,capture-channels = <2>;
> + status = "okay";
> +};
> +
> +&i2s2 {
> + status = "okay";
> +};
> +
> +&io_domains {
> + audio-supply = <&vcca1v8_codec>;
> + bt656-supply = <&vcc_3v0>;
> + gpio1830-supply = <&vcc_3v0>;
> + sdmmc-supply = <&vcc_sdio>;
> + status = "okay";
> +};
> +
> +&pmu_io_domains {
> + pmu1830-supply = <&vcc_3v0>;
> + status = "okay";
> +};
> +
> +&pinctrl {
> + buttons {
> + pwr_key_l: pwr-key-l {
> + rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + lcd-panel {
> + lcd_panel_reset: lcd-panel-reset {
> + rockchip,pins = <4 RK_PD5 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + leds {
> + diy_led_gpio: diy_led-gpio {
> + rockchip,pins = <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + work_led_gpio: work_led-gpio {
> + rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + yellow_led_gpio: yellow_led-gpio {
> + rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + vsel1_gpio: vsel1-gpio {
> + rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> +
> + vsel2_gpio: vsel2-gpio {
> + rockchip,pins = <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> + };
> +
> + sdio-pwrseq {
> + wifi_enable_h: wifi-enable-h {
> + rockchip,pins = <0 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + sdmmc {
> + vcc3v0_sd_en: vcc3v0-sd-en {
> + rockchip,pins = <4 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + pmic_int_l: pmic-int-l {
> + rockchip,pins = <1 RK_PC5 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +
> + usb2 {
> + vcc5v0_host_en: vcc5v0-host-en {
> + rockchip,pins = <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + vcc_sys_en: vcc-sys-en {
> + rockchip,pins = <2 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + hub_rst: hub-rst {
> + rockchip,pins = <2 RK_PA4 RK_FUNC_GPIO &pcfg_output_high>;
> + };
> + };
> +
> + usb-typec {
> + vcc_vbus_typec1_en: vcc-vbus-typec1-en {
> + rockchip,pins = <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + fusb30x {
> + fusb0_int: fusb0-int {
> + rockchip,pins = <1 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> +
> + fusb1_int: fusb1-int {
> + rockchip,pins = <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +};
> +
> +&pwm0 {
> + status = "okay";
> +};
> +
> +&pwm2 {
> + status = "okay";
> +};
> +
> +&saradc {
> + vref-supply = <&vcca1v8_s3>;
> + status = "okay";
> +};
> +
> +&sdmmc {
> + bus-width = <4>;
> + cap-sd-highspeed;
> + cd-gpios = <&gpio0 RK_PA7 GPIO_ACTIVE_LOW>;
> + disable-wp;
> + max-frequency = <150000000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_bus4>;
> + sd-uhs-sdr104;
> + vmmc-supply = <&vcc3v0_sd>;
> + vqmmc-supply = <&vcc_sdio>;
> + status = "okay";
> +};
> +
> +&sdhci {
> + bus-width = <8>;
> + non-removable;
> + status = "okay";
> +};
> +
> +&spi1 {
> + status = "okay";
> +
> + flash at 0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <10000000>;
> + };
> +};
> +
> +&tcphy0 {
> + status = "okay";
> +};
> +
> +&tcphy1 {
> + status = "okay";
> +};
> +
> +&tsadc {
> + /* tshut mode 0:CRU 1:GPIO */
> + rockchip,hw-tshut-mode = <1>;
> + /* tshut polarity 0:LOW 1:HIGH */
> + rockchip,hw-tshut-polarity = <1>;
> + status = "okay";
> +};
> +
> +&u2phy0 {
> + status = "okay";
> +
> + u2phy0_otg: otg-port {
> + phy-supply = <&vcc_vbus_typec0>;
> + status = "okay";
> + };
> +
> + u2phy0_host: host-port {
> + phy-supply = <&vcc5v0_host>;
> + status = "okay";
> + };
> +};
> +
> +&u2phy1 {
> + status = "okay";
> +
> + u2phy1_otg: otg-port {
> + phy-supply = <&vcc_vbus_typec1>;
> + status = "okay";
> + };
> +
> + u2phy1_host: host-port {
> + phy-supply = <&vcc5v0_host>;
> + status = "okay";
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_xfer &uart0_cts>;
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&usb_host0_ehci {
> + status = "okay";
> +};
> +
> +&usb_host0_ohci {
> + status = "okay";
> +};
> +
> +&usb_host1_ehci {
> + status = "okay";
> +};
> +
> +&usb_host1_ohci {
> + status = "okay";
> +};
> +
> +&usbdrd3_0 {
> + status = "okay";
> +};
> +
> +&usbdrd_dwc3_0 {
> + status = "okay";
> +};
> +
> +&usbdrd3_1 {
> + status = "okay";
> +};
> +
> +&usbdrd_dwc3_1 {
> + status = "okay";
> + dr_mode = "host";
> +};
> +
> +&vopb {
> + status = "okay";
> +};
> +
> +&vopb_mmu {
> + status = "okay";
> +};
> +
> +&vopl {
> + status = "okay";
> +};
> +
> +&vopl_mmu {
> + status = "okay";
> +};
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 09/11] roc-pc-rk3399: Enable SPI Flash
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-30 3:00 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:00 UTC (permalink / raw)
To: Jagan Teki, Simon Glass, Philipp Tomsich
Cc: u-boot-0aAXYlwwYIKGBzrmiIFOJg, linux-amarula,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Enable winbond SPI flash for ROC-PC-RK3399 board.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 4 ++++
> configs/roc-pc-rk3399_defconfig | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
> index 77d5cf5d3c..5746442981 100644
> --- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
> @@ -7,6 +7,10 @@
> #include "rk3399-sdram-lpddr4-100.dtsi"
>
> / {
> + aliases {
> + spi0 = &spi1;
> + };
> +
> chosen {
> u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
> };
> diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
> index 305baa712c..f37a7bda00 100644
> --- a/configs/roc-pc-rk3399_defconfig
> +++ b/configs/roc-pc-rk3399_defconfig
> @@ -42,6 +42,8 @@ CONFIG_RAM_RK3399_LPDDR4=y
> CONFIG_BAUDRATE=1500000
> CONFIG_DEBUG_UART_SHIFT=2
> CONFIG_SYSRESET=y
> +CONFIG_SPI_FLASH_WINBOND=y
> +CONFIG_ROCKCHIP_SPI=y
> CONFIG_USB=y
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_DWC3=y
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 09/11] roc-pc-rk3399: Enable SPI Flash
@ 2019-12-30 3:00 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:00 UTC (permalink / raw)
To: u-boot
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Enable winbond SPI flash for ROC-PC-RK3399 board.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 4 ++++
> configs/roc-pc-rk3399_defconfig | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
> index 77d5cf5d3c..5746442981 100644
> --- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
> @@ -7,6 +7,10 @@
> #include "rk3399-sdram-lpddr4-100.dtsi"
>
> / {
> + aliases {
> + spi0 = &spi1;
> + };
> +
> chosen {
> u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
> };
> diff --git a/configs/roc-pc-rk3399_defconfig b/configs/roc-pc-rk3399_defconfig
> index 305baa712c..f37a7bda00 100644
> --- a/configs/roc-pc-rk3399_defconfig
> +++ b/configs/roc-pc-rk3399_defconfig
> @@ -42,6 +42,8 @@ CONFIG_RAM_RK3399_LPDDR4=y
> CONFIG_BAUDRATE=1500000
> CONFIG_DEBUG_UART_SHIFT=2
> CONFIG_SYSRESET=y
> +CONFIG_SPI_FLASH_WINBOND=y
> +CONFIG_ROCKCHIP_SPI=y
> CONFIG_USB=y
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_DWC3=y
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 10/11] rockpro-rk3399: Enable SPI Flash
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-30 3:00 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:00 UTC (permalink / raw)
To: Jagan Teki, Simon Glass, Philipp Tomsich
Cc: u-boot, linux-amarula, linux-rockchip
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Enable winbond SPI flash for ROC-PC-RK3399 board.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 ++++
> configs/rockpro64-rk3399_defconfig | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> index 4648513ea9..deaa3efd39 100644
> --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> @@ -6,6 +6,10 @@
> #include "rk3399-u-boot.dtsi"
> #include "rk3399-sdram-lpddr4-100.dtsi"
> / {
> + aliases {
> + spi0 = &spi1;
> + };
> +
> chosen {
> u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
> };
> diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
> index 49e27c91cb..6a50ec7dbc 100644
> --- a/configs/rockpro64-rk3399_defconfig
> +++ b/configs/rockpro64-rk3399_defconfig
> @@ -46,6 +46,8 @@ CONFIG_RAM_RK3399_LPDDR4=y
> CONFIG_BAUDRATE=1500000
> CONFIG_DEBUG_UART_SHIFT=2
> CONFIG_SYSRESET=y
> +CONFIG_SPI_FLASH_GIGADEVICE=y
> +CONFIG_ROCKCHIP_SPI=y
> CONFIG_USB=y
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_DWC3=y
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 10/11] rockpro-rk3399: Enable SPI Flash
@ 2019-12-30 3:00 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:00 UTC (permalink / raw)
To: u-boot
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Enable winbond SPI flash for ROC-PC-RK3399 board.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 ++++
> configs/rockpro64-rk3399_defconfig | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> index 4648513ea9..deaa3efd39 100644
> --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> @@ -6,6 +6,10 @@
> #include "rk3399-u-boot.dtsi"
> #include "rk3399-sdram-lpddr4-100.dtsi"
> / {
> + aliases {
> + spi0 = &spi1;
> + };
> +
> chosen {
> u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
> };
> diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
> index 49e27c91cb..6a50ec7dbc 100644
> --- a/configs/rockpro64-rk3399_defconfig
> +++ b/configs/rockpro64-rk3399_defconfig
> @@ -46,6 +46,8 @@ CONFIG_RAM_RK3399_LPDDR4=y
> CONFIG_BAUDRATE=1500000
> CONFIG_DEBUG_UART_SHIFT=2
> CONFIG_SYSRESET=y
> +CONFIG_SPI_FLASH_GIGADEVICE=y
> +CONFIG_ROCKCHIP_SPI=y
> CONFIG_USB=y
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_DWC3=y
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 11/11] roc-rk3399-pc: Add SPI boot support
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-30 3:05 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:05 UTC (permalink / raw)
To: Jagan Teki, Simon Glass, Philipp Tomsich
Cc: u-boot, linux-amarula, linux-rockchip
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Add SPI boot support for ROC-RK3399-PC board.
>
> This would add separate config file
What is the key reason to have a new separate config file? I think it
would be much better
to use the same defconfig, spi boot is one of features like other
features, it should not need
a separate config.
Thanks,
- Kever
> for SPI along
> with dts changes.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 12 ++++-
> board/rockchip/evb_rk3399/MAINTAINERS | 2 +
> configs/roc-pc-rk3399-spi_defconfig | 62 ++++++++++++++++++++++++++
> 3 files changed, 75 insertions(+), 1 deletion(-)
> create mode 100644 configs/roc-pc-rk3399-spi_defconfig
>
> diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
> index 5746442981..6e43c7c71b 100644
> --- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
> @@ -11,8 +11,18 @@
> spi0 = &spi1;
> };
>
> + config {
> + u-boot,spl-payload-offset = <0x40000>; /* @ 256KB */
> + };
> +
> chosen {
> - u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
> + u-boot,spl-boot-order = "same-as-spl", &spi_flash, &sdhci, &sdmmc;
> + };
> +};
> +
> +&spi1 {
> + spi_flash: flash@0 {
> + u-boot,dm-pre-reloc;
> };
> };
>
> diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
> index eab4c4c525..8de6ec88f1 100644
> --- a/board/rockchip/evb_rk3399/MAINTAINERS
> +++ b/board/rockchip/evb_rk3399/MAINTAINERS
> @@ -57,8 +57,10 @@ F: arch/arm/dts/rk3399-orangepi-u-boot.dtsi
>
> ROC-RK3399-PC
> M: Levin Du <djw@t-chip.com.cn>
> +M: Jagan Teki <jagan@amarulasolutions.com>
> S: Maintained
> F: configs/roc-pc-rk3399_defconfig
> +F: configs/roc-pc-rk3399-spi_defconfig
> F: arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
>
> ROCK-PI-4
> diff --git a/configs/roc-pc-rk3399-spi_defconfig b/configs/roc-pc-rk3399-spi_defconfig
> new file mode 100644
> index 0000000000..1fdfb10101
> --- /dev/null
> +++ b/configs/roc-pc-rk3399-spi_defconfig
> @@ -0,0 +1,62 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SYS_TEXT_BASE=0x00200000
> +CONFIG_ROCKCHIP_RK3399=y
> +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
> +# CONFIG_SPL_MMC_SUPPORT is not set
> +CONFIG_SPL_SPI_FLASH_SUPPORT=y
> +CONFIG_SPL_SPI_SUPPORT=y
> +CONFIG_SPL_SPI_LOAD=y
> +CONFIG_SPL_TEXT_BASE=0xff8c2000
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-roc-pc"
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_SPI_FLASH=y
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_DM_ETH=y
> +CONFIG_ETH_DESIGNWARE=y
> +CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PMIC_RK8XX=y
> +CONFIG_REGULATOR_PWM=y
> +CONFIG_REGULATOR_RK8XX=y
> +CONFIG_PWM_ROCKCHIP=y
> +CONFIG_RAM_RK3399_LPDDR4=y
> +CONFIG_BAUDRATE=1500000
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_SYSRESET=y
> +CONFIG_SPI_FLASH_WINBOND=y
> +CONFIG_ROCKCHIP_SPI=y
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_HOST_ETHER=y
> +CONFIG_USB_ETHER_ASIX=y
> +CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_USB_ETHER_MCS7830=y
> +CONFIG_USB_ETHER_RTL8152=y
> +CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_ERRNO_STR=y
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 11/11] roc-rk3399-pc: Add SPI boot support
@ 2019-12-30 3:05 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:05 UTC (permalink / raw)
To: u-boot
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Add SPI boot support for ROC-RK3399-PC board.
>
> This would add separate config file
What is the key reason to have a new separate config file? I think it
would be much better
to use the same defconfig, spi boot is one of features like other
features, it should not need
a separate config.
Thanks,
- Kever
> for SPI along
> with dts changes.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 12 ++++-
> board/rockchip/evb_rk3399/MAINTAINERS | 2 +
> configs/roc-pc-rk3399-spi_defconfig | 62 ++++++++++++++++++++++++++
> 3 files changed, 75 insertions(+), 1 deletion(-)
> create mode 100644 configs/roc-pc-rk3399-spi_defconfig
>
> diff --git a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
> index 5746442981..6e43c7c71b 100644
> --- a/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
> @@ -11,8 +11,18 @@
> spi0 = &spi1;
> };
>
> + config {
> + u-boot,spl-payload-offset = <0x40000>; /* @ 256KB */
> + };
> +
> chosen {
> - u-boot,spl-boot-order = "same-as-spl", &sdhci, &sdmmc;
> + u-boot,spl-boot-order = "same-as-spl", &spi_flash, &sdhci, &sdmmc;
> + };
> +};
> +
> +&spi1 {
> + spi_flash: flash at 0 {
> + u-boot,dm-pre-reloc;
> };
> };
>
> diff --git a/board/rockchip/evb_rk3399/MAINTAINERS b/board/rockchip/evb_rk3399/MAINTAINERS
> index eab4c4c525..8de6ec88f1 100644
> --- a/board/rockchip/evb_rk3399/MAINTAINERS
> +++ b/board/rockchip/evb_rk3399/MAINTAINERS
> @@ -57,8 +57,10 @@ F: arch/arm/dts/rk3399-orangepi-u-boot.dtsi
>
> ROC-RK3399-PC
> M: Levin Du <djw@t-chip.com.cn>
> +M: Jagan Teki <jagan@amarulasolutions.com>
> S: Maintained
> F: configs/roc-pc-rk3399_defconfig
> +F: configs/roc-pc-rk3399-spi_defconfig
> F: arch/arm/dts/rk3399-roc-pc-u-boot.dtsi
>
> ROCK-PI-4
> diff --git a/configs/roc-pc-rk3399-spi_defconfig b/configs/roc-pc-rk3399-spi_defconfig
> new file mode 100644
> index 0000000000..1fdfb10101
> --- /dev/null
> +++ b/configs/roc-pc-rk3399-spi_defconfig
> @@ -0,0 +1,62 @@
> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SYS_TEXT_BASE=0x00200000
> +CONFIG_ROCKCHIP_RK3399=y
> +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_DEBUG_UART_BASE=0xFF1A0000
> +CONFIG_DEBUG_UART_CLOCK=24000000
> +CONFIG_DEBUG_UART=y
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-roc-pc.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
> +# CONFIG_SPL_MMC_SUPPORT is not set
> +CONFIG_SPL_SPI_FLASH_SUPPORT=y
> +CONFIG_SPL_SPI_SUPPORT=y
> +CONFIG_SPL_SPI_LOAD=y
> +CONFIG_SPL_TEXT_BASE=0xff8c2000
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3399-roc-pc"
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_SPI_FLASH=y
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ROCKCHIP=y
> +CONFIG_DM_ETH=y
> +CONFIG_ETH_DESIGNWARE=y
> +CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PMIC_RK8XX=y
> +CONFIG_REGULATOR_PWM=y
> +CONFIG_REGULATOR_RK8XX=y
> +CONFIG_PWM_ROCKCHIP=y
> +CONFIG_RAM_RK3399_LPDDR4=y
> +CONFIG_BAUDRATE=1500000
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_SYSRESET=y
> +CONFIG_SPI_FLASH_WINBOND=y
> +CONFIG_ROCKCHIP_SPI=y
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_HOST_ETHER=y
> +CONFIG_USB_ETHER_ASIX=y
> +CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_USB_ETHER_MCS7830=y
> +CONFIG_USB_ETHER_RTL8152=y
> +CONFIG_USB_ETHER_SMSC95XX=y
> +CONFIG_ERRNO_STR=y
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 06/11] env: kconfig: Restrict rockchip env for MMC
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-30 3:05 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:05 UTC (permalink / raw)
To: Jagan Teki, Simon Glass, Philipp Tomsich
Cc: u-boot, linux-amarula, linux-rockchip
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Rockchip do support SPI flash as well, so there is
> a possibility of using flash environment for those
> use cases.
>
> So, restrict the current env offset, size for MMC.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> env/Kconfig | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/env/Kconfig b/env/Kconfig
> index ed12609f6a..9416a70022 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -488,7 +488,7 @@ config ENV_OFFSET
> hex "Environment offset"
> depends on ENV_IS_IN_EEPROM || ENV_IS_IN_MMC || ENV_IS_IN_NAND || \
> ENV_IS_IN_SPI_FLASH
> - default 0x3f8000 if ARCH_ROCKCHIP
> + default 0x3f8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
> default 0x88000 if ARCH_SUNXI
> default 0xE0000 if ARCH_ZYNQ
> default 0x1E00000 if ARCH_ZYNQMP
> @@ -511,7 +511,8 @@ config ENV_SIZE
> hex "Environment Size"
> default 0x40000 if ENV_IS_IN_SPI_FLASH && ARCH_ZYNQMP
> default 0x20000 if ARCH_SUNXI || ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
> - default 0x8000 if ARCH_ROCKCHIP || ARCH_ZYNQMP || ARCH_VERSAL
> + default 0x8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
> + default 0x8000 if ARCH_ZYNQMP || ARCH_VERSAL
> default 0x4000 if ARC
> default 0x1f000
> help
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 06/11] env: kconfig: Restrict rockchip env for MMC
@ 2019-12-30 3:05 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:05 UTC (permalink / raw)
To: u-boot
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Rockchip do support SPI flash as well, so there is
> a possibility of using flash environment for those
> use cases.
>
> So, restrict the current env offset, size for MMC.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> env/Kconfig | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/env/Kconfig b/env/Kconfig
> index ed12609f6a..9416a70022 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -488,7 +488,7 @@ config ENV_OFFSET
> hex "Environment offset"
> depends on ENV_IS_IN_EEPROM || ENV_IS_IN_MMC || ENV_IS_IN_NAND || \
> ENV_IS_IN_SPI_FLASH
> - default 0x3f8000 if ARCH_ROCKCHIP
> + default 0x3f8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
> default 0x88000 if ARCH_SUNXI
> default 0xE0000 if ARCH_ZYNQ
> default 0x1E00000 if ARCH_ZYNQMP
> @@ -511,7 +511,8 @@ config ENV_SIZE
> hex "Environment Size"
> default 0x40000 if ENV_IS_IN_SPI_FLASH && ARCH_ZYNQMP
> default 0x20000 if ARCH_SUNXI || ARCH_ZYNQ || ARCH_OMAP2PLUS || ARCH_AT91
> - default 0x8000 if ARCH_ROCKCHIP || ARCH_ZYNQMP || ARCH_VERSAL
> + default 0x8000 if ARCH_ROCKCHIP && ENV_IS_IN_MMC
> + default 0x8000 if ARCH_ZYNQMP || ARCH_VERSAL
> default 0x4000 if ARC
> default 0x1f000
> help
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 05/11] rk3399: Check MMC env while defining it
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-30 3:06 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:06 UTC (permalink / raw)
To: Jagan Teki, Simon Glass, Philipp Tomsich
Cc: u-boot, linux-amarula, linux-rockchip
On 2019/12/21 下午3:54, Jagan Teki wrote:
> rk3399 do support SPI flash as well, so there is
> a possibility of using flash environment for those
> usecases.
>
> So define env device for MMC only when it is used
> by specific configuration.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> include/configs/evb_rk3399.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/configs/evb_rk3399.h b/include/configs/evb_rk3399.h
> index b9c4d683f4..c0b0358893 100644
> --- a/include/configs/evb_rk3399.h
> +++ b/include/configs/evb_rk3399.h
> @@ -8,7 +8,9 @@
>
> #include <configs/rk3399_common.h>
>
> -#define CONFIG_SYS_MMC_ENV_DEV 0
> +#if defined(CONFIG_ENV_IS_IN_MMC)
> +# define CONFIG_SYS_MMC_ENV_DEV 0
> +#endif
>
> #define SDRAM_BANK_SIZE (2UL << 30)
>
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 05/11] rk3399: Check MMC env while defining it
@ 2019-12-30 3:06 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:06 UTC (permalink / raw)
To: u-boot
On 2019/12/21 下午3:54, Jagan Teki wrote:
> rk3399 do support SPI flash as well, so there is
> a possibility of using flash environment for those
> usecases.
>
> So define env device for MMC only when it is used
> by specific configuration.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> include/configs/evb_rk3399.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/configs/evb_rk3399.h b/include/configs/evb_rk3399.h
> index b9c4d683f4..c0b0358893 100644
> --- a/include/configs/evb_rk3399.h
> +++ b/include/configs/evb_rk3399.h
> @@ -8,7 +8,9 @@
>
> #include <configs/rk3399_common.h>
>
> -#define CONFIG_SYS_MMC_ENV_DEV 0
> +#if defined(CONFIG_ENV_IS_IN_MMC)
> +# define CONFIG_SYS_MMC_ENV_DEV 0
> +#endif
>
> #define SDRAM_BANK_SIZE (2UL << 30)
>
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 04/11] rk3399: Add boot flash script offet, size
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-30 3:06 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:06 UTC (permalink / raw)
To: Jagan Teki, Simon Glass, Philipp Tomsich
Cc: u-boot, linux-amarula, linux-rockchip
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Most of the SPI flash devices in rockchip (rk3399)
> are 16MiB size. So, let's use the script offset at
> the end of 8K.
>
> This way it cannot overlap any offsets being used
> by software components in flash layout.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> include/configs/rk3399_common.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
> index 127ca1f09c..92eb5cb750 100644
> --- a/include/configs/rk3399_common.h
> +++ b/include/configs/rk3399_common.h
> @@ -48,6 +48,8 @@
>
> #define ENV_MEM_LAYOUT_SETTINGS \
> "scriptaddr=0x00500000\0" \
> + "script_offset_f=0xffe000\0" \
> + "script_size_f=0x2000\0" \
> "pxefile_addr_r=0x00600000\0" \
> "fdt_addr_r=0x01f00000\0" \
> "kernel_addr_r=0x02080000\0" \
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 04/11] rk3399: Add boot flash script offet, size
@ 2019-12-30 3:06 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:06 UTC (permalink / raw)
To: u-boot
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Most of the SPI flash devices in rockchip (rk3399)
> are 16MiB size. So, let's use the script offset at
> the end of 8K.
>
> This way it cannot overlap any offsets being used
> by software components in flash layout.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> include/configs/rk3399_common.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
> index 127ca1f09c..92eb5cb750 100644
> --- a/include/configs/rk3399_common.h
> +++ b/include/configs/rk3399_common.h
> @@ -48,6 +48,8 @@
>
> #define ENV_MEM_LAYOUT_SETTINGS \
> "scriptaddr=0x00500000\0" \
> + "script_offset_f=0xffe000\0" \
> + "script_size_f=0x2000\0" \
> "pxefile_addr_r=0x00600000\0" \
> "fdt_addr_r=0x01f00000\0" \
> "kernel_addr_r=0x02080000\0" \
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 03/11] rockchip: Include SF on distrocmd devices
[not found] ` <20191221075440.6944-4-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
@ 2019-12-30 3:07 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:07 UTC (permalink / raw)
To: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Include the SPI flash device on distro boot targets.
>
> Included at the beginning of the target devices list
> since the rockchip platform has a boot order start
> from SPI Flash.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> include/configs/rockchip-common.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
> index 68e1105a4b..4e6d6e98d9 100644
> --- a/include/configs/rockchip-common.h
> +++ b/include/configs/rockchip-common.h
> @@ -11,6 +11,12 @@
>
> #ifndef CONFIG_SPL_BUILD
>
> +#if CONFIG_IS_ENABLED(CMD_SF)
> +# define BOOT_TARGET_SF(func) func(SF, sf, 0)
> +#else
> +# define BOOT_TARGET_SF(func)
> +#endif
> +
> /* First try to boot from SD (index 0), then eMMC (index 1) */
> #if CONFIG_IS_ENABLED(CMD_MMC)
> #define BOOT_TARGET_MMC(func) \
> @@ -39,6 +45,7 @@
> #endif
>
> #define BOOT_TARGET_DEVICES(func) \
> + BOOT_TARGET_SF(func) \
> BOOT_TARGET_MMC(func) \
> BOOT_TARGET_USB(func) \
> BOOT_TARGET_PXE(func) \
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 02/11] distro_bootcmd: Add SF support
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-30 3:07 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:07 UTC (permalink / raw)
To: Jagan Teki, Simon Glass, Philipp Tomsich
Cc: u-boot, linux-amarula, Tom Rini, linux-rockchip
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Add distro boot command support for SPI flash.
>
> This distro boot will read the boot script at specific
> location at the flash and start sourcing the same.
>
> The common macro like BOOTENV_SHARED_FLASH would help
> to extend the support for nand flash in future.
>
> Cc: Tom Rini <trini@konsulko.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> include/config_distro_bootcmd.h | 35 +++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
> index fc0935fa21..d68b79e290 100644
> --- a/include/config_distro_bootcmd.h
> +++ b/include/config_distro_bootcmd.h
> @@ -43,6 +43,22 @@
> #define BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) \
> #devtypel #instance " "
>
> +#define BOOTENV_SHARED_SF_BODY(devtypel) \
> + "if " #devtypel " probe ${devnum}; then " \
> + "devtype=" #devtypel "; " \
> + "run scan_flash_for_scripts; " \
> + "fi\0"
> +
> +#define BOOTENV_SHARED_FLASH(devtypel) \
> + #devtypel "_boot=" \
> + BOOTENV_SHARED_SF_BODY(devtypel)
> +
> +#define BOOTENV_DEV_FLASH(devtypeu, devtypel, instance) \
> + BOOTENV_DEV_BLKDEV(devtypeu, devtypel, instance)
> +
> +#define BOOTENV_DEV_NAME_FLASH(devtypeu, devtypel, instance) \
> + BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance)
> +
> #ifdef CONFIG_SANDBOX
> #define BOOTENV_SHARED_HOST BOOTENV_SHARED_BLKDEV(host)
> #define BOOTENV_DEV_HOST BOOTENV_DEV_BLKDEV
> @@ -398,6 +414,18 @@
> BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE
> #endif
>
> +#if defined(CONFIG_CMD_SF)
> +#define BOOTENV_SHARED_SF BOOTENV_SHARED_FLASH(sf)
> +#define BOOTENV_DEV_SF BOOTENV_DEV_FLASH
> +#define BOOTENV_DEV_NAME_SF BOOTENV_DEV_NAME_FLASH
> +#else
> +#define BOOTENV_SHARED_SF
> +#define BOOTENV_DEV_SF \
> + BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF
> +#define BOOTENV_DEV_NAME_SF \
> + BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF
> +#endif
> +
> #define BOOTENV_DEV_NAME(devtypeu, devtypel, instance) \
> BOOTENV_DEV_NAME_##devtypeu(devtypeu, devtypel, instance)
> #define BOOTENV_BOOT_TARGETS \
> @@ -412,6 +440,7 @@
> BOOTENV_SHARED_USB \
> BOOTENV_SHARED_SATA \
> BOOTENV_SHARED_SCSI \
> + BOOTENV_SHARED_SF \
> BOOTENV_SHARED_NVME \
> BOOTENV_SHARED_IDE \
> BOOTENV_SHARED_UBIFS \
> @@ -436,6 +465,12 @@
> "echo SCRIPT FAILED: continuing...; " \
> "fi\0" \
> \
> + "scan_flash_for_scripts=" \
> + "${devtype} read ${scriptaddr} " \
> + "${script_offset_f} ${script_size_f}; " \
> + "source ${scriptaddr}; " \
> + "echo SCRIPT FAILED: continuing...\0" \
> + \
> "boot_a_script=" \
> "load ${devtype} ${devnum}:${distro_bootpart} " \
> "${scriptaddr} ${prefix}${script}; " \
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 02/11] distro_bootcmd: Add SF support
@ 2019-12-30 3:07 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2019-12-30 3:07 UTC (permalink / raw)
To: u-boot
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Add distro boot command support for SPI flash.
>
> This distro boot will read the boot script at specific
> location at the flash and start sourcing the same.
>
> The common macro like BOOTENV_SHARED_FLASH would help
> to extend the support for nand flash in future.
>
> Cc: Tom Rini <trini@konsulko.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> include/config_distro_bootcmd.h | 35 +++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
> index fc0935fa21..d68b79e290 100644
> --- a/include/config_distro_bootcmd.h
> +++ b/include/config_distro_bootcmd.h
> @@ -43,6 +43,22 @@
> #define BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance) \
> #devtypel #instance " "
>
> +#define BOOTENV_SHARED_SF_BODY(devtypel) \
> + "if " #devtypel " probe ${devnum}; then " \
> + "devtype=" #devtypel "; " \
> + "run scan_flash_for_scripts; " \
> + "fi\0"
> +
> +#define BOOTENV_SHARED_FLASH(devtypel) \
> + #devtypel "_boot=" \
> + BOOTENV_SHARED_SF_BODY(devtypel)
> +
> +#define BOOTENV_DEV_FLASH(devtypeu, devtypel, instance) \
> + BOOTENV_DEV_BLKDEV(devtypeu, devtypel, instance)
> +
> +#define BOOTENV_DEV_NAME_FLASH(devtypeu, devtypel, instance) \
> + BOOTENV_DEV_NAME_BLKDEV(devtypeu, devtypel, instance)
> +
> #ifdef CONFIG_SANDBOX
> #define BOOTENV_SHARED_HOST BOOTENV_SHARED_BLKDEV(host)
> #define BOOTENV_DEV_HOST BOOTENV_DEV_BLKDEV
> @@ -398,6 +414,18 @@
> BOOT_TARGET_DEVICES_references_PXE_without_CONFIG_CMD_DHCP_or_PXE
> #endif
>
> +#if defined(CONFIG_CMD_SF)
> +#define BOOTENV_SHARED_SF BOOTENV_SHARED_FLASH(sf)
> +#define BOOTENV_DEV_SF BOOTENV_DEV_FLASH
> +#define BOOTENV_DEV_NAME_SF BOOTENV_DEV_NAME_FLASH
> +#else
> +#define BOOTENV_SHARED_SF
> +#define BOOTENV_DEV_SF \
> + BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF
> +#define BOOTENV_DEV_NAME_SF \
> + BOOT_TARGET_DEVICES_references_SF_without_CONFIG_CMD_SF
> +#endif
> +
> #define BOOTENV_DEV_NAME(devtypeu, devtypel, instance) \
> BOOTENV_DEV_NAME_##devtypeu(devtypeu, devtypel, instance)
> #define BOOTENV_BOOT_TARGETS \
> @@ -412,6 +440,7 @@
> BOOTENV_SHARED_USB \
> BOOTENV_SHARED_SATA \
> BOOTENV_SHARED_SCSI \
> + BOOTENV_SHARED_SF \
> BOOTENV_SHARED_NVME \
> BOOTENV_SHARED_IDE \
> BOOTENV_SHARED_UBIFS \
> @@ -436,6 +465,12 @@
> "echo SCRIPT FAILED: continuing...; " \
> "fi\0" \
> \
> + "scan_flash_for_scripts=" \
> + "${devtype} read ${scriptaddr} " \
> + "${script_offset_f} ${script_size_f}; " \
> + "source ${scriptaddr}; " \
> + "echo SCRIPT FAILED: continuing...\0" \
> + \
> "boot_a_script=" \
> "load ${devtype} ${devnum}:${distro_bootpart} " \
> "${scriptaddr} ${prefix}${script}; " \
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 11/11] roc-rk3399-pc: Add SPI boot support
2019-12-30 3:05 ` Kever Yang
@ 2019-12-30 7:52 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-30 7:52 UTC (permalink / raw)
To: Kever Yang; +Cc: U-Boot-Denx, linux-amarula, open list:ARM/Rockchip SoC...
On Mon, Dec 30, 2019 at 8:35 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>
>
> On 2019/12/21 下午3:54, Jagan Teki wrote:
> > Add SPI boot support for ROC-RK3399-PC board.
> >
> > This would add separate config file
>
> What is the key reason to have a new separate config file? I think it
> would be much better
>
> to use the same defconfig, spi boot is one of features like other
> features, it should not need
>
> a separate config.
Problem is env, we don't have dynamic env pickup I guess, don't we?
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 11/11] roc-rk3399-pc: Add SPI boot support
@ 2019-12-30 7:52 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2019-12-30 7:52 UTC (permalink / raw)
To: u-boot
On Mon, Dec 30, 2019 at 8:35 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>
>
> On 2019/12/21 下午3:54, Jagan Teki wrote:
> > Add SPI boot support for ROC-RK3399-PC board.
> >
> > This would add separate config file
>
> What is the key reason to have a new separate config file? I think it
> would be much better
>
> to use the same defconfig, spi boot is one of features like other
> features, it should not need
>
> a separate config.
Problem is env, we don't have dynamic env pickup I guess, don't we?
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 07/11] env: Enable SPI flash env for rockchip
2019-12-28 12:08 ` Jagan Teki
@ 2019-12-30 9:04 ` Soeren Moch
-1 siblings, 0 replies; 91+ messages in thread
From: Soeren Moch @ 2019-12-30 9:04 UTC (permalink / raw)
To: Jagan Teki; +Cc: U-Boot-Denx, linux-amarula, open list:ARM/Rockchip SoC...
On 28.12.19 13:08, Jagan Teki wrote:
> On Fri, Dec 27, 2019 at 6:49 PM Soeren Moch <smoch@web.de> wrote:
>> On 27.12.19 13:04, Jagan Teki wrote:
>>> On Fri, Dec 27, 2019 at 4:00 PM Soeren Moch <smoch@web.de> wrote:
>>>> Hi!
>>>>
>>>> On 27.12.19 07:50, Jagan Teki wrote:
>>>>> Hi Kever,
>>>>>
>>>>> On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>>>>>> Jagan,
>>>>>>
>>>>>>
>>>>>> On 2019/12/21 下午3:54, Jagan Teki wrote:
>>>>>>> Most of the SPI flash devices in rockchip are 16MiB size.
>>>>>>>
>>>>>>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
>>>>>>> size and then start env of 8KiB would be a compatible location
>>>>>>> between all variants of flash sizes.
>>>>>>>
>>>>>>> This patch add env start from 0x14000 with a size of 8KiB.
>>>>>> What's the space map in SPI flash suppose to be? Including
>>>>>> tpl/spl/u-boot.itb
>>>>>>
>>>>>> I would prefer to use 128KiB-8KiB as the env start address, we'd better
>>>>>> to avoid the
>>>>>>
>>>>>> risk of overlap between the env space and the firmware space.
>>>>> Here is the 16MiB flash layout, I have used. I can see the loader1
>>>>> (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
>>>>> space for it. and 8K env after loader2(u-boot). let me know your
>>>>> thoughts?
>>>> Why we cannot use the same layout as what is defined for SD/eMMC:
>>>> http://opensource.rock-chips.com/wiki_Partitions
>>>>
>>>>
>>>>
>>>>> 0x0 - 0x8000, 32K => reserved/loader1
>>>>> 0x8000 - 0x40000, 224K => loader1
>>>>> 0x40000 - 0x140000, 1M => loader2
>>>>> 0x140000 - 0x142000, 8K => env
>>>>> 0x142000 - 0x842000, 7M => kernel
>>>>> 0x842000 - 0x853800, 100K => dtb
>>>>> 0x853800 - => root
>>>> These small loader1/loader2 partitions may byte us later when newer
>>>> u-boot versions only will fit for SD and not for SPI anymore.
>>> Yes, the initial idea is to reuse the existing SD layout but the SPI
>>> flash is limited in size, and it is further limited in rk3399 boards
>>> (rockpro64, roc-rk3399-pc..). which is 16MiB. So reusing half of the
>>> flash size will occupy for till loader2 in SD scheme.
>> Exactly. On my RockPro64 SPI flash size is 16MiB. This covers everything
>> up to "boot", especially loader1, loader2, and U-Boot ENV. Probably the
>> SPI on these boards is sized this way to exactly match this use case.
>> What should be the advantage of only using half of the available memory?
I found another Rockchip documentation about SPI usage:
http://opensource.rock-chips.com/wiki_Boot_option
This clearly confirms my assumption: When booting from SPI everything up
to u-boot should reside in SPI, later stages (kernel,...) in "other place".
> To make small systems to full use of Flash. unlike distros, the
> embedded systems that run just with initramfs. Or any update mechanism
> in systems to make flash boot as an update agent and SD or other
> mediums as main systems.
You talk about rockpro64 and roc-rk3399-pc here. These are consumer
boards, intended for end users. These are not "small systems", they
never will be used without other storage than SPI. And as already
mentioned, even a heavily stripped down kernel will not fir in remaining
SPI space. So there is no such use case on these boards.
>>>> The reserved space for kernel is already too small for normal kernel
>>>> builds today, not to mention a root filesystem.
>>>>
>>>> Are there any use cases where somebody needs to place boot and root
>>>> partitions on SPI flash?
>>> So, explained above due to size limitation the respective blocks like
>>> kernel, root (we can say initrd) are indeed less-sized partitions.
>>> Moreover SPI flash is not a suitable storage for rootfs in rockchip,
>>> since the boot order start from SPI flash usually board would boot
>>> from flash and then look for SD, eMMC, PCIe NVM for loading big chunk
>>> rootfs.
>>>
>>> More or less the idea of above flash layout is to fit properly
>>> with-in-the size boundaries and indeed for small initramfs systems.
>> We use distroboot in the defconfigs of these boards, so no separate
>> space for kernel or initrd is required in (raw) flash, these blobs are
>> always loaded from the boot partition instead.
>> Besides that, kernels for my RockPro64 are bigger (12MiB - 20MiB) than
>> the availbale space in SPI anyway, with additional ~5MiB for initrd.
> As I explained above. So, we can skip Linux, rootfs from flash and
> make use of flash layout that compatible between all systems. what is
> the issue with that other than future proof with SD layout.
I'm not sure what you mean here. defconfig on these consumer boards
should be as simple and easy to understand as possible. And for sure it
should be as documented by rockchip. Boot procedure already is
complicated enough, we should not confuse users even more.
>
> I understand your point, but each and every storage medium can have
> it's own usage to make use of full system running. So the partition
> layout would depend on the size and file systems but it shouldn't
> depend on particular software usage, IMHO.
The distroboot feature of u-boot is totally independent of the actual
operating system running later. And distroboot is used now in defconfig,
so what is your problem here?
>> My use case for SPI would be to store u-boot+SPL+TPL+ATF+environment
>> there, so that I can use a single combined root+boot partition on a SD
>> card / USB disk.
>> So I think the easiest, least confusing, and future-proof SPI partition
>> scheme would be to use exactly what is defined already for SD/eMMC.
> Less confused in terms of maintenance and easy to understand but it
> may not be used for some corner cases like smaller systems.
If you want to support corner cases, you can for sure do so with adapted
u-boot configs. defconfig for consumer boards should be as easy to
understand and maintain as possible. And that also means it should be as
documented and not confusingly different.
I maintain a different board [1] for years now, and this nowadays
repeatedly causes problems for many developers due to size constraints.
All this because the original board vendor decided to use too small
u-boot partitions. Please do not repeat this mistake here.
Soeren
[1]
https://github.com/u-boot/u-boot/blob/master/board/tbs/tbs2910/MAINTAINERS
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 07/11] env: Enable SPI flash env for rockchip
@ 2019-12-30 9:04 ` Soeren Moch
0 siblings, 0 replies; 91+ messages in thread
From: Soeren Moch @ 2019-12-30 9:04 UTC (permalink / raw)
To: u-boot
On 28.12.19 13:08, Jagan Teki wrote:
> On Fri, Dec 27, 2019 at 6:49 PM Soeren Moch <smoch@web.de> wrote:
>> On 27.12.19 13:04, Jagan Teki wrote:
>>> On Fri, Dec 27, 2019 at 4:00 PM Soeren Moch <smoch@web.de> wrote:
>>>> Hi!
>>>>
>>>> On 27.12.19 07:50, Jagan Teki wrote:
>>>>> Hi Kever,
>>>>>
>>>>> On Mon, Dec 23, 2019 at 8:04 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>>>>>> Jagan,
>>>>>>
>>>>>>
>>>>>> On 2019/12/21 下午3:54, Jagan Teki wrote:
>>>>>>> Most of the SPI flash devices in rockchip are 16MiB size.
>>>>>>>
>>>>>>> So, keeping U-Boot proper offset start from 128MiB with 1MiB
>>>>>>> size and then start env of 8KiB would be a compatible location
>>>>>>> between all variants of flash sizes.
>>>>>>>
>>>>>>> This patch add env start from 0x14000 with a size of 8KiB.
>>>>>> What's the space map in SPI flash suppose to be? Including
>>>>>> tpl/spl/u-boot.itb
>>>>>>
>>>>>> I would prefer to use 128KiB-8KiB as the env start address, we'd better
>>>>>> to avoid the
>>>>>>
>>>>>> risk of overlap between the env space and the firmware space.
>>>>> Here is the 16MiB flash layout, I have used. I can see the loader1
>>>>> (tpl/spl) can be possible to load at 0x0 or 0x32K so I have given the
>>>>> space for it. and 8K env after loader2(u-boot). let me know your
>>>>> thoughts?
>>>> Why we cannot use the same layout as what is defined for SD/eMMC:
>>>> http://opensource.rock-chips.com/wiki_Partitions
>>>>
>>>>
>>>>
>>>>> 0x0 - 0x8000, 32K => reserved/loader1
>>>>> 0x8000 - 0x40000, 224K => loader1
>>>>> 0x40000 - 0x140000, 1M => loader2
>>>>> 0x140000 - 0x142000, 8K => env
>>>>> 0x142000 - 0x842000, 7M => kernel
>>>>> 0x842000 - 0x853800, 100K => dtb
>>>>> 0x853800 - => root
>>>> These small loader1/loader2 partitions may byte us later when newer
>>>> u-boot versions only will fit for SD and not for SPI anymore.
>>> Yes, the initial idea is to reuse the existing SD layout but the SPI
>>> flash is limited in size, and it is further limited in rk3399 boards
>>> (rockpro64, roc-rk3399-pc..). which is 16MiB. So reusing half of the
>>> flash size will occupy for till loader2 in SD scheme.
>> Exactly. On my RockPro64 SPI flash size is 16MiB. This covers everything
>> up to "boot", especially loader1, loader2, and U-Boot ENV. Probably the
>> SPI on these boards is sized this way to exactly match this use case.
>> What should be the advantage of only using half of the available memory?
I found another Rockchip documentation about SPI usage:
http://opensource.rock-chips.com/wiki_Boot_option
This clearly confirms my assumption: When booting from SPI everything up
to u-boot should reside in SPI, later stages (kernel,...) in "other place".
> To make small systems to full use of Flash. unlike distros, the
> embedded systems that run just with initramfs. Or any update mechanism
> in systems to make flash boot as an update agent and SD or other
> mediums as main systems.
You talk about rockpro64 and roc-rk3399-pc here. These are consumer
boards, intended for end users. These are not "small systems", they
never will be used without other storage than SPI. And as already
mentioned, even a heavily stripped down kernel will not fir in remaining
SPI space. So there is no such use case on these boards.
>>>> The reserved space for kernel is already too small for normal kernel
>>>> builds today, not to mention a root filesystem.
>>>>
>>>> Are there any use cases where somebody needs to place boot and root
>>>> partitions on SPI flash?
>>> So, explained above due to size limitation the respective blocks like
>>> kernel, root (we can say initrd) are indeed less-sized partitions.
>>> Moreover SPI flash is not a suitable storage for rootfs in rockchip,
>>> since the boot order start from SPI flash usually board would boot
>>> from flash and then look for SD, eMMC, PCIe NVM for loading big chunk
>>> rootfs.
>>>
>>> More or less the idea of above flash layout is to fit properly
>>> with-in-the size boundaries and indeed for small initramfs systems.
>> We use distroboot in the defconfigs of these boards, so no separate
>> space for kernel or initrd is required in (raw) flash, these blobs are
>> always loaded from the boot partition instead.
>> Besides that, kernels for my RockPro64 are bigger (12MiB - 20MiB) than
>> the availbale space in SPI anyway, with additional ~5MiB for initrd.
> As I explained above. So, we can skip Linux, rootfs from flash and
> make use of flash layout that compatible between all systems. what is
> the issue with that other than future proof with SD layout.
I'm not sure what you mean here. defconfig on these consumer boards
should be as simple and easy to understand as possible. And for sure it
should be as documented by rockchip. Boot procedure already is
complicated enough, we should not confuse users even more.
>
> I understand your point, but each and every storage medium can have
> it's own usage to make use of full system running. So the partition
> layout would depend on the size and file systems but it shouldn't
> depend on particular software usage, IMHO.
The distroboot feature of u-boot is totally independent of the actual
operating system running later. And distroboot is used now in defconfig,
so what is your problem here?
>> My use case for SPI would be to store u-boot+SPL+TPL+ATF+environment
>> there, so that I can use a single combined root+boot partition on a SD
>> card / USB disk.
>> So I think the easiest, least confusing, and future-proof SPI partition
>> scheme would be to use exactly what is defined already for SD/eMMC.
> Less confused in terms of maintenance and easy to understand but it
> may not be used for some corner cases like smaller systems.
If you want to support corner cases, you can for sure do so with adapted
u-boot configs. defconfig for consumer boards should be as easy to
understand and maintain as possible. And that also means it should be as
documented and not confusingly different.
I maintain a different board [1] for years now, and this nowadays
repeatedly causes problems for many developers due to size constraints.
All this because the original board vendor decided to use too small
u-boot partitions. Please do not repeat this mistake here.
Soeren
[1]
https://github.com/u-boot/u-boot/blob/master/board/tbs/tbs2910/MAINTAINERS
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 10/11] rockpro-rk3399: Enable SPI Flash
2019-12-21 7:54 ` Jagan Teki
@ 2019-12-30 11:51 ` Emmanuel Vadot
-1 siblings, 0 replies; 91+ messages in thread
From: Emmanuel Vadot @ 2019-12-30 11:51 UTC (permalink / raw)
To: Jagan Teki
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Simon Glass,
Kever Yang, u-boot-0aAXYlwwYIKGBzrmiIFOJg, Philipp Tomsich,
linux-amarula
Hi Jagan,
On Sat, 21 Dec 2019 13:24:39 +0530
Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> Enable winbond SPI flash for ROC-PC-RK3399 board.
s/ROC-PC-RK3399/RockPro64/
>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> ---
> arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 ++++
> configs/rockpro64-rk3399_defconfig | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> index 4648513ea9..deaa3efd39 100644
> --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> @@ -6,6 +6,10 @@
> #include "rk3399-u-boot.dtsi"
> #include "rk3399-sdram-lpddr4-100.dtsi"
> / {
> + aliases {
> + spi0 = &spi1;
That looks weird ... what's the point of this alias exactly ?
> + };
> +
> chosen {
> u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
> };
> diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
> index 49e27c91cb..6a50ec7dbc 100644
> --- a/configs/rockpro64-rk3399_defconfig
> +++ b/configs/rockpro64-rk3399_defconfig
> @@ -46,6 +46,8 @@ CONFIG_RAM_RK3399_LPDDR4=y
> CONFIG_BAUDRATE=1500000
> CONFIG_DEBUG_UART_SHIFT=2
> CONFIG_SYSRESET=y
> +CONFIG_SPI_FLASH_GIGADEVICE=y
> +CONFIG_ROCKCHIP_SPI=y
> CONFIG_USB=y
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_DWC3=y
> --
> 2.18.0.321.gffc6fa0e3
--
Emmanuel Vadot <manu-xXdDKFdH5B3kFDPD4ZthVA@public.gmane.org>
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 10/11] rockpro-rk3399: Enable SPI Flash
@ 2019-12-30 11:51 ` Emmanuel Vadot
0 siblings, 0 replies; 91+ messages in thread
From: Emmanuel Vadot @ 2019-12-30 11:51 UTC (permalink / raw)
To: u-boot
Hi Jagan,
On Sat, 21 Dec 2019 13:24:39 +0530
Jagan Teki <jagan@amarulasolutions.com> wrote:
> Enable winbond SPI flash for ROC-PC-RK3399 board.
s/ROC-PC-RK3399/RockPro64/
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 ++++
> configs/rockpro64-rk3399_defconfig | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> index 4648513ea9..deaa3efd39 100644
> --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> @@ -6,6 +6,10 @@
> #include "rk3399-u-boot.dtsi"
> #include "rk3399-sdram-lpddr4-100.dtsi"
> / {
> + aliases {
> + spi0 = &spi1;
That looks weird ... what's the point of this alias exactly ?
> + };
> +
> chosen {
> u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
> };
> diff --git a/configs/rockpro64-rk3399_defconfig b/configs/rockpro64-rk3399_defconfig
> index 49e27c91cb..6a50ec7dbc 100644
> --- a/configs/rockpro64-rk3399_defconfig
> +++ b/configs/rockpro64-rk3399_defconfig
> @@ -46,6 +46,8 @@ CONFIG_RAM_RK3399_LPDDR4=y
> CONFIG_BAUDRATE=1500000
> CONFIG_DEBUG_UART_SHIFT=2
> CONFIG_SYSRESET=y
> +CONFIG_SPI_FLASH_GIGADEVICE=y
> +CONFIG_ROCKCHIP_SPI=y
> CONFIG_USB=y
> CONFIG_USB_XHCI_HCD=y
> CONFIG_USB_XHCI_DWC3=y
> --
> 2.18.0.321.gffc6fa0e3
--
Emmanuel Vadot <manu@bidouilliste.com>
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 03/11] rockchip: Include SF on distrocmd devices
2019-12-21 7:54 ` Jagan Teki
@ 2020-01-07 8:44 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2020-01-07 8:44 UTC (permalink / raw)
To: Jagan Teki, Simon Glass, Philipp Tomsich
Cc: u-boot, linux-amarula, linux-rockchip
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Include the SPI flash device on distro boot targets.
>
> Included at the beginning of the target devices list
> since the rockchip platform has a boot order start
> from SPI Flash.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> include/configs/rockchip-common.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
> index 68e1105a4b..4e6d6e98d9 100644
> --- a/include/configs/rockchip-common.h
> +++ b/include/configs/rockchip-common.h
> @@ -11,6 +11,12 @@
>
> #ifndef CONFIG_SPL_BUILD
>
> +#if CONFIG_IS_ENABLED(CMD_SF)
> +# define BOOT_TARGET_SF(func) func(SF, sf, 0)
> +#else
> +# define BOOT_TARGET_SF(func)
> +#endif
> +
> /* First try to boot from SD (index 0), then eMMC (index 1) */
> #if CONFIG_IS_ENABLED(CMD_MMC)
> #define BOOT_TARGET_MMC(func) \
> @@ -39,6 +45,7 @@
> #endif
>
> #define BOOT_TARGET_DEVICES(func) \
> + BOOT_TARGET_SF(func) \
> BOOT_TARGET_MMC(func) \
> BOOT_TARGET_USB(func) \
> BOOT_TARGET_PXE(func) \
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 03/11] rockchip: Include SF on distrocmd devices
@ 2020-01-07 8:44 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2020-01-07 8:44 UTC (permalink / raw)
To: u-boot
On 2019/12/21 下午3:54, Jagan Teki wrote:
> Include the SPI flash device on distro boot targets.
>
> Included at the beginning of the target devices list
> since the rockchip platform has a boot order start
> from SPI Flash.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Thanks,
- Kever
> ---
> include/configs/rockchip-common.h | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
> index 68e1105a4b..4e6d6e98d9 100644
> --- a/include/configs/rockchip-common.h
> +++ b/include/configs/rockchip-common.h
> @@ -11,6 +11,12 @@
>
> #ifndef CONFIG_SPL_BUILD
>
> +#if CONFIG_IS_ENABLED(CMD_SF)
> +# define BOOT_TARGET_SF(func) func(SF, sf, 0)
> +#else
> +# define BOOT_TARGET_SF(func)
> +#endif
> +
> /* First try to boot from SD (index 0), then eMMC (index 1) */
> #if CONFIG_IS_ENABLED(CMD_MMC)
> #define BOOT_TARGET_MMC(func) \
> @@ -39,6 +45,7 @@
> #endif
>
> #define BOOT_TARGET_DEVICES(func) \
> + BOOT_TARGET_SF(func) \
> BOOT_TARGET_MMC(func) \
> BOOT_TARGET_USB(func) \
> BOOT_TARGET_PXE(func) \
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 11/11] roc-rk3399-pc: Add SPI boot support
2019-12-30 7:52 ` Jagan Teki
@ 2020-01-07 8:53 ` Kever Yang
-1 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2020-01-07 8:53 UTC (permalink / raw)
To: Jagan Teki
Cc: U-Boot-Denx, Simon Glass, Philipp Tomsich, linux-amarula,
open list:ARM/Rockchip SoC...
Hi Jagan,
On 2019/12/30 下午3:52, Jagan Teki wrote:
> On Mon, Dec 30, 2019 at 8:35 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>>
>> On 2019/12/21 下午3:54, Jagan Teki wrote:
>>> Add SPI boot support for ROC-RK3399-PC board.
>>>
>>> This would add separate config file
>> What is the key reason to have a new separate config file? I think it
>> would be much better
>>
>> to use the same defconfig, spi boot is one of features like other
>> features, it should not need
>>
>> a separate config.
> Problem is env, we don't have dynamic env pickup I guess, don't we?
I would suggest to split the addition of the spi_defconfig out of this
patch so that I can merge
the other part of code update and get the image for spi without binman
for now before we
have a better solution.
And I don't want to double the defconfig file number for spi config
image with binman support.
Thanks,
- Kever
>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 11/11] roc-rk3399-pc: Add SPI boot support
@ 2020-01-07 8:53 ` Kever Yang
0 siblings, 0 replies; 91+ messages in thread
From: Kever Yang @ 2020-01-07 8:53 UTC (permalink / raw)
To: u-boot
Hi Jagan,
On 2019/12/30 下午3:52, Jagan Teki wrote:
> On Mon, Dec 30, 2019 at 8:35 AM Kever Yang <kever.yang@rock-chips.com> wrote:
>>
>> On 2019/12/21 下午3:54, Jagan Teki wrote:
>>> Add SPI boot support for ROC-RK3399-PC board.
>>>
>>> This would add separate config file
>> What is the key reason to have a new separate config file? I think it
>> would be much better
>>
>> to use the same defconfig, spi boot is one of features like other
>> features, it should not need
>>
>> a separate config.
> Problem is env, we don't have dynamic env pickup I guess, don't we?
I would suggest to split the addition of the spi_defconfig out of this
patch so that I can merge
the other part of code update and get the image for spi without binman
for now before we
have a better solution.
And I don't want to double the defconfig file number for spi config
image with binman support.
Thanks,
- Kever
>
>
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 10/11] rockpro-rk3399: Enable SPI Flash
2019-12-30 11:51 ` Emmanuel Vadot
@ 2020-01-08 12:59 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2020-01-08 12:59 UTC (permalink / raw)
To: Emmanuel Vadot; +Cc: open list:ARM/Rockchip SoC..., U-Boot-Denx, linux-amarula
On Mon, Dec 30, 2019 at 5:21 PM Emmanuel Vadot <manu@bidouilliste.com> wrote:
>
>
> Hi Jagan,
>
> On Sat, 21 Dec 2019 13:24:39 +0530
> Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> > Enable winbond SPI flash for ROC-PC-RK3399 board.
>
> s/ROC-PC-RK3399/RockPro64/
>
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> > arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 ++++
> > configs/rockpro64-rk3399_defconfig | 2 ++
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > index 4648513ea9..deaa3efd39 100644
> > --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > @@ -6,6 +6,10 @@
> > #include "rk3399-u-boot.dtsi"
> > #include "rk3399-sdram-lpddr4-100.dtsi"
> > / {
> > + aliases {
> > + spi0 = &spi1;
>
> That looks weird ... what's the point of this alias exactly ?
spi uclass would require alias number to bind the driver, no way to
escape as of now.
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 10/11] rockpro-rk3399: Enable SPI Flash
@ 2020-01-08 12:59 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2020-01-08 12:59 UTC (permalink / raw)
To: u-boot
On Mon, Dec 30, 2019 at 5:21 PM Emmanuel Vadot <manu@bidouilliste.com> wrote:
>
>
> Hi Jagan,
>
> On Sat, 21 Dec 2019 13:24:39 +0530
> Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> > Enable winbond SPI flash for ROC-PC-RK3399 board.
>
> s/ROC-PC-RK3399/RockPro64/
>
> >
> > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > ---
> > arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 ++++
> > configs/rockpro64-rk3399_defconfig | 2 ++
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > index 4648513ea9..deaa3efd39 100644
> > --- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
> > @@ -6,6 +6,10 @@
> > #include "rk3399-u-boot.dtsi"
> > #include "rk3399-sdram-lpddr4-100.dtsi"
> > / {
> > + aliases {
> > + spi0 = &spi1;
>
> That looks weird ... what's the point of this alias exactly ?
spi uclass would require alias number to bind the driver, no way to
escape as of now.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 02/11] distro_bootcmd: Add SF support
2019-12-21 7:54 ` Jagan Teki
@ 2020-01-20 17:22 ` Tom Rini
-1 siblings, 0 replies; 91+ messages in thread
From: Tom Rini @ 2020-01-20 17:22 UTC (permalink / raw)
To: Jagan Teki
Cc: linux-rockchip, Heinrich Schuchardt, u-boot, Alexander Graf,
linux-amarula
[-- Attachment #1: Type: text/plain, Size: 832 bytes --]
+A few people that may have insight to my question
On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> Add distro boot command support for SPI flash.
>
> This distro boot will read the boot script at specific
> location at the flash and start sourcing the same.
>
> The common macro like BOOTENV_SHARED_FLASH would help
> to extend the support for nand flash in future.
>
> Cc: Tom Rini <trini@konsulko.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
What distro is this for? My concern here is that hundreds of boards
(literally) grow by a few hundred bytes to add in this bit of additional
default logic. That's not a big problem if distributions are now going
to be using SPI flash as where they're programming in their bootscript.
But, who is doing that? Thanks!
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 02/11] distro_bootcmd: Add SF support
@ 2020-01-20 17:22 ` Tom Rini
0 siblings, 0 replies; 91+ messages in thread
From: Tom Rini @ 2020-01-20 17:22 UTC (permalink / raw)
To: u-boot
+A few people that may have insight to my question
On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> Add distro boot command support for SPI flash.
>
> This distro boot will read the boot script at specific
> location at the flash and start sourcing the same.
>
> The common macro like BOOTENV_SHARED_FLASH would help
> to extend the support for nand flash in future.
>
> Cc: Tom Rini <trini@konsulko.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
What distro is this for? My concern here is that hundreds of boards
(literally) grow by a few hundred bytes to add in this bit of additional
default logic. That's not a big problem if distributions are now going
to be using SPI flash as where they're programming in their bootscript.
But, who is doing that? Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200120/9c5a3ae3/attachment.sig>
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 02/11] distro_bootcmd: Add SF support
2020-01-20 17:22 ` Tom Rini
@ 2020-01-20 17:40 ` Alexander Graf
-1 siblings, 0 replies; 91+ messages in thread
From: Alexander Graf @ 2020-01-20 17:40 UTC (permalink / raw)
To: Tom Rini, Jagan Teki
Cc: linux-rockchip, Heinrich Schuchardt, u-boot, linux-amarula
On 20.01.20 18:22, Tom Rini wrote:
> +A few people that may have insight to my question
>
> On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
>
>> Add distro boot command support for SPI flash.
>>
>> This distro boot will read the boot script at specific
>> location at the flash and start sourcing the same.
>>
>> The common macro like BOOTENV_SHARED_FLASH would help
>> to extend the support for nand flash in future.
>>
>> Cc: Tom Rini <trini@konsulko.com>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> What distro is this for? My concern here is that hundreds of boards
> (literally) grow by a few hundred bytes to add in this bit of additional
> default logic. That's not a big problem if distributions are now going
> to be using SPI flash as where they're programming in their bootscript.
> But, who is doing that? Thanks!
I am not aware of any "distro" that puts a U-Boot script at offset 0 of
the SPI Flash.
Traditionally, SPI Flash boot setups were always very hand crafted -
exactly the opposite of what distro boot is for. That said, I think
supporting SPI Flash boot for rk3399 is great! Albeit I would personally
only store U-Boot and the environment on SPI, not the target OS.
Jagan, is putting a U-Boot script on the SPI Flash something you thought
of or something that the rk3399 reference board already does? If it's
the latter, maybe you could add it as a board custom boot function?
Alex
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 02/11] distro_bootcmd: Add SF support
@ 2020-01-20 17:40 ` Alexander Graf
0 siblings, 0 replies; 91+ messages in thread
From: Alexander Graf @ 2020-01-20 17:40 UTC (permalink / raw)
To: u-boot
On 20.01.20 18:22, Tom Rini wrote:
> +A few people that may have insight to my question
>
> On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
>
>> Add distro boot command support for SPI flash.
>>
>> This distro boot will read the boot script at specific
>> location at the flash and start sourcing the same.
>>
>> The common macro like BOOTENV_SHARED_FLASH would help
>> to extend the support for nand flash in future.
>>
>> Cc: Tom Rini <trini@konsulko.com>
>> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> What distro is this for? My concern here is that hundreds of boards
> (literally) grow by a few hundred bytes to add in this bit of additional
> default logic. That's not a big problem if distributions are now going
> to be using SPI flash as where they're programming in their bootscript.
> But, who is doing that? Thanks!
I am not aware of any "distro" that puts a U-Boot script at offset 0 of
the SPI Flash.
Traditionally, SPI Flash boot setups were always very hand crafted -
exactly the opposite of what distro boot is for. That said, I think
supporting SPI Flash boot for rk3399 is great! Albeit I would personally
only store U-Boot and the environment on SPI, not the target OS.
Jagan, is putting a U-Boot script on the SPI Flash something you thought
of or something that the rk3399 reference board already does? If it's
the latter, maybe you could add it as a board custom boot function?
Alex
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 02/11] distro_bootcmd: Add SF support
2020-01-20 17:40 ` Alexander Graf
@ 2020-01-23 16:55 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2020-01-23 16:55 UTC (permalink / raw)
To: Alexander Graf, Tom Rini
Cc: open list:ARM/Rockchip SoC...,
Heinrich Schuchardt, U-Boot-Denx, linux-amarula
On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote:
>
>
> On 20.01.20 18:22, Tom Rini wrote:
> > +A few people that may have insight to my question
> >
> > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> >
> >> Add distro boot command support for SPI flash.
> >>
> >> This distro boot will read the boot script at specific
> >> location at the flash and start sourcing the same.
> >>
> >> The common macro like BOOTENV_SHARED_FLASH would help
> >> to extend the support for nand flash in future.
> >>
> >> Cc: Tom Rini <trini@konsulko.com>
> >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > What distro is this for? My concern here is that hundreds of boards
> > (literally) grow by a few hundred bytes to add in this bit of additional
> > default logic. That's not a big problem if distributions are now going
> > to be using SPI flash as where they're programming in their bootscript.
> > But, who is doing that? Thanks!
>
>
> I am not aware of any "distro" that puts a U-Boot script at offset 0 of
> the SPI Flash.
>
> Traditionally, SPI Flash boot setups were always very hand crafted -
> exactly the opposite of what distro boot is for. That said, I think
> supporting SPI Flash boot for rk3399 is great! Albeit I would personally
> only store U-Boot and the environment on SPI, not the target OS.
>
> Jagan, is putting a U-Boot script on the SPI Flash something you thought
> of or something that the rk3399 reference board already does? If it's
> the latter, maybe you could add it as a board custom boot function?
Yes it would be later that points to. rk3399 has SPI flash layout and
out of which one of offset(script_offset_f=0xffe000 from
include/configs/rk3399_common.h) stored the programming script.
Jagan.
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 02/11] distro_bootcmd: Add SF support
@ 2020-01-23 16:55 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2020-01-23 16:55 UTC (permalink / raw)
To: u-boot
On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote:
>
>
> On 20.01.20 18:22, Tom Rini wrote:
> > +A few people that may have insight to my question
> >
> > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> >
> >> Add distro boot command support for SPI flash.
> >>
> >> This distro boot will read the boot script at specific
> >> location at the flash and start sourcing the same.
> >>
> >> The common macro like BOOTENV_SHARED_FLASH would help
> >> to extend the support for nand flash in future.
> >>
> >> Cc: Tom Rini <trini@konsulko.com>
> >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > What distro is this for? My concern here is that hundreds of boards
> > (literally) grow by a few hundred bytes to add in this bit of additional
> > default logic. That's not a big problem if distributions are now going
> > to be using SPI flash as where they're programming in their bootscript.
> > But, who is doing that? Thanks!
>
>
> I am not aware of any "distro" that puts a U-Boot script at offset 0 of
> the SPI Flash.
>
> Traditionally, SPI Flash boot setups were always very hand crafted -
> exactly the opposite of what distro boot is for. That said, I think
> supporting SPI Flash boot for rk3399 is great! Albeit I would personally
> only store U-Boot and the environment on SPI, not the target OS.
>
> Jagan, is putting a U-Boot script on the SPI Flash something you thought
> of or something that the rk3399 reference board already does? If it's
> the latter, maybe you could add it as a board custom boot function?
Yes it would be later that points to. rk3399 has SPI flash layout and
out of which one of offset(script_offset_f=0xffe000 from
include/configs/rk3399_common.h) stored the programming script.
Jagan.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 02/11] distro_bootcmd: Add SF support
2020-01-23 16:55 ` Jagan Teki
@ 2020-01-23 17:03 ` Tom Rini
-1 siblings, 0 replies; 91+ messages in thread
From: Tom Rini @ 2020-01-23 17:03 UTC (permalink / raw)
To: Jagan Teki
Cc: open list:ARM/Rockchip SoC...,
Heinrich Schuchardt, U-Boot-Denx, Alexander Graf, linux-amarula
[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]
On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote:
> On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote:
> >
> >
> > On 20.01.20 18:22, Tom Rini wrote:
> > > +A few people that may have insight to my question
> > >
> > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> > >
> > >> Add distro boot command support for SPI flash.
> > >>
> > >> This distro boot will read the boot script at specific
> > >> location at the flash and start sourcing the same.
> > >>
> > >> The common macro like BOOTENV_SHARED_FLASH would help
> > >> to extend the support for nand flash in future.
> > >>
> > >> Cc: Tom Rini <trini@konsulko.com>
> > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > What distro is this for? My concern here is that hundreds of boards
> > > (literally) grow by a few hundred bytes to add in this bit of additional
> > > default logic. That's not a big problem if distributions are now going
> > > to be using SPI flash as where they're programming in their bootscript.
> > > But, who is doing that? Thanks!
> >
> >
> > I am not aware of any "distro" that puts a U-Boot script at offset 0 of
> > the SPI Flash.
> >
> > Traditionally, SPI Flash boot setups were always very hand crafted -
> > exactly the opposite of what distro boot is for. That said, I think
> > supporting SPI Flash boot for rk3399 is great! Albeit I would personally
> > only store U-Boot and the environment on SPI, not the target OS.
> >
> > Jagan, is putting a U-Boot script on the SPI Flash something you thought
> > of or something that the rk3399 reference board already does? If it's
> > the latter, maybe you could add it as a board custom boot function?
>
> Yes it would be later that points to. rk3399 has SPI flash layout and
> out of which one of offset(script_offset_f=0xffe000 from
> include/configs/rk3399_common.h) stored the programming script.
So I'm not sure why we're adding distro boot support to SPI flash. What
is the reference platform storing there exactly? Thanks!
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 02/11] distro_bootcmd: Add SF support
@ 2020-01-23 17:03 ` Tom Rini
0 siblings, 0 replies; 91+ messages in thread
From: Tom Rini @ 2020-01-23 17:03 UTC (permalink / raw)
To: u-boot
On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote:
> On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote:
> >
> >
> > On 20.01.20 18:22, Tom Rini wrote:
> > > +A few people that may have insight to my question
> > >
> > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> > >
> > >> Add distro boot command support for SPI flash.
> > >>
> > >> This distro boot will read the boot script at specific
> > >> location at the flash and start sourcing the same.
> > >>
> > >> The common macro like BOOTENV_SHARED_FLASH would help
> > >> to extend the support for nand flash in future.
> > >>
> > >> Cc: Tom Rini <trini@konsulko.com>
> > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > What distro is this for? My concern here is that hundreds of boards
> > > (literally) grow by a few hundred bytes to add in this bit of additional
> > > default logic. That's not a big problem if distributions are now going
> > > to be using SPI flash as where they're programming in their bootscript.
> > > But, who is doing that? Thanks!
> >
> >
> > I am not aware of any "distro" that puts a U-Boot script at offset 0 of
> > the SPI Flash.
> >
> > Traditionally, SPI Flash boot setups were always very hand crafted -
> > exactly the opposite of what distro boot is for. That said, I think
> > supporting SPI Flash boot for rk3399 is great! Albeit I would personally
> > only store U-Boot and the environment on SPI, not the target OS.
> >
> > Jagan, is putting a U-Boot script on the SPI Flash something you thought
> > of or something that the rk3399 reference board already does? If it's
> > the latter, maybe you could add it as a board custom boot function?
>
> Yes it would be later that points to. rk3399 has SPI flash layout and
> out of which one of offset(script_offset_f=0xffe000 from
> include/configs/rk3399_common.h) stored the programming script.
So I'm not sure why we're adding distro boot support to SPI flash. What
is the reference platform storing there exactly? Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200123/4ff0d1f2/attachment.sig>
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 02/11] distro_bootcmd: Add SF support
2020-01-23 17:03 ` Tom Rini
@ 2020-01-23 17:11 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2020-01-23 17:11 UTC (permalink / raw)
To: Tom Rini
Cc: open list:ARM/Rockchip SoC...,
Heinrich Schuchardt, U-Boot-Denx, Alexander Graf, linux-amarula
On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote:
> > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote:
> > >
> > >
> > > On 20.01.20 18:22, Tom Rini wrote:
> > > > +A few people that may have insight to my question
> > > >
> > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> > > >
> > > >> Add distro boot command support for SPI flash.
> > > >>
> > > >> This distro boot will read the boot script at specific
> > > >> location at the flash and start sourcing the same.
> > > >>
> > > >> The common macro like BOOTENV_SHARED_FLASH would help
> > > >> to extend the support for nand flash in future.
> > > >>
> > > >> Cc: Tom Rini <trini@konsulko.com>
> > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > What distro is this for? My concern here is that hundreds of boards
> > > > (literally) grow by a few hundred bytes to add in this bit of additional
> > > > default logic. That's not a big problem if distributions are now going
> > > > to be using SPI flash as where they're programming in their bootscript.
> > > > But, who is doing that? Thanks!
> > >
> > >
> > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of
> > > the SPI Flash.
> > >
> > > Traditionally, SPI Flash boot setups were always very hand crafted -
> > > exactly the opposite of what distro boot is for. That said, I think
> > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally
> > > only store U-Boot and the environment on SPI, not the target OS.
> > >
> > > Jagan, is putting a U-Boot script on the SPI Flash something you thought
> > > of or something that the rk3399 reference board already does? If it's
> > > the latter, maybe you could add it as a board custom boot function?
> >
> > Yes it would be later that points to. rk3399 has SPI flash layout and
> > out of which one of offset(script_offset_f=0xffe000 from
> > include/configs/rk3399_common.h) stored the programming script.
>
> So I'm not sure why we're adding distro boot support to SPI flash. What
> is the reference platform storing there exactly? Thanks!
I'm not sure I understand the question? we have rk3399 SBC's that boot
from SPI and have feasibility to run distro boot using programming
script store in flash offset like boot.scr does for MMC.
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 02/11] distro_bootcmd: Add SF support
@ 2020-01-23 17:11 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2020-01-23 17:11 UTC (permalink / raw)
To: u-boot
On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote:
> > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote:
> > >
> > >
> > > On 20.01.20 18:22, Tom Rini wrote:
> > > > +A few people that may have insight to my question
> > > >
> > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> > > >
> > > >> Add distro boot command support for SPI flash.
> > > >>
> > > >> This distro boot will read the boot script at specific
> > > >> location at the flash and start sourcing the same.
> > > >>
> > > >> The common macro like BOOTENV_SHARED_FLASH would help
> > > >> to extend the support for nand flash in future.
> > > >>
> > > >> Cc: Tom Rini <trini@konsulko.com>
> > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > What distro is this for? My concern here is that hundreds of boards
> > > > (literally) grow by a few hundred bytes to add in this bit of additional
> > > > default logic. That's not a big problem if distributions are now going
> > > > to be using SPI flash as where they're programming in their bootscript.
> > > > But, who is doing that? Thanks!
> > >
> > >
> > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of
> > > the SPI Flash.
> > >
> > > Traditionally, SPI Flash boot setups were always very hand crafted -
> > > exactly the opposite of what distro boot is for. That said, I think
> > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally
> > > only store U-Boot and the environment on SPI, not the target OS.
> > >
> > > Jagan, is putting a U-Boot script on the SPI Flash something you thought
> > > of or something that the rk3399 reference board already does? If it's
> > > the latter, maybe you could add it as a board custom boot function?
> >
> > Yes it would be later that points to. rk3399 has SPI flash layout and
> > out of which one of offset(script_offset_f=0xffe000 from
> > include/configs/rk3399_common.h) stored the programming script.
>
> So I'm not sure why we're adding distro boot support to SPI flash. What
> is the reference platform storing there exactly? Thanks!
I'm not sure I understand the question? we have rk3399 SBC's that boot
from SPI and have feasibility to run distro boot using programming
script store in flash offset like boot.scr does for MMC.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 02/11] distro_bootcmd: Add SF support
2020-01-23 17:11 ` Jagan Teki
@ 2020-01-23 17:15 ` Tom Rini
-1 siblings, 0 replies; 91+ messages in thread
From: Tom Rini @ 2020-01-23 17:15 UTC (permalink / raw)
To: Jagan Teki
Cc: open list:ARM/Rockchip SoC...,
Heinrich Schuchardt, U-Boot-Denx, Alexander Graf, linux-amarula
[-- Attachment #1: Type: text/plain, Size: 2891 bytes --]
On Thu, Jan 23, 2020 at 10:41:15PM +0530, Jagan Teki wrote:
> On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote:
> > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote:
> > > >
> > > >
> > > > On 20.01.20 18:22, Tom Rini wrote:
> > > > > +A few people that may have insight to my question
> > > > >
> > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> > > > >
> > > > >> Add distro boot command support for SPI flash.
> > > > >>
> > > > >> This distro boot will read the boot script at specific
> > > > >> location at the flash and start sourcing the same.
> > > > >>
> > > > >> The common macro like BOOTENV_SHARED_FLASH would help
> > > > >> to extend the support for nand flash in future.
> > > > >>
> > > > >> Cc: Tom Rini <trini@konsulko.com>
> > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > > What distro is this for? My concern here is that hundreds of boards
> > > > > (literally) grow by a few hundred bytes to add in this bit of additional
> > > > > default logic. That's not a big problem if distributions are now going
> > > > > to be using SPI flash as where they're programming in their bootscript.
> > > > > But, who is doing that? Thanks!
> > > >
> > > >
> > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of
> > > > the SPI Flash.
> > > >
> > > > Traditionally, SPI Flash boot setups were always very hand crafted -
> > > > exactly the opposite of what distro boot is for. That said, I think
> > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally
> > > > only store U-Boot and the environment on SPI, not the target OS.
> > > >
> > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought
> > > > of or something that the rk3399 reference board already does? If it's
> > > > the latter, maybe you could add it as a board custom boot function?
> > >
> > > Yes it would be later that points to. rk3399 has SPI flash layout and
> > > out of which one of offset(script_offset_f=0xffe000 from
> > > include/configs/rk3399_common.h) stored the programming script.
> >
> > So I'm not sure why we're adding distro boot support to SPI flash. What
> > is the reference platform storing there exactly? Thanks!
>
> I'm not sure I understand the question? we have rk3399 SBC's that boot
> from SPI and have feasibility to run distro boot using programming
> script store in flash offset like boot.scr does for MMC.
OK, and what distro(s) today are doing that? I'm not happy with this
patch as it's growing hundreds (literally) of boards in size and I'd
like to know what is leveraging this functionality today, or is going to
be as soon as it's upstream and widely available. Thanks!
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 02/11] distro_bootcmd: Add SF support
@ 2020-01-23 17:15 ` Tom Rini
0 siblings, 0 replies; 91+ messages in thread
From: Tom Rini @ 2020-01-23 17:15 UTC (permalink / raw)
To: u-boot
On Thu, Jan 23, 2020 at 10:41:15PM +0530, Jagan Teki wrote:
> On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote:
> > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote:
> > > >
> > > >
> > > > On 20.01.20 18:22, Tom Rini wrote:
> > > > > +A few people that may have insight to my question
> > > > >
> > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> > > > >
> > > > >> Add distro boot command support for SPI flash.
> > > > >>
> > > > >> This distro boot will read the boot script at specific
> > > > >> location at the flash and start sourcing the same.
> > > > >>
> > > > >> The common macro like BOOTENV_SHARED_FLASH would help
> > > > >> to extend the support for nand flash in future.
> > > > >>
> > > > >> Cc: Tom Rini <trini@konsulko.com>
> > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > > What distro is this for? My concern here is that hundreds of boards
> > > > > (literally) grow by a few hundred bytes to add in this bit of additional
> > > > > default logic. That's not a big problem if distributions are now going
> > > > > to be using SPI flash as where they're programming in their bootscript.
> > > > > But, who is doing that? Thanks!
> > > >
> > > >
> > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of
> > > > the SPI Flash.
> > > >
> > > > Traditionally, SPI Flash boot setups were always very hand crafted -
> > > > exactly the opposite of what distro boot is for. That said, I think
> > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally
> > > > only store U-Boot and the environment on SPI, not the target OS.
> > > >
> > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought
> > > > of or something that the rk3399 reference board already does? If it's
> > > > the latter, maybe you could add it as a board custom boot function?
> > >
> > > Yes it would be later that points to. rk3399 has SPI flash layout and
> > > out of which one of offset(script_offset_f=0xffe000 from
> > > include/configs/rk3399_common.h) stored the programming script.
> >
> > So I'm not sure why we're adding distro boot support to SPI flash. What
> > is the reference platform storing there exactly? Thanks!
>
> I'm not sure I understand the question? we have rk3399 SBC's that boot
> from SPI and have feasibility to run distro boot using programming
> script store in flash offset like boot.scr does for MMC.
OK, and what distro(s) today are doing that? I'm not happy with this
patch as it's growing hundreds (literally) of boards in size and I'd
like to know what is leveraging this functionality today, or is going to
be as soon as it's upstream and widely available. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200123/8341159e/attachment.sig>
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 02/11] distro_bootcmd: Add SF support
2020-01-23 17:15 ` Tom Rini
@ 2020-01-23 17:29 ` Jagan Teki
-1 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2020-01-23 17:29 UTC (permalink / raw)
To: Tom Rini
Cc: open list:ARM/Rockchip SoC...,
Heinrich Schuchardt, U-Boot-Denx, Alexander Graf, linux-amarula
On Thu, Jan 23, 2020 at 10:45 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Jan 23, 2020 at 10:41:15PM +0530, Jagan Teki wrote:
> > On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote:
> > > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote:
> > > > >
> > > > >
> > > > > On 20.01.20 18:22, Tom Rini wrote:
> > > > > > +A few people that may have insight to my question
> > > > > >
> > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> > > > > >
> > > > > >> Add distro boot command support for SPI flash.
> > > > > >>
> > > > > >> This distro boot will read the boot script at specific
> > > > > >> location at the flash and start sourcing the same.
> > > > > >>
> > > > > >> The common macro like BOOTENV_SHARED_FLASH would help
> > > > > >> to extend the support for nand flash in future.
> > > > > >>
> > > > > >> Cc: Tom Rini <trini@konsulko.com>
> > > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > > > What distro is this for? My concern here is that hundreds of boards
> > > > > > (literally) grow by a few hundred bytes to add in this bit of additional
> > > > > > default logic. That's not a big problem if distributions are now going
> > > > > > to be using SPI flash as where they're programming in their bootscript.
> > > > > > But, who is doing that? Thanks!
> > > > >
> > > > >
> > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of
> > > > > the SPI Flash.
> > > > >
> > > > > Traditionally, SPI Flash boot setups were always very hand crafted -
> > > > > exactly the opposite of what distro boot is for. That said, I think
> > > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally
> > > > > only store U-Boot and the environment on SPI, not the target OS.
> > > > >
> > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought
> > > > > of or something that the rk3399 reference board already does? If it's
> > > > > the latter, maybe you could add it as a board custom boot function?
> > > >
> > > > Yes it would be later that points to. rk3399 has SPI flash layout and
> > > > out of which one of offset(script_offset_f=0xffe000 from
> > > > include/configs/rk3399_common.h) stored the programming script.
> > >
> > > So I'm not sure why we're adding distro boot support to SPI flash. What
> > > is the reference platform storing there exactly? Thanks!
> >
> > I'm not sure I understand the question? we have rk3399 SBC's that boot
> > from SPI and have feasibility to run distro boot using programming
> > script store in flash offset like boot.scr does for MMC.
>
> OK, and what distro(s) today are doing that? I'm not happy with this
> patch as it's growing hundreds (literally) of boards in size and I'd
> like to know what is leveraging this functionality today, or is going to
> be as soon as it's upstream and widely available. Thanks!
Not sure about the possibility more boards using this at this point,
but I was initially created custom to rockchip and feel that it would
be useful to rest if it's generic. May be will split into rockchip
area if it's eating too much footprint.
Jagan.
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 02/11] distro_bootcmd: Add SF support
@ 2020-01-23 17:29 ` Jagan Teki
0 siblings, 0 replies; 91+ messages in thread
From: Jagan Teki @ 2020-01-23 17:29 UTC (permalink / raw)
To: u-boot
On Thu, Jan 23, 2020 at 10:45 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Jan 23, 2020 at 10:41:15PM +0530, Jagan Teki wrote:
> > On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote:
> > > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote:
> > > > >
> > > > >
> > > > > On 20.01.20 18:22, Tom Rini wrote:
> > > > > > +A few people that may have insight to my question
> > > > > >
> > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> > > > > >
> > > > > >> Add distro boot command support for SPI flash.
> > > > > >>
> > > > > >> This distro boot will read the boot script at specific
> > > > > >> location at the flash and start sourcing the same.
> > > > > >>
> > > > > >> The common macro like BOOTENV_SHARED_FLASH would help
> > > > > >> to extend the support for nand flash in future.
> > > > > >>
> > > > > >> Cc: Tom Rini <trini@konsulko.com>
> > > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > > > What distro is this for? My concern here is that hundreds of boards
> > > > > > (literally) grow by a few hundred bytes to add in this bit of additional
> > > > > > default logic. That's not a big problem if distributions are now going
> > > > > > to be using SPI flash as where they're programming in their bootscript.
> > > > > > But, who is doing that? Thanks!
> > > > >
> > > > >
> > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of
> > > > > the SPI Flash.
> > > > >
> > > > > Traditionally, SPI Flash boot setups were always very hand crafted -
> > > > > exactly the opposite of what distro boot is for. That said, I think
> > > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally
> > > > > only store U-Boot and the environment on SPI, not the target OS.
> > > > >
> > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought
> > > > > of or something that the rk3399 reference board already does? If it's
> > > > > the latter, maybe you could add it as a board custom boot function?
> > > >
> > > > Yes it would be later that points to. rk3399 has SPI flash layout and
> > > > out of which one of offset(script_offset_f=0xffe000 from
> > > > include/configs/rk3399_common.h) stored the programming script.
> > >
> > > So I'm not sure why we're adding distro boot support to SPI flash. What
> > > is the reference platform storing there exactly? Thanks!
> >
> > I'm not sure I understand the question? we have rk3399 SBC's that boot
> > from SPI and have feasibility to run distro boot using programming
> > script store in flash offset like boot.scr does for MMC.
>
> OK, and what distro(s) today are doing that? I'm not happy with this
> patch as it's growing hundreds (literally) of boards in size and I'd
> like to know what is leveraging this functionality today, or is going to
> be as soon as it's upstream and widely available. Thanks!
Not sure about the possibility more boards using this at this point,
but I was initially created custom to rockchip and feel that it would
be useful to rest if it's generic. May be will split into rockchip
area if it's eating too much footprint.
Jagan.
^ permalink raw reply [flat|nested] 91+ messages in thread
* Re: [PATCH 02/11] distro_bootcmd: Add SF support
2020-01-23 17:29 ` Jagan Teki
@ 2020-01-23 17:59 ` Tom Rini
-1 siblings, 0 replies; 91+ messages in thread
From: Tom Rini @ 2020-01-23 17:59 UTC (permalink / raw)
To: Jagan Teki
Cc: open list:ARM/Rockchip SoC...,
Heinrich Schuchardt, U-Boot-Denx, Alexander Graf, linux-amarula
[-- Attachment #1: Type: text/plain, Size: 3672 bytes --]
On Thu, Jan 23, 2020 at 10:59:17PM +0530, Jagan Teki wrote:
> On Thu, Jan 23, 2020 at 10:45 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Jan 23, 2020 at 10:41:15PM +0530, Jagan Teki wrote:
> > > On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote:
> > > > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote:
> > > > > >
> > > > > >
> > > > > > On 20.01.20 18:22, Tom Rini wrote:
> > > > > > > +A few people that may have insight to my question
> > > > > > >
> > > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> > > > > > >
> > > > > > >> Add distro boot command support for SPI flash.
> > > > > > >>
> > > > > > >> This distro boot will read the boot script at specific
> > > > > > >> location at the flash and start sourcing the same.
> > > > > > >>
> > > > > > >> The common macro like BOOTENV_SHARED_FLASH would help
> > > > > > >> to extend the support for nand flash in future.
> > > > > > >>
> > > > > > >> Cc: Tom Rini <trini@konsulko.com>
> > > > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > > > > What distro is this for? My concern here is that hundreds of boards
> > > > > > > (literally) grow by a few hundred bytes to add in this bit of additional
> > > > > > > default logic. That's not a big problem if distributions are now going
> > > > > > > to be using SPI flash as where they're programming in their bootscript.
> > > > > > > But, who is doing that? Thanks!
> > > > > >
> > > > > >
> > > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of
> > > > > > the SPI Flash.
> > > > > >
> > > > > > Traditionally, SPI Flash boot setups were always very hand crafted -
> > > > > > exactly the opposite of what distro boot is for. That said, I think
> > > > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally
> > > > > > only store U-Boot and the environment on SPI, not the target OS.
> > > > > >
> > > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought
> > > > > > of or something that the rk3399 reference board already does? If it's
> > > > > > the latter, maybe you could add it as a board custom boot function?
> > > > >
> > > > > Yes it would be later that points to. rk3399 has SPI flash layout and
> > > > > out of which one of offset(script_offset_f=0xffe000 from
> > > > > include/configs/rk3399_common.h) stored the programming script.
> > > >
> > > > So I'm not sure why we're adding distro boot support to SPI flash. What
> > > > is the reference platform storing there exactly? Thanks!
> > >
> > > I'm not sure I understand the question? we have rk3399 SBC's that boot
> > > from SPI and have feasibility to run distro boot using programming
> > > script store in flash offset like boot.scr does for MMC.
> >
> > OK, and what distro(s) today are doing that? I'm not happy with this
> > patch as it's growing hundreds (literally) of boards in size and I'd
> > like to know what is leveraging this functionality today, or is going to
> > be as soon as it's upstream and widely available. Thanks!
>
> Not sure about the possibility more boards using this at this point,
> but I was initially created custom to rockchip and feel that it would
> be useful to rest if it's generic. May be will split into rockchip
> area if it's eating too much footprint.
Yes, the "distro boot" functionality refers to what we need to allow
boards to easily Just Work with standard off the shelf *nix
distributions. Thanks!
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 91+ messages in thread
* [PATCH 02/11] distro_bootcmd: Add SF support
@ 2020-01-23 17:59 ` Tom Rini
0 siblings, 0 replies; 91+ messages in thread
From: Tom Rini @ 2020-01-23 17:59 UTC (permalink / raw)
To: u-boot
On Thu, Jan 23, 2020 at 10:59:17PM +0530, Jagan Teki wrote:
> On Thu, Jan 23, 2020 at 10:45 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Jan 23, 2020 at 10:41:15PM +0530, Jagan Teki wrote:
> > > On Thu, Jan 23, 2020 at 10:33 PM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Jan 23, 2020 at 10:25:50PM +0530, Jagan Teki wrote:
> > > > > On Mon, Jan 20, 2020 at 11:10 PM Alexander Graf <agraf@csgraf.de> wrote:
> > > > > >
> > > > > >
> > > > > > On 20.01.20 18:22, Tom Rini wrote:
> > > > > > > +A few people that may have insight to my question
> > > > > > >
> > > > > > > On Sat, Dec 21, 2019 at 01:24:31PM +0530, Jagan Teki wrote:
> > > > > > >
> > > > > > >> Add distro boot command support for SPI flash.
> > > > > > >>
> > > > > > >> This distro boot will read the boot script at specific
> > > > > > >> location at the flash and start sourcing the same.
> > > > > > >>
> > > > > > >> The common macro like BOOTENV_SHARED_FLASH would help
> > > > > > >> to extend the support for nand flash in future.
> > > > > > >>
> > > > > > >> Cc: Tom Rini <trini@konsulko.com>
> > > > > > >> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> > > > > > > What distro is this for? My concern here is that hundreds of boards
> > > > > > > (literally) grow by a few hundred bytes to add in this bit of additional
> > > > > > > default logic. That's not a big problem if distributions are now going
> > > > > > > to be using SPI flash as where they're programming in their bootscript.
> > > > > > > But, who is doing that? Thanks!
> > > > > >
> > > > > >
> > > > > > I am not aware of any "distro" that puts a U-Boot script at offset 0 of
> > > > > > the SPI Flash.
> > > > > >
> > > > > > Traditionally, SPI Flash boot setups were always very hand crafted -
> > > > > > exactly the opposite of what distro boot is for. That said, I think
> > > > > > supporting SPI Flash boot for rk3399 is great! Albeit I would personally
> > > > > > only store U-Boot and the environment on SPI, not the target OS.
> > > > > >
> > > > > > Jagan, is putting a U-Boot script on the SPI Flash something you thought
> > > > > > of or something that the rk3399 reference board already does? If it's
> > > > > > the latter, maybe you could add it as a board custom boot function?
> > > > >
> > > > > Yes it would be later that points to. rk3399 has SPI flash layout and
> > > > > out of which one of offset(script_offset_f=0xffe000 from
> > > > > include/configs/rk3399_common.h) stored the programming script.
> > > >
> > > > So I'm not sure why we're adding distro boot support to SPI flash. What
> > > > is the reference platform storing there exactly? Thanks!
> > >
> > > I'm not sure I understand the question? we have rk3399 SBC's that boot
> > > from SPI and have feasibility to run distro boot using programming
> > > script store in flash offset like boot.scr does for MMC.
> >
> > OK, and what distro(s) today are doing that? I'm not happy with this
> > patch as it's growing hundreds (literally) of boards in size and I'd
> > like to know what is leveraging this functionality today, or is going to
> > be as soon as it's upstream and widely available. Thanks!
>
> Not sure about the possibility more boards using this at this point,
> but I was initially created custom to rockchip and feel that it would
> be useful to rest if it's generic. May be will split into rockchip
> area if it's eating too much footprint.
Yes, the "distro boot" functionality refers to what we need to allow
boards to easily Just Work with standard off the shelf *nix
distributions. Thanks!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200123/8aed65e2/attachment.sig>
^ permalink raw reply [flat|nested] 91+ messages in thread
end of thread, other threads:[~2020-01-23 17:59 UTC | newest]
Thread overview: 91+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-21 7:54 [PATCH 00/11] rk3399: SPI boot support (fixes, updates) Jagan Teki
2019-12-21 7:54 ` Jagan Teki
[not found] ` <20191221075440.6944-1-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
2019-12-21 7:54 ` [PATCH 01/11] spi: rk: Limit transfers to (64K - 1) bytes Jagan Teki
2019-12-21 7:54 ` Jagan Teki
[not found] ` <20191221075440.6944-2-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
2019-12-23 2:30 ` Kever Yang
2019-12-23 2:30 ` Kever Yang
2019-12-27 5:55 ` Jagan Teki
2019-12-27 5:55 ` Jagan Teki
2019-12-21 7:54 ` [PATCH 02/11] distro_bootcmd: Add SF support Jagan Teki
2019-12-21 7:54 ` Jagan Teki
2019-12-30 3:07 ` Kever Yang
2019-12-30 3:07 ` Kever Yang
2020-01-20 17:22 ` Tom Rini
2020-01-20 17:22 ` Tom Rini
2020-01-20 17:40 ` Alexander Graf
2020-01-20 17:40 ` Alexander Graf
2020-01-23 16:55 ` Jagan Teki
2020-01-23 16:55 ` Jagan Teki
2020-01-23 17:03 ` Tom Rini
2020-01-23 17:03 ` Tom Rini
2020-01-23 17:11 ` Jagan Teki
2020-01-23 17:11 ` Jagan Teki
2020-01-23 17:15 ` Tom Rini
2020-01-23 17:15 ` Tom Rini
2020-01-23 17:29 ` Jagan Teki
2020-01-23 17:29 ` Jagan Teki
2020-01-23 17:59 ` Tom Rini
2020-01-23 17:59 ` Tom Rini
2019-12-21 7:54 ` [PATCH 03/11] rockchip: Include SF on distrocmd devices Jagan Teki
2019-12-21 7:54 ` Jagan Teki
[not found] ` <20191221075440.6944-4-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
2019-12-30 3:07 ` Kever Yang
2020-01-07 8:44 ` Kever Yang
2020-01-07 8:44 ` Kever Yang
2019-12-21 7:54 ` [PATCH 04/11] rk3399: Add boot flash script offet, size Jagan Teki
2019-12-21 7:54 ` Jagan Teki
2019-12-30 3:06 ` Kever Yang
2019-12-30 3:06 ` Kever Yang
2019-12-21 7:54 ` [PATCH 05/11] rk3399: Check MMC env while defining it Jagan Teki
2019-12-21 7:54 ` Jagan Teki
2019-12-30 3:06 ` Kever Yang
2019-12-30 3:06 ` Kever Yang
2019-12-21 7:54 ` [PATCH 06/11] env: kconfig: Restrict rockchip env for MMC Jagan Teki
2019-12-21 7:54 ` Jagan Teki
2019-12-30 3:05 ` Kever Yang
2019-12-30 3:05 ` Kever Yang
2019-12-21 7:54 ` [PATCH 07/11] env: Enable SPI flash env for rockchip Jagan Teki
2019-12-21 7:54 ` Jagan Teki
2019-12-23 2:34 ` Kever Yang
2019-12-23 2:34 ` Kever Yang
2019-12-27 6:50 ` Jagan Teki
2019-12-27 6:50 ` Jagan Teki
2019-12-27 10:02 ` Kever Yang
2019-12-27 10:02 ` Kever Yang
2019-12-27 10:10 ` Jagan Teki
2019-12-27 10:10 ` Jagan Teki
2019-12-27 10:30 ` Soeren Moch
2019-12-27 10:30 ` Soeren Moch
2019-12-27 12:04 ` Jagan Teki
2019-12-27 12:04 ` Jagan Teki
2019-12-27 13:19 ` Soeren Moch
2019-12-27 13:19 ` Soeren Moch
[not found] ` <30fdf54b-0f71-ffbf-ac57-51050a29b56d-S0/GAf8tV78@public.gmane.org>
2019-12-28 12:08 ` Jagan Teki
2019-12-28 12:08 ` Jagan Teki
2019-12-30 9:04 ` Soeren Moch
2019-12-30 9:04 ` Soeren Moch
2019-12-30 2:59 ` Kever Yang
2019-12-30 2:59 ` Kever Yang
2019-12-21 7:54 ` [PATCH 08/11] rockchip: dts: Sync ROC-RK3399-PC changes from Linux Jagan Teki
2019-12-21 7:54 ` Jagan Teki
[not found] ` <20191221075440.6944-9-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
2019-12-30 3:00 ` Kever Yang
2019-12-30 3:00 ` Kever Yang
2019-12-21 7:54 ` [PATCH 09/11] roc-pc-rk3399: Enable SPI Flash Jagan Teki
2019-12-21 7:54 ` Jagan Teki
[not found] ` <20191221075440.6944-10-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
2019-12-30 3:00 ` Kever Yang
2019-12-30 3:00 ` Kever Yang
2019-12-21 7:54 ` [PATCH 10/11] rockpro-rk3399: " Jagan Teki
2019-12-21 7:54 ` Jagan Teki
2019-12-30 3:00 ` Kever Yang
2019-12-30 3:00 ` Kever Yang
[not found] ` <20191221075440.6944-11-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
2019-12-30 11:51 ` Emmanuel Vadot
2019-12-30 11:51 ` Emmanuel Vadot
2020-01-08 12:59 ` Jagan Teki
2020-01-08 12:59 ` Jagan Teki
2019-12-21 7:54 ` [PATCH 11/11] roc-rk3399-pc: Add SPI boot support Jagan Teki
2019-12-21 7:54 ` Jagan Teki
2019-12-30 3:05 ` Kever Yang
2019-12-30 3:05 ` Kever Yang
2019-12-30 7:52 ` Jagan Teki
2019-12-30 7:52 ` Jagan Teki
[not found] ` <CAMty3ZA1u3-21QN4N6W=9Sq3n493BBBB2W_FzAEQC9aze4SoMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2020-01-07 8:53 ` Kever Yang
2020-01-07 8:53 ` Kever Yang
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.