[PATCH v2 00/12] Puma RK3399 migration to TPL and numerous fixes
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(-)
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);
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
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
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
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;
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
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
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
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
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
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 ---------
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
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=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 ../u-boot-rockchip.bin
If everything went according to plan, you should see the following
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=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 ../u-boot-rockchip.bin
If everything went according to plan, you should see the following
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
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
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...
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
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...
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-2Dboo... 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
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...
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#L13...
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
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
participants (4)
-
Kever Yang -
Quentin Schulz -
Quentin Schulz -
quentin.schulz＠theobroma-systems.com