[PATCH v2 00/12] Puma RK3399 migration to TPL and numerous fixes

[PATCH v2 00/12] Puma RK3399 migration to TPL and numerous fixes

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Puma RK3399 SoM struggled for a few releases already to boot because the
SPL was too big. Therefore, let's migrate to TPL like most RK3399-boards
already did a few releases ago.

This also fixes numerous issues around fallback booting (U-Boot proper
corrupted on the storage medium from where TPL/SPL was loaded) and default
order of boot targets.

It also forces the environment storage medium to be the same as the one
from which U-Boot proper was loaded, for a more consistent user
experience.

The environment can also be stored on SPI flash now.

Finally some cleanup and the migration of the flashing instructions to
u-boot-rockchip.bin and u-boot-rockchip-spi.bin.

A small patch for Lion RK3368 also, for migrating the flashing
instructions to u-boot-rockchip.bin.

Cheers,
Quentin

v2:
 - rebase on top of latest master,
 - removed dependency on patch removing SPL_PAD_TO by moving the
 "custom" SPL payload offset to puma/lion u-boot dtsi,

Quentin Schulz (12):
  rockchip: puma-rk3399: fix boot_targets swap depending on U-Boot
    proper load medium
  rockchip: puma-rk3399: use gpio-hog instead of fixed-regulator for
    enabling eMMC/SPI-NOR
  rockchip: puma-rk3399: allow non-SD-Card-loaded SPL to load U-Boot
    proper from SD-Card
  rockchip: puma-rk3399: remove unused default ENV_OFFSET for SPI
    flashes
  rockchip: puma-rk3399: load environment from same MMC as used for
    loading U-Boot proper
  rockchip: puma-rk3399: allow loading environment from SPI-NOR flash
  rockchip: puma-rk3399: load environment from same medium as one used
    to load U-Boot proper
  rockchip: puma-rk3399: remove useless CONFIG_SYS_SPI_U_BOOT_OFFS
  rockchip: puma-rk3399: migrate to TPL
  rockchip: puma-rk3399: migrate to u-boot-rockchip.bin
  rockchip: lion-rk3368: migrate to u-boot-rockchip.bin
  rockchip: puma-rk3399: migrate to u-boot-rockchip-spi.bin

 arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi   |  8 ++
 arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi   | 75 ++++++++++++-----
 board/theobroma-systems/lion_rk3368/README    |  9 +-
 board/theobroma-systems/puma_rk3399/Kconfig   |  3 -
 board/theobroma-systems/puma_rk3399/README    | 22 ++---
 .../puma_rk3399/puma-rk3399.c                 | 84 ++++++++++++++++---
 configs/puma-rk3399_defconfig                 | 16 ++--
 7 files changed, 153 insertions(+), 64 deletions(-)

-- 
2.37.3

[PATCH v2 01/12] rockchip: puma-rk3399: fix boot_targets swap depending on U-Boot proper load medium

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

distroboot should try first on the same MMC medium as the one the SPL
loaded U-Boot proper from. This was the case when the introducing commit
was merged because the default order was eMMC first and then SD card.
The check was therefore made only on whether we booted from SD card,
because otherwise the order was the expected one.
However, in commit b212ad24a604 ("rockchip: Fix MMC boot order"), the
order was swapped. Meaning our simple check is now useless.

Let's fix that by accounting for all scenarii: default boot_targets has
mmc0 first but booting from SD Card, mmc1 first but booting from eMMC.

Fixes: b212ad24a604 ("rockchip: Fix MMC boot order")
Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
---
 .../puma_rk3399/puma-rk3399.c                 | 25 ++++++++++---------
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
index deeba3084a..ce3436b770 100644
--- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
+++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
@@ -77,18 +77,16 @@ static int setup_boottargets(void)
 	}
 
 	/*
-	 * Only run, if booting from mmc1 (i.e. /mmc@fe320000) and
-	 * only consider cases where the default boot-order first
-	 * tries to boot from mmc0 (eMMC) and then from mmc1
-	 * (i.e. external SD).
-	 *
-	 * In other words: the SD card will be moved to earlier in the
-	 * order, if U-Boot was also loaded from the SD-card.
+	 * Make the default boot medium between SD Card and eMMC, the one that
+	 * was used to load U-Boot proper. If SPI-NOR flash was used, keep
+	 * original default order.
 	 */
-	if (!strcmp(boot_device, "/mmc@fe320000")) {
+	if (strcmp(boot_device, "/spi@ff1d0000/flash@0")) {
+		bool sd_booted = !strcmp(boot_device, "/mmc@fe320000");
 		char *mmc0, *mmc1;
 
-		debug("%s: booted from SD-Card\n", __func__);
+		debug("%s: booted from %s\n", __func__,
+		      sd_booted ? "SD-Card" : "eMMC");
 		mmc0 = strstr(env, "mmc0");
 		mmc1 = strstr(env, "mmc1");
 
@@ -98,10 +96,13 @@ static int setup_boottargets(void)
 		}
 
 		/*
-		 * If mmc0 comes first in the boot order, we need to change
-		 * the strings to make mmc1 first.
+		 * If mmc0 comes first in the boot order and U-Boot proper was
+		 * loaded from mmc1, swap mmc0 and mmc1 in the list.
+		 * If mmc1 comes first in the boot order and U-Boot proper was
+		 * loaded from mmc0, swap mmc0 and mmc1 in the list.
 		 */
-		if (mmc0 < mmc1) {
+		if ((mmc0 < mmc1 && sd_booted) ||
+		    (mmc0 > mmc1 && !sd_booted)) {
 			mmc0[3] = '1';
 			mmc1[3] = '0';
 			debug("%s: set boot_targets to: %s\n", __func__, env);
-- 
2.37.3

[PATCH v2 02/12] rockchip: puma-rk3399: use gpio-hog instead of fixed-regulator for enabling eMMC/SPI-NOR

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

On Haikou devkit, it is possible to disable eMMC and SPI-NOR to force
booting from SD card or USB via rkdeveloptool by toggling a switch. This
switch needs to be overridden in software to be able to access eMMC and
SPI-NOR once the device has booted from SD Card. Puma SoM can override
this pin via gpio3_d5.

Until now, fixed regulator device was abused to model this, but since
there's now support for GPIO hogs, let's use it.

Since we want to be able to boot the SPL from SD Card but give it the
ability to load U-Boot proper from a fallback medium such as eMMC and
SPI-NOR, SPL support for GPIO hogs needs to be enabled too. Support for
other kinds of regulators are not needed anymore, so let's disable them.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
---
 arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 32 +++++++++------------
 configs/puma-rk3399_defconfig               |  5 ++--
 2 files changed, 16 insertions(+), 21 deletions(-)

diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
index e0476ab25c..b9b6ac3f6c 100644
--- a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
@@ -31,24 +31,6 @@
 		spi5 = &spi5;
 	};
 
-	/*
-	 * The Qseven BIOS_DISABLE signal on the RK3399-Q7 keeps the on-module
-	 * eMMC and SPI flash powered-down initially (in fact it keeps the
-	 * reset signal asserted).  Even though it is an enable signal, we
-	 * model this as a regulator.
-	 */
-	bios_enable: bios_enable {
-		compatible = "regulator-fixed";
-		u-boot,dm-pre-reloc;
-		regulator-name = "bios_enable";
-		enable-active-high;
-		gpio = <&gpio3 RK_PD5 GPIO_ACTIVE_LOW>;
-		regulator-always-on;
-		regulator-boot-on;
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-	};
-
 	vdd_log: vdd-log {
 		compatible = "pwm-regulator";
 		pwms = <&pwm2 0 25000 1>;
@@ -68,6 +50,20 @@
 
 &gpio3 {
 	u-boot,dm-pre-reloc;
+
+	/*
+	 * The Qseven BIOS_DISABLE signal on the RK3399-Q7 keeps the on-module
+	 * eMMC and SPI flash powered-down initially (in fact it keeps the
+	 * reset signal asserted). BIOS_DISABLE_OVERRIDE pin allows to re-enable
+	 * eMMC and SPI after the SPL has been booted from SD Card.
+	 */
+	bios_disable_override {
+		u-boot,dm-pre-reloc;
+		gpios = <RK_PD5 GPIO_ACTIVE_LOW>;
+		output-high;
+		line-name = "bios_disable_override";
+		gpio-hog;
+	};
 };
 
 &norflash {
diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index 6acc442ba8..6082b67523 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -58,6 +58,8 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_SYS_MMC_ENV_DEV=1
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_GPIO_HOG=y
+CONFIG_SPL_GPIO_HOG=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_MISC=y
@@ -80,10 +82,7 @@ CONFIG_PHY_ROCKCHIP_TYPEC=y
 CONFIG_DM_PMIC_FAN53555=y
 CONFIG_PMIC_RK8XX=y
 CONFIG_SPL_PMIC_RK8XX=y
-CONFIG_SPL_DM_REGULATOR=y
 CONFIG_REGULATOR_PWM=y
-CONFIG_SPL_DM_REGULATOR_FIXED=y
-CONFIG_DM_REGULATOR_GPIO=y
 CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_DM_RESET=y
-- 
2.37.3

[PATCH v2 03/12] rockchip: puma-rk3399: allow non-SD-Card-loaded SPL to load U-Boot proper from SD-Card

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Trying to load U-Boot proper from SPL when SPL was not loaded from
SD-Card is currently not working because the SDMMC pins aren't muxed
correctly. It is assumed the BootROM is doing this for us when booting
from SD-Card hence why it's not needed when booting TPL/SPL from
SD-Card.

The pinctrl properties are removed from the SPL DT property removal list
and the pinctrl configuration nodes made available in the SPL DT, in
addition to the pull-up configurations to allow loading U-Boot proper
from SD-Card as a fallback mechanism for SPI-NOR and eMMC.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
---
 arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 24 +++++++++++++++++++++
 configs/puma-rk3399_defconfig               |  2 +-
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
index b9b6ac3f6c..5dc345bbe8 100644
--- a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
@@ -66,6 +66,30 @@
 	};
 };
 
+&gpio4 {
+	u-boot,dm-pre-reloc;
+};
+
 &norflash {
 	u-boot,dm-pre-reloc;
 };
+
+&pcfg_pull_none {
+	u-boot,dm-pre-reloc;
+};
+
+&pcfg_pull_up {
+	u-boot,dm-pre-reloc;
+};
+
+&sdmmc_bus4 {
+	u-boot,dm-pre-reloc;
+};
+
+&sdmmc_clk {
+	u-boot,dm-pre-reloc;
+};
+
+&sdmmc_cmd {
+	u-boot,dm-pre-reloc;
+};
diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index 6082b67523..1b0bf8848a 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -51,7 +51,7 @@ CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIVE=y
-CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_OVERWRITE=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
-- 
2.37.3

[PATCH v2 04/12] rockchip: puma-rk3399: remove unused default ENV_OFFSET for SPI flashes

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

CONFIG_ENV_OFFSET is set in the defconfig to a different value already
so this isn't used. Let's remove it as to not confuse users.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
---
 board/theobroma-systems/puma_rk3399/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/board/theobroma-systems/puma_rk3399/Kconfig b/board/theobroma-systems/puma_rk3399/Kconfig
index 21946d984d..15af55574c 100644
--- a/board/theobroma-systems/puma_rk3399/Kconfig
+++ b/board/theobroma-systems/puma_rk3399/Kconfig
@@ -15,9 +15,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
 config ENV_SIZE
 	default 0x4000
 
-config ENV_OFFSET
-	default 0x3fc000 if ENV_IS_IN_SPI_FLASH
-
 choice
 	prompt "Theobroma Systems RK3399-Q7 DDR Option"
 	default TARGET_PUMA_RK3399_RAM_DDR3_1333
-- 
2.37.3

[PATCH v2 05/12] rockchip: puma-rk3399: load environment from same MMC as used for loading U-Boot proper

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Automatically detect which MMC device (SD-Card or eMMC) was used to load
U-Boot proper and load the environment from that MMC device instead of
a hardcoded one.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
---
 .../puma_rk3399/puma-rk3399.c                 | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
index ce3436b770..5e5e58c88e 100644
--- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
+++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
@@ -113,6 +113,28 @@ static int setup_boottargets(void)
 	return 0;
 }
 
+int mmc_get_env_dev(void)
+{
+	const char *boot_device =
+		ofnode_read_chosen_string("u-boot,spl-boot-device");
+
+	if (!boot_device) {
+		debug("%s: /chosen/u-boot,spl-boot-device not set\n",
+		      __func__);
+		return CONFIG_SYS_MMC_ENV_DEV;
+	}
+
+	debug("%s: booted from %s\n", __func__, boot_device);
+
+	if (!strcmp(boot_device, "/mmc@fe320000"))
+		return 1;
+
+	if (!strcmp(boot_device, "/mmc@fe330000"))
+		return 0;
+
+	return CONFIG_SYS_MMC_ENV_DEV;
+}
+
 int misc_init_r(void)
 {
 	const u32 cpuid_offset = 0x7;
-- 
2.37.3

[PATCH v2 06/12] rockchip: puma-rk3399: allow loading environment from SPI-NOR flash

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

There's a SPI-NOR flash available from which SPL and U-Boot proper can
be booted, it makes sense to also allow this medium to store U-Boot
environment so let's enable it.

The Device Tree advertises a max frequency of 50MHz so let's set the
config option appropriately.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
---
 configs/puma-rk3399_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index 1b0bf8848a..f62cfc9aab 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -54,6 +54,8 @@ CONFIG_OF_LIVE=y
 CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_OVERWRITE=y
 CONFIG_ENV_IS_IN_MMC=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_ENV_SPI_MAX_HZ=50000000
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_SYS_MMC_ENV_DEV=1
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
-- 
2.37.3

[PATCH v2 07/12] rockchip: puma-rk3399: load environment from same medium as one used to load U-Boot proper

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Chances are when one boots U-Boot proper from a given storage medium,
they want the same medium to be used to load and store the environment.

This basically allows to have completely separate U-Boot (TPL/SPL/U-Boot
proper/environment) per storage medium which is convenient when working
with recovery from SD-Card as one would just need to insert a properly
configured SD-Card into the device to have access to their whole debug
setup.

No fallback mechanism is provided as to not dirty other storage medium
environment by mistake. However, since arch_env_get_location() is called
by env_init() which is part of the pre-relocation process, a valid,
non-ENVL_UNKNOWN, value shall be returned otherwise the relocation fails
with the following message:
initcall sequence 00000000002866c0 failed at call 0000000000256b34 (err=-19)

This valid, non-ENVL_UNKNOWN, value is ENVL_NOWHERE which requires to
always select CONFIG_ENV_IS_NOWHERE otherwise this work-around does not
work.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 .../puma_rk3399/puma-rk3399.c                 | 37 +++++++++++++++++++
 configs/puma-rk3399_defconfig                 |  1 +
 2 files changed, 38 insertions(+)

diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
index 5e5e58c88e..7ef4bac24b 100644
--- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
+++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
@@ -6,6 +6,7 @@
 #include <common.h>
 #include <dm.h>
 #include <env.h>
+#include <env_internal.h>
 #include <init.h>
 #include <log.h>
 #include <misc.h>
@@ -135,6 +136,42 @@ int mmc_get_env_dev(void)
 	return CONFIG_SYS_MMC_ENV_DEV;
 }
 
+#if !IS_ENABLED(CONFIG_ENV_IS_NOWHERE)
+#error Please enable CONFIG_ENV_IS_NOWHERE
+#endif
+
+enum env_location arch_env_get_location(enum env_operation op, int prio)
+{
+	const char *boot_device =
+		ofnode_read_chosen_string("u-boot,spl-boot-device");
+
+	if (prio > 0)
+		return ENVL_UNKNOWN;
+
+	if (!boot_device) {
+		debug("%s: /chosen/u-boot,spl-boot-device not set\n",
+		      __func__);
+		return ENVL_NOWHERE;
+	}
+
+	debug("%s: booted from %s\n", __func__, boot_device);
+
+	if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH) &&
+	    !strcmp(boot_device, "/spi@ff1d0000/flash@0"))
+		return ENVL_SPI_FLASH;
+
+	if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC) &&
+	    (!strcmp(boot_device, "/mmc@fe320000") ||
+	     !strcmp(boot_device, "/mmc@fe330000")))
+		return ENVL_MMC;
+
+	printf("%s: No environment available: booted from %s but U-Boot "
+	       "config does not allow loading environment from it.",
+	       __func__, boot_device);
+
+	return ENVL_NOWHERE;
+}
+
 int misc_init_r(void)
 {
 	const u32 cpuid_offset = 0x7;
diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index f62cfc9aab..cfa743668b 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -53,6 +53,7 @@ CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_LIVE=y
 CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
 CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_NOWHERE=y
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_ENV_SPI_MAX_HZ=50000000
-- 
2.37.3

[PATCH v2 08/12] rockchip: puma-rk3399: remove useless CONFIG_SYS_SPI_U_BOOT_OFFS

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

The SPL payload offset when booting from SPI defaults to
CONFIG_SYS_SPI_U_BOOT_OFFS but can be overridden by
u-boot,spl-payload-offset. The Device Tree for Puma Haikou has this
property so there's no need to have this one option in the defconfig,
especially since they are not in sync and therefore confusing.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
---
 configs/puma-rk3399_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index cfa743668b..8c153e66e0 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -36,7 +36,6 @@ CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
 CONFIG_SPL_I2C=y
 CONFIG_SPL_POWER=y
 CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x20000
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
-- 
2.37.3

[PATCH v2 09/12] rockchip: puma-rk3399: migrate to TPL

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Depending on the toolchain used to compile the SPL for Puma RK3399-Q7
module, the board does not boot because the resulting binary is too big
to fit in SRAM.

Let's add a TPL so that there's no need to fiddle with or hack the
defconfig to have a working bootloader.

This follows what's been done for the majority of other RK3399-based
boards.

See the original commit for the first migrations:
bdc00080111f "rockchip: rk3399: update defconfig for TPL"

Unfortunately, the offset in SPI-NOR for U-Boot proper needs to be
modified, since the move from SPL to TPL+SPL for idbloader.img (and the
"only the first 2KB per 4KB blocks are written" "hack" for rkspi format)
increased the size above 256KB. Let's move it to 512KB to, hopefully, be
safe.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
---
 arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 2 +-
 board/theobroma-systems/puma_rk3399/README  | 8 ++++----
 configs/puma-rk3399_defconfig               | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
index 5dc345bbe8..27a792fe6d 100644
--- a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
@@ -14,7 +14,7 @@
 
 / {
 	config {
-		u-boot,spl-payload-offset = <0x40000>; /* @ 256KB */
+		u-boot,spl-payload-offset = <0x80000>; /* @ 512KB */
 		u-boot,mmc-env-offset = <0x4000>;      /* @  16KB */
 		u-boot,efi-partition-entries-offset = <0x200000>; /* 2MB */
 		u-boot,boot-led = "module_led";
diff --git a/board/theobroma-systems/puma_rk3399/README b/board/theobroma-systems/puma_rk3399/README
index 254c3bbe96..550bdfb1f4 100644
--- a/board/theobroma-systems/puma_rk3399/README
+++ b/board/theobroma-systems/puma_rk3399/README
@@ -51,13 +51,13 @@ The SPL image for SD-Card/eMMC is readily available in idbloader.img at the
 root of U-Boot after compilation.
 
 Creating an SPL image for SPI-NOR:
-  > tools/mkimage -n rk3399 -T rkspi -d spl/u-boot-spl.bin idbloader-spi.img
+  > tools/mkimage -n rk3399 -T rkspi -d tpl/u-boot-tpl.bin:spl/u-boot-spl.bin idbloader-spi.img
 
 Flash the image
 ===============
 
-Copy the SPL to offset 32k for SD/eMMC, offset 0 for NOR-Flash and the FIT
-image to offset 256k.
+Copy the SPL to offset 32k and the FIT image to offset 256k for SD/eMMC.
+Copy the SPL to offset 0 and the FIT image to offset 512k for NOR-Flash.
 
 SD-Card
 -------
@@ -98,4 +98,4 @@ help of the Rockchip loader binary.
   > ./rkdeveloptool db rkbin/rk3399_loader_spinor_v1.25.114.bin
   > ./rkdeveloptool ef
   > ./rkdeveloptool wl 0 ../idbloader-spi.img
-  > ./rkdeveloptool wl 512 ../u-boot.itb
+  > ./rkdeveloptool wl 1024 ../u-boot.itb
diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index 8c153e66e0..50d7591d40 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -7,7 +7,6 @@ CONFIG_SPL_GPIO=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_ENV_OFFSET=0x3F8000
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-puma-haikou"
-CONFIG_SPL_TEXT_BASE=0xff8c2000
 CONFIG_ROCKCHIP_RK3399=y
 CONFIG_ROCKCHIP_BOOT_MODE_REG=0x0
 CONFIG_TARGET_PUMA_RK3399=y
@@ -31,11 +30,12 @@ CONFIG_SPL_BSS_MAX_SIZE=0x10000
 # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
 CONFIG_SPL_STACK=0xff8effff
 CONFIG_SPL_STACK_R=y
-CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x10000
 CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x200
 CONFIG_SPL_I2C=y
 CONFIG_SPL_POWER=y
 CONFIG_SPL_SPI_LOAD=y
+CONFIG_TPL=y
 CONFIG_CMD_BOOTZ=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
-- 
2.37.3

[PATCH v2 10/12] rockchip: puma-rk3399: migrate to u-boot-rockchip.bin

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

The offset of the SPL payload on Puma is different than for other
Rockchip devices in that it is stored at offset 256K instead of much
further away in the MMC.

Flashing one binary instead of two at different offsets is much more
user friendly so let's migrate to it by modifying the offset in the Puma
specific Device Tree.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
---
 arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi |  8 ++++++++
 board/theobroma-systems/puma_rk3399/README  | 11 +++--------
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
index 27a792fe6d..3c4487232a 100644
--- a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
@@ -44,6 +44,14 @@
 	};
 };
 
+&binman {
+	simple-bin {
+		blob {
+			offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512)>;
+		};
+	};
+};
+
 &gpio1 {
 	u-boot,dm-pre-reloc;
 };
diff --git a/board/theobroma-systems/puma_rk3399/README b/board/theobroma-systems/puma_rk3399/README
index 550bdfb1f4..2e3785c986 100644
--- a/board/theobroma-systems/puma_rk3399/README
+++ b/board/theobroma-systems/puma_rk3399/README
@@ -47,23 +47,19 @@ Compile the U-Boot
 Package the image
 =================
 
-The SPL image for SD-Card/eMMC is readily available in idbloader.img at the
-root of U-Boot after compilation.
-
 Creating an SPL image for SPI-NOR:
   > tools/mkimage -n rk3399 -T rkspi -d tpl/u-boot-tpl.bin:spl/u-boot-spl.bin idbloader-spi.img
 
 Flash the image
 ===============
 
-Copy the SPL to offset 32k and the FIT image to offset 256k for SD/eMMC.
+Copy u-boot-rockchip.bin to offset 32k for SD/eMMC.
 Copy the SPL to offset 0 and the FIT image to offset 512k for NOR-Flash.
 
 SD-Card
 -------
 
-  > dd if=idbloader.img of=/dev/sdb seek=64
-  > dd if=u-boot.itb of=/dev/sdb seek=512
+  > dd if=u-boot-rockchip.bin of=/dev/sdb seek=64
 
 eMMC
 ----
@@ -79,8 +75,7 @@ help of the Rockchip loader binary.
   > ./tools/boot_merger RKBOOT/RK3399MINIALL.ini
   > cd ..
   > ./rkdeveloptool db rkbin/rk3399_loader_v1.25.126.bin
-  > ./rkdeveloptool wl 64 ../idbloader.img
-  > ./rkdeveloptool wl 512 ../u-boot.itb
+  > ./rkdeveloptool wl 64 ../u-boot-rockchip.bin
 
 NOR-Flash
 ---------
-- 
2.37.3

[PATCH v2 11/12] rockchip: lion-rk3368: migrate to u-boot-rockchip.bin

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

The offset of the SPL payload on Lion is different than for other
Rockchip devices in that it is stored at offset 256K instead of much
further away in the MMC.

Flashing one binary instead of two at different offsets is much more
user friendly so let's migrate to it by modifying the offset in the Lion
specific Device Tree.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi | 8 ++++++++
 board/theobroma-systems/lion_rk3368/README  | 9 +++------
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi b/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi
index 7826d1e70b..02cb5ef9d9 100644
--- a/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi
+++ b/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi
@@ -38,6 +38,14 @@
 	};
 };
 
+&binman {
+	simple-bin {
+		blob {
+			offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512)>;
+		};
+	};
+};
+
 &gpio2 {
 	u-boot,dm-pre-reloc;
 };
diff --git a/board/theobroma-systems/lion_rk3368/README b/board/theobroma-systems/lion_rk3368/README
index 7488b18326..3c15a7bb36 100644
--- a/board/theobroma-systems/lion_rk3368/README
+++ b/board/theobroma-systems/lion_rk3368/README
@@ -27,14 +27,12 @@ Build the full U-Boot and a FIT image including the ATF
 Flash the image
 ===============
 
-Copy the SPL to offset 32k and the FIT image containing the payloads
-(U-Boot proper, ATF, devicetree) to offset 256k card.
+Copy u-boot-rockchip.bin at offset 32k on SD-Card/eMMC.
 
 SD-Card
 -------
 
-  > dd if=idbloader.img of=/dev/sdb seek=64
-  > dd if=u-boot.itb of=/dev/sdb seek=512
+  > dd if=u-boot-rockchip.bin of=/dev/sdb seekp=64
 
 eMMC
 ----
@@ -47,8 +45,7 @@ help of the Rockchip loader binary.
   > autoreconf -i && && ./configure && make
   > git clone https://github.com/rockchip-linux/rkbin.git
   > ./rkdeveloptool db rkbin/rk33/rk3368_loader_v2.00.256.bin
-  > ./rkdeveloptool wl 64 ../spl.img
-  > ./rkdeveloptool wl 512 ../u-boot.itb
+  > ./rkdeveloptool wl 64 ../u-boot-rockchip.bin
 
 
 If everything went according to plan, you should see the following
-- 
2.37.3

[PATCH v2 12/12] rockchip: puma-rk3399: migrate to u-boot-rockchip-spi.bin

[Quentin Schulz]

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

Now that a single binary containing TPL/SPL correctly formatted for SPI
flashes and U-Boot proper, can be generated by binman, let's do it.

Also update the documentation to tell the user to use this newly
generated file instead of manually generating and flashing the binaries.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
---
 arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi |  9 +++++++++
 board/theobroma-systems/puma_rk3399/README  | 11 ++---------
 configs/puma-rk3399_defconfig               |  1 +
 3 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
index 3c4487232a..f8335c74a7 100644
--- a/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi
@@ -50,6 +50,15 @@
 			offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512)>;
 		};
 	};
+
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+	simple-bin-spi {
+		blob {
+			/* same as u-boot,spl-payload-offset */
+			offset = <0x80000>;
+		};
+	};
+#endif
 };
 
 &gpio1 {
diff --git a/board/theobroma-systems/puma_rk3399/README b/board/theobroma-systems/puma_rk3399/README
index 2e3785c986..649aa3c543 100644
--- a/board/theobroma-systems/puma_rk3399/README
+++ b/board/theobroma-systems/puma_rk3399/README
@@ -44,17 +44,11 @@ Compile the U-Boot
   > cd ../u-boot
   > make CROSS_COMPILE=aarch64-linux-gnu- puma-rk3399_defconfig all
 
-Package the image
-=================
-
-Creating an SPL image for SPI-NOR:
-  > tools/mkimage -n rk3399 -T rkspi -d tpl/u-boot-tpl.bin:spl/u-boot-spl.bin idbloader-spi.img
-
 Flash the image
 ===============
 
 Copy u-boot-rockchip.bin to offset 32k for SD/eMMC.
-Copy the SPL to offset 0 and the FIT image to offset 512k for NOR-Flash.
+Copy u-boot-rockchip-spi.bin to offset 0 for NOR-flash.
 
 SD-Card
 -------
@@ -92,5 +86,4 @@ help of the Rockchip loader binary.
   > cd ..
   > ./rkdeveloptool db rkbin/rk3399_loader_spinor_v1.25.114.bin
   > ./rkdeveloptool ef
-  > ./rkdeveloptool wl 0 ../idbloader-spi.img
-  > ./rkdeveloptool wl 1024 ../u-boot.itb
+  > ./rkdeveloptool wl 0 ../u-boot-rockchip-spi.bin
diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
index 50d7591d40..34186d1caa 100644
--- a/configs/puma-rk3399_defconfig
+++ b/configs/puma-rk3399_defconfig
@@ -9,6 +9,7 @@ CONFIG_ENV_OFFSET=0x3F8000
 CONFIG_DEFAULT_DEVICE_TREE="rk3399-puma-haikou"
 CONFIG_ROCKCHIP_RK3399=y
 CONFIG_ROCKCHIP_BOOT_MODE_REG=0x0
+CONFIG_ROCKCHIP_SPI_IMAGE=y
 CONFIG_TARGET_PUMA_RK3399=y
 CONFIG_DEBUG_UART_BASE=0xFF180000
 CONFIG_DEBUG_UART_CLOCK=24000000
-- 
2.37.3

Re: [PATCH v2 11/12] rockchip: lion-rk3368: migrate to u-boot-rockchip.bin

[Kever Yang]

On 2022/9/15 17:14, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> The offset of the SPL payload on Lion is different than for other
> Rockchip devices in that it is stored at offset 256K instead of much
> further away in the MMC.
>
> Flashing one binary instead of two at different offsets is much more
> user friendly so let's migrate to it by modifying the offset in the Lion
> specific Device Tree.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever

> ---
>   arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi | 8 ++++++++
>   board/theobroma-systems/lion_rk3368/README  | 9 +++------
>   2 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi b/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi
> index 7826d1e70b..02cb5ef9d9 100644
> --- a/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi
> +++ b/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi
> @@ -38,6 +38,14 @@
>   	};
>   };
>   
> +&binman {
> +	simple-bin {
> +		blob {
> +			offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512)>;
> +		};
> +	};
> +};
> +
>   &gpio2 {
>   	u-boot,dm-pre-reloc;
>   };
> diff --git a/board/theobroma-systems/lion_rk3368/README b/board/theobroma-systems/lion_rk3368/README
> index 7488b18326..3c15a7bb36 100644
> --- a/board/theobroma-systems/lion_rk3368/README
> +++ b/board/theobroma-systems/lion_rk3368/README
> @@ -27,14 +27,12 @@ Build the full U-Boot and a FIT image including the ATF
>   Flash the image
>   ===============
>   
> -Copy the SPL to offset 32k and the FIT image containing the payloads
> -(U-Boot proper, ATF, devicetree) to offset 256k card.
> +Copy u-boot-rockchip.bin at offset 32k on SD-Card/eMMC.
>   
>   SD-Card
>   -------
>   
> -  > dd if=idbloader.img of=/dev/sdb seek=64
> -  > dd if=u-boot.itb of=/dev/sdb seek=512
> +  > dd if=u-boot-rockchip.bin of=/dev/sdb seekp=64
>   
>   eMMC
>   ----
> @@ -47,8 +45,7 @@ help of the Rockchip loader binary.
>     > autoreconf -i && && ./configure && make
>     > git clone https://github.com/rockchip-linux/rkbin.git
>     > ./rkdeveloptool db rkbin/rk33/rk3368_loader_v2.00.256.bin
> -  > ./rkdeveloptool wl 64 ../spl.img
> -  > ./rkdeveloptool wl 512 ../u-boot.itb
> +  > ./rkdeveloptool wl 64 ../u-boot-rockchip.bin
>   
>   
>   If everything went according to plan, you should see the following

Re: [PATCH v2 07/12] rockchip: puma-rk3399: load environment from same medium as one used to load U-Boot proper

[Kever Yang]

On 2022/9/15 17:14, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> Chances are when one boots U-Boot proper from a given storage medium,
> they want the same medium to be used to load and store the environment.
>
> This basically allows to have completely separate U-Boot (TPL/SPL/U-Boot
> proper/environment) per storage medium which is convenient when working
> with recovery from SD-Card as one would just need to insert a properly
> configured SD-Card into the device to have access to their whole debug
> setup.
>
> No fallback mechanism is provided as to not dirty other storage medium
> environment by mistake. However, since arch_env_get_location() is called
> by env_init() which is part of the pre-relocation process, a valid,
> non-ENVL_UNKNOWN, value shall be returned otherwise the relocation fails
> with the following message:
> initcall sequence 00000000002866c0 failed at call 0000000000256b34 (err=-19)
>
> This valid, non-ENVL_UNKNOWN, value is ENVL_NOWHERE which requires to
> always select CONFIG_ENV_IS_NOWHERE otherwise this work-around does not
> work.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Thanks,
- Kever
> ---
>   .../puma_rk3399/puma-rk3399.c                 | 37 +++++++++++++++++++
>   configs/puma-rk3399_defconfig                 |  1 +
>   2 files changed, 38 insertions(+)
>
> diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> index 5e5e58c88e..7ef4bac24b 100644
> --- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> +++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> @@ -6,6 +6,7 @@
>   #include <common.h>
>   #include <dm.h>
>   #include <env.h>
> +#include <env_internal.h>
>   #include <init.h>
>   #include <log.h>
>   #include <misc.h>
> @@ -135,6 +136,42 @@ int mmc_get_env_dev(void)
>   	return CONFIG_SYS_MMC_ENV_DEV;
>   }
>   
> +#if !IS_ENABLED(CONFIG_ENV_IS_NOWHERE)
> +#error Please enable CONFIG_ENV_IS_NOWHERE
> +#endif
> +
> +enum env_location arch_env_get_location(enum env_operation op, int prio)
> +{
> +	const char *boot_device =
> +		ofnode_read_chosen_string("u-boot,spl-boot-device");
> +
> +	if (prio > 0)
> +		return ENVL_UNKNOWN;
> +
> +	if (!boot_device) {
> +		debug("%s: /chosen/u-boot,spl-boot-device not set\n",
> +		      __func__);
> +		return ENVL_NOWHERE;
> +	}
> +
> +	debug("%s: booted from %s\n", __func__, boot_device);
> +
> +	if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH) &&
> +	    !strcmp(boot_device, "/spi@ff1d0000/flash@0"))
> +		return ENVL_SPI_FLASH;
> +
> +	if (IS_ENABLED(CONFIG_ENV_IS_IN_MMC) &&
> +	    (!strcmp(boot_device, "/mmc@fe320000") ||
> +	     !strcmp(boot_device, "/mmc@fe330000")))
> +		return ENVL_MMC;
> +
> +	printf("%s: No environment available: booted from %s but U-Boot "
> +	       "config does not allow loading environment from it.",
> +	       __func__, boot_device);
> +
> +	return ENVL_NOWHERE;
> +}
> +
>   int misc_init_r(void)
>   {
>   	const u32 cpuid_offset = 0x7;
> diff --git a/configs/puma-rk3399_defconfig b/configs/puma-rk3399_defconfig
> index f62cfc9aab..cfa743668b 100644
> --- a/configs/puma-rk3399_defconfig
> +++ b/configs/puma-rk3399_defconfig
> @@ -53,6 +53,7 @@ CONFIG_SPL_OF_CONTROL=y
>   CONFIG_OF_LIVE=y
>   CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
>   CONFIG_ENV_OVERWRITE=y
> +CONFIG_ENV_IS_NOWHERE=y
>   CONFIG_ENV_IS_IN_MMC=y
>   CONFIG_ENV_IS_IN_SPI_FLASH=y
>   CONFIG_ENV_SPI_MAX_HZ=50000000

Re: [PATCH v2 11/12] rockchip: lion-rk3368: migrate to u-boot-rockchip.bin

[Kever Yang]

Hi Quentin,

     I got below error when apply this patch, could you help to check

+Error: arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi:44.16-17 syntax error
+FATAL ERROR: Unable to parse input tree
+make[3]: *** [arch/arm/dts/rk3368-lion-haikou.dtb] Error 1
+make[2]: *** [arch-dtbs] Error 2

Thanks,

- Kever

On 2022/9/15 17:14, Quentin Schulz wrote:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> The offset of the SPL payload on Lion is different than for other
> Rockchip devices in that it is stored at offset 256K instead of much
> further away in the MMC.
>
> Flashing one binary instead of two at different offsets is much more
> user friendly so let's migrate to it by modifying the offset in the Lion
> specific Device Tree.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> ---
>   arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi | 8 ++++++++
>   board/theobroma-systems/lion_rk3368/README  | 9 +++------
>   2 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi b/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi
> index 7826d1e70b..02cb5ef9d9 100644
> --- a/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi
> +++ b/arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi
> @@ -38,6 +38,14 @@
>   	};
>   };
>   
> +&binman {
> +	simple-bin {
> +		blob {
> +			offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512)>;
> +		};
> +	};
> +};
> +
>   &gpio2 {
>   	u-boot,dm-pre-reloc;
>   };
> diff --git a/board/theobroma-systems/lion_rk3368/README b/board/theobroma-systems/lion_rk3368/README
> index 7488b18326..3c15a7bb36 100644
> --- a/board/theobroma-systems/lion_rk3368/README
> +++ b/board/theobroma-systems/lion_rk3368/README
> @@ -27,14 +27,12 @@ Build the full U-Boot and a FIT image including the ATF
>   Flash the image
>   ===============
>   
> -Copy the SPL to offset 32k and the FIT image containing the payloads
> -(U-Boot proper, ATF, devicetree) to offset 256k card.
> +Copy u-boot-rockchip.bin at offset 32k on SD-Card/eMMC.
>   
>   SD-Card
>   -------
>   
> -  > dd if=idbloader.img of=/dev/sdb seek=64
> -  > dd if=u-boot.itb of=/dev/sdb seek=512
> +  > dd if=u-boot-rockchip.bin of=/dev/sdb seekp=64
>   
>   eMMC
>   ----
> @@ -47,8 +45,7 @@ help of the Rockchip loader binary.
>     > autoreconf -i && && ./configure && make
>     > git clone https://github.com/rockchip-linux/rkbin.git
>     > ./rkdeveloptool db rkbin/rk33/rk3368_loader_v2.00.256.bin
> -  > ./rkdeveloptool wl 64 ../spl.img
> -  > ./rkdeveloptool wl 512 ../u-boot.itb
> +  > ./rkdeveloptool wl 64 ../u-boot-rockchip.bin
>   
>   
>   If everything went according to plan, you should see the following

Re: [PATCH v2 11/12] rockchip: lion-rk3368: migrate to u-boot-rockchip.bin

[Quentin Schulz]

Hi Kever,

On 10/19/22 13:28, Kever Yang wrote:
> Hi Quentin,
> 
>      I got below error when apply this patch, could you help to check
> 
> +Error: arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi:44.16-17 syntax error
> +FATAL ERROR: Unable to parse input tree
> +make[3]: *** [arch/arm/dts/rk3368-lion-haikou.dtb] Error 1
> +make[2]: *** [arch-dtbs] Error 2
> 

Did you run make lion-rk3368_defconfig before trying to compile the DTS?

I ran:
```
git checkout 3724ddf157
b4 shazam --add-link --add-my-sob 
https://lore.kernel.org/u-boot/20220915091432.789294-1-foss+uboot@0leil.net/
make CROSS_COMPILE="ccache aarch64-linux-gnu-" lion-rk3368_defconfig
make CROSS_COMPILE="ccache aarch64-linux-gnu-" j`nproc`
```
and it compiled without any problem.

Cheers,
Quentin

Re: [PATCH v2 11/12] rockchip: lion-rk3368: migrate to u-boot-rockchip.bin

[Kever Yang]

Hi Quentin,

     This is report by the  denx ci system:

https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/jobs/515913

     And I can reproduce it with buildman sheep-rk3568


Thanks,

- Kever

On 2022/10/19 20:11, Quentin Schulz wrote:
> Hi Kever,
>
> On 10/19/22 13:28, Kever Yang wrote:
>> Hi Quentin,
>>
>>      I got below error when apply this patch, could you help to check
>>
>> +Error: arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi:44.16-17 syntax 
>> error
>> +FATAL ERROR: Unable to parse input tree
>> +make[3]: *** [arch/arm/dts/rk3368-lion-haikou.dtb] Error 1
>> +make[2]: *** [arch-dtbs] Error 2
>>
>
> Did you run make lion-rk3368_defconfig before trying to compile the DTS?
>
> I ran:
> ```
> git checkout 3724ddf157
> b4 shazam --add-link --add-my-sob 
> https://lore.kernel.org/u-boot/20220915091432.789294-1-foss+uboot@0leil.net/
> make CROSS_COMPILE="ccache aarch64-linux-gnu-" lion-rk3368_defconfig
> make CROSS_COMPILE="ccache aarch64-linux-gnu-" j`nproc`
> ```
> and it compiled without any problem.
>
> Cheers,
> Quentin

Re: [PATCH v2 11/12] rockchip: lion-rk3368: migrate to u-boot-rockchip.bin

[quentin.schulz]

Hi Kever,

On 10/19/22 2:47 PM, Kever Yang <kever.yang@rock-chips.com> wrote:
> Hi Quentin,
> 
>      This is report by the  denx ci system:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__source.denx.de_u-2Dboot_custodians_u-2Dboot-2Drockchip_-2D_jobs_515913&d=DwIDaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=jlsoDVbl-1nmumJr2buEbP1CHgfZWWOLR9Xh-ycxj-II1AQbLWozSLgCKBSYz-3o&s=dMfyQSyv3NY0elXedC3GxMELp8oSMp8hCy5WZniPV2U&e=

I cannot see this page, probably a custodian account on that gitlab instance is required?

>      And I can reproduce it with buildman sheep-rk3568
> 

I can reproduce by building for sheep-3368_defconfig indeed.

CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR is not defined for this board and it is used in the lion dts.

Since the Lion dts is built for any RK3368-based board, it needs to be defined for all boards based on RK3368 which is not the case for the Sheep board.

Was it a deliberate choice to build all DTS from a specific SoC, whatever the board you're building for?

I would have imagined that using CONFIG_TARGET_LION_RK3368 instead of CONFIG_ROCKCHIP_RK3368 in arch/arm/dts/Makefile for deciding whether to build a device tree would make more sense?

For the time being, please just drop this patch, we don't really need it at the moment so I'll have a look on how to do this properly when I have time.

Thanks!
Quentin

> 
> Thanks,
> 
> - Kever
> 
> On 2022/10/19 20:11, Quentin Schulz wrote:
> > Hi Kever,
> >
> > On 10/19/22 13:28, Kever Yang wrote:
> >> Hi Quentin,
> >>
> >>      I got below error when apply this patch, could you help to check
> >>
> >> +Error: arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi:44.16-17 syntax 
> >> error
> >> +FATAL ERROR: Unable to parse input tree
> >> +make[3]: *** [arch/arm/dts/rk3368-lion-haikou.dtb] Error 1
> >> +make[2]: *** [arch-dtbs] Error 2
> >>
> >
> > Did you run make lion-rk3368_defconfig before trying to compile the DTS?
> >
> > I ran:
> > ```
> > git checkout 3724ddf157
> > b4 shazam --add-link --add-my-sob 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_u-2Dboot_20220915091432.789294-2D1-2Dfoss-2Buboot-400leil.net_&d=DwIDaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=jlsoDVbl-1nmumJr2buEbP1CHgfZWWOLR9Xh-ycxj-II1AQbLWozSLgCKBSYz-3o&s=lpPi8rny7_X2xST4eJ40go_Uv41ZYqpuCeU46CpJCz4&e= make CROSS_COMPILE="ccache aarch64-linux-gnu-" lion-rk3368_defconfig
> > make CROSS_COMPILE="ccache aarch64-linux-gnu-" j`nproc`
> > ```
> > and it compiled without any problem.
> >
> > Cheers,
> > Quentin
> 

Re: [PATCH v2 11/12] rockchip: lion-rk3368: migrate to u-boot-rockchip.bin

[Kever Yang]

On 2022/10/19 22:10, quentin.schulz@theobroma-systems.com wrote:
> Hi Kever,
>
> On 10/19/22 2:47 PM, Kever Yang <kever.yang@rock-chips.com> wrote:
>> Hi Quentin,
>>
>>      This is report by the  denx ci system:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__source.denx.de_u-2Dboot_custodians_u-2Dboot-2Drockchip_-2D_jobs_515913&d=DwIDaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=jlsoDVbl-1nmumJr2buEbP1CHgfZWWOLR9Xh-ycxj-II1AQbLWozSLgCKBSYz-3o&s=dMfyQSyv3NY0elXedC3GxMELp8oSMp8hCy5WZniPV2U&e= 
>>
>
> I cannot see this page, probably a custodian account on that gitlab 
> instance is required?
>
>>      And I can reproduce it with buildman sheep-rk3568
>>
>
> I can reproduce by building for sheep-3368_defconfig indeed.
>
> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR is not defined for this board 
> and it is used in the lion dts.
>
> Since the Lion dts is built for any RK3368-based board, it needs to be 
> defined for all boards based on RK3368 which is not the case for the 
> Sheep board.

The lion dts is only used for this board, the sheep board have its own 
dts, I didn't see any sheep dts include lion dts, but it's strange why 
the sheep-rk3368 fail with lion change.


>
> Was it a deliberate choice to build all DTS from a specific SoC, 
> whatever the board you're building for?
>
> I would have imagined that using CONFIG_TARGET_LION_RK3368 instead of 
> CONFIG_ROCKCHIP_RK3368 in arch/arm/dts/Makefile for deciding whether 
> to build a device tree would make more sense?
>
> For the time being, please just drop this patch, we don't really need 
> it at the moment so I'll have a look on how to do this properly when I 
> have time.

OK, you  can send the follow up patch if we figure out the reason.


Thanks,

- Kever

>
> Thanks!
> Quentin
>
>>
>> Thanks,
>>
>> - Kever
>>
>> On 2022/10/19 20:11, Quentin Schulz wrote:
>> > Hi Kever,
>> >
>> > On 10/19/22 13:28, Kever Yang wrote:
>> >> Hi Quentin,
>> >>
>> >>      I got below error when apply this patch, could you help to check
>> >>
>> >> +Error: arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi:44.16-17 
>> syntax >> error
>> >> +FATAL ERROR: Unable to parse input tree
>> >> +make[3]: *** [arch/arm/dts/rk3368-lion-haikou.dtb] Error 1
>> >> +make[2]: *** [arch-dtbs] Error 2
>> >>
>> >
>> > Did you run make lion-rk3368_defconfig before trying to compile the 
>> DTS?
>> >
>> > I ran:
>> > ```
>> > git checkout 3724ddf157
>> > b4 shazam --add-link --add-my-sob > 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_u-2Dboot_20220915091432.789294-2D1-2Dfoss-2Buboot-400leil.net_&d=DwIDaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=jlsoDVbl-1nmumJr2buEbP1CHgfZWWOLR9Xh-ycxj-II1AQbLWozSLgCKBSYz-3o&s=lpPi8rny7_X2xST4eJ40go_Uv41ZYqpuCeU46CpJCz4&e= 
>> make CROSS_COMPILE="ccache aarch64-linux-gnu-" lion-rk3368_defconfig
>> > make CROSS_COMPILE="ccache aarch64-linux-gnu-" j`nproc`
>> > ```
>> > and it compiled without any problem.
>> >
>> > Cheers,
>> > Quentin
>>

Re: [PATCH v2 11/12] rockchip: lion-rk3368: migrate to u-boot-rockchip.bin

[Quentin Schulz]

Hi Kever,

On 10/21/22 03:14, Kever Yang wrote:
> 
> On 2022/10/19 22:10, quentin.schulz@theobroma-systems.com wrote:
>> Hi Kever,
>>
>> On 10/19/22 2:47 PM, Kever Yang <kever.yang@rock-chips.com> wrote:
>>> Hi Quentin,
>>>
>>>      This is report by the  denx ci system:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__source.denx.de_u-2Dboot_custodians_u-2Dboot-2Drockchip_-2D_jobs_515913&d=DwIDaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=jlsoDVbl-1nmumJr2buEbP1CHgfZWWOLR9Xh-ycxj-II1AQbLWozSLgCKBSYz-3o&s=dMfyQSyv3NY0elXedC3GxMELp8oSMp8hCy5WZniPV2U&e=
>>
>> I cannot see this page, probably a custodian account on that gitlab 
>> instance is required?
>>
>>>      And I can reproduce it with buildman sheep-rk3568
>>>
>>
>> I can reproduce by building for sheep-3368_defconfig indeed.
>>
>> CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR is not defined for this board 
>> and it is used in the lion dts.
>>
>> Since the Lion dts is built for any RK3368-based board, it needs to be 
>> defined for all boards based on RK3368 which is not the case for the 
>> Sheep board.
> 
> The lion dts is only used for this board, the sheep board have its own 
> dts, I didn't see any sheep dts include lion dts, but it's strange why 
> the sheep-rk3368 fail with lion change.
> 

It is not included, but all RK3368-based boards are compiled when 
CONFIG_ROCKCHIP_RK3368 is enabled, which is the case for all 
RK3368-based boards. SO if you compile U-Boot with sheep defconfig, you 
compile the device trees for other RK3368-based machines.

c.f.:
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/Makefile#L131-L135

> 
>>
>> Was it a deliberate choice to build all DTS from a specific SoC, 
>> whatever the board you're building for?
>>
>> I would have imagined that using CONFIG_TARGET_LION_RK3368 instead of 
>> CONFIG_ROCKCHIP_RK3368 in arch/arm/dts/Makefile for deciding whether 
>> to build a device tree would make more sense?
>>
>> For the time being, please just drop this patch, we don't really need 
>> it at the moment so I'll have a look on how to do this properly when I 
>> have time.
> 
> OK, you  can send the follow up patch if we figure out the reason.
> 

My idea was to build those DTS based not on SoC-specific Kconfig but 
target-specific Kconfig, e.g. 
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/Makefile#L3

I'll try to carve some time in the next few days/next week to do that.

Cheers,
Quentin