[RFC PATCH 0/8] migrate u-boot-rockchip.bin to binman and generate an image for SPI

[RFC PATCH 0/8] migrate u-boot-rockchip.bin to binman and generate an image for SPI

[Quentin Schulz]

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

This migrates the generation of u-boot-rockchip.bin from Makefile to binman
completely. There is therefore no idbloader.img anymore as it is created on
the fly by binman.

This also adds support for generating the same kind of image than
u-boot-rockchip.bin but for SPI flashes (specifically, a different image
type generated by mkimage is necessary, in addition to a different
offset in the storage medium).

This has been tested on Puma RK3399 with patches soon to be sent to the
ML.

This is a pretty big change and would like people having access to
Rockchip devices to extensively test those (especially those Aarch32
devices I don't have access to) whenever possible. Please also provide
feedback/patches on missing docs updates.

This also helped removing the hardcoded value for the u-boot.itb offset
in u-boot-rockchip.bin which prevented Puma SoM to be migrated to it.

Cheers,
Quentin

Quentin Schulz (8):
  rockchip: generate idbloader.img content for u-boot-rockchip.bin with
    binman for ARM
  rockchip: generate u-boot-rockchip.bin with binman for ARM64 boards
  rockchip: remove unneeded CONFIG_SPL_PAD_TO
  rockchip: pad u-boot-rockchip.bin correctly
  rockchip: simplify binman image dependencies addition to INPUTS
  rockchip: allow to build SPI images even without HAS_ROM option
  binman: add support for skipping file concatenation for mkimage
  rockchip: add u-boot-rockchip-spi.bin image for booting from SPI-NOR
    flash

 Makefile                          | 39 ++++--------------------
 arch/arm/Kconfig                  |  2 +-
 arch/arm/dts/rk3288-u-boot.dtsi   |  2 +-
 arch/arm/dts/rk3399-u-boot.dtsi   |  2 +-
 arch/arm/dts/rockchip-u-boot.dtsi | 50 +++++++++++++++++++++++++++++--
 arch/arm/mach-rockchip/Kconfig    |  6 ++--
 doc/board/rockchip/rockchip.rst   |  2 +-
 include/configs/rockchip-common.h |  2 --
 tools/binman/entries.rst          | 22 ++++++++++++++
 tools/binman/etype/mkimage.py     | 41 ++++++++++++++++++++++---
 10 files changed, 118 insertions(+), 50 deletions(-)

-- 
2.36.1

[RFC PATCH 1/8] rockchip: generate idbloader.img content for u-boot-rockchip.bin with binman for ARM

[Quentin Schulz]

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

idbloader.img content - currently created by way of Makefile - can be
created by binman directly.

So let's do that for Rockchip ARM platforms.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 Makefile                          |  2 +-
 arch/arm/dts/rockchip-u-boot.dtsi | 15 +++++++++++++--
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index 98867fbe06..ec6a13fd05 100644
--- a/Makefile
+++ b/Makefile
@@ -1000,7 +1000,7 @@ endif
 else
 ifeq ($(CONFIG_SPL),y)
 # Generate these inputs for binman which will create the output files
-INPUTS-y += idbloader.img u-boot.img
+INPUTS-y += u-boot.img
 endif
 endif
 endif
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi b/arch/arm/dts/rockchip-u-boot.dtsi
index eae3ee715d..0362c97e0b 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -17,9 +17,20 @@
 		filename = "u-boot-rockchip.bin";
 		pad-byte = <0xff>;
 
-		blob {
-			filename = "idbloader.img";
+		mkimage {
+			args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
+#ifndef CONFIG_TPL
+			u-boot-spl {
+			};
 		};
+#else
+			u-boot-tpl {
+			};
+		};
+
+		u-boot-spl {
+		};
+#endif
 
 		u-boot-img {
 			offset = <CONFIG_SPL_PAD_TO>;
-- 
2.36.1

[RFC PATCH 2/8] rockchip: generate u-boot-rockchip.bin with binman for ARM64 boards

[Quentin Schulz]

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

This allows to build u-boot-rockchip.bin binary with binman for Rockchip
ARM64 boards instead of the legacy Makefile way.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 Makefile                          | 28 ++--------------------------
 arch/arm/Kconfig                  |  2 +-
 arch/arm/dts/rockchip-u-boot.dtsi |  5 +++++
 3 files changed, 8 insertions(+), 27 deletions(-)

diff --git a/Makefile b/Makefile
index ec6a13fd05..d4f53afc66 100644
--- a/Makefile
+++ b/Makefile
@@ -994,8 +994,7 @@ ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
 # On ARM64 this target is produced by binman so we don't need this dep
 ifeq ($(CONFIG_ARM64),y)
 ifeq ($(CONFIG_SPL),y)
-# TODO: Get binman to generate this too
-INPUTS-y += u-boot-rockchip.bin
+INPUTS-y += u-boot.itb
 endif
 else
 ifeq ($(CONFIG_SPL),y)
@@ -1488,29 +1487,6 @@ OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \
 u-boot-with-spl.bin: $(SPL_IMAGE) $(SPL_PAYLOAD) FORCE
 	$(call if_changed,pad_cat)
 
-ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
-
-# TPL + SPL
-ifeq ($(CONFIG_SPL)$(CONFIG_TPL),yy)
-MKIMAGEFLAGS_u-boot-tpl-rockchip.bin = -n $(CONFIG_SYS_SOC) -T rksd
-tpl/u-boot-tpl-rockchip.bin: tpl/u-boot-tpl.bin FORCE
-	$(call if_changed,mkimage)
-idbloader.img: tpl/u-boot-tpl-rockchip.bin spl/u-boot-spl.bin FORCE
-	$(call if_changed,cat)
-else
-MKIMAGEFLAGS_idbloader.img = -n $(CONFIG_SYS_SOC) -T rksd
-idbloader.img: spl/u-boot-spl.bin FORCE
-	$(call if_changed,mkimage)
-endif
-
-ifeq ($(CONFIG_ARM64),y)
-OBJCOPYFLAGS_u-boot-rockchip.bin = -I binary -O binary \
-	--pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0xff
-u-boot-rockchip.bin: idbloader.img u-boot.itb FORCE
-	$(call if_changed,pad_cat)
-endif # CONFIG_ARM64
-
-endif # CONFIG_ARCH_ROCKCHIP
 
 ifeq ($(CONFIG_ARCH_LPC32XX)$(CONFIG_SPL),yy)
 MKIMAGEFLAGS_lpc32xx-spl.img = -T lpc32xximage -a $(CONFIG_SPL_TEXT_BASE)
@@ -2213,7 +2189,7 @@ CLEAN_FILES += include/bmp_logo.h include/bmp_logo_data.h \
 	       tools/version.h u-boot* MLO* SPL System.map fit-dtb.blob* \
 	       u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-boot.imx.log \
 	       lpc32xx-* bl31.c bl31.elf bl31_*.bin image.map tispl.bin* \
-	       idbloader.img flash.bin flash.log defconfig keep-syms-lto.c \
+	       flash.bin flash.log defconfig keep-syms-lto.c \
 	       mkimage-out.spl.mkimage mkimage.spl.mkimage imx-boot.map \
 	       itb.fit.fit itb.fit.itb itb.map spl.map
 
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9898c7d68e..4b2464c197 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1973,7 +1973,7 @@ config ARCH_STM32MP
 config ARCH_ROCKCHIP
 	bool "Support Rockchip SoCs"
 	select BLK
-	select BINMAN if SPL_OPTEE || (SPL && !ARM64)
+	select BINMAN if SPL_OPTEE || SPL
 	select DM
 	select DM_GPIO
 	select DM_I2C
diff --git a/arch/arm/dts/rockchip-u-boot.dtsi b/arch/arm/dts/rockchip-u-boot.dtsi
index 0362c97e0b..aef6c379e2 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -32,7 +32,12 @@
 		};
 #endif
 
+#ifdef CONFIG_ARM64
+		blob {
+			filename = "u-boot.itb";
+#else
 		u-boot-img {
+#endif
 			offset = <CONFIG_SPL_PAD_TO>;
 		};
 	};
-- 
2.36.1

[RFC PATCH 3/8] rockchip: remove unneeded CONFIG_SPL_PAD_TO

[Quentin Schulz]

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

Since binman takes care of setting the appropriate offset for the SPL
payload, there's no need to define this variable anymore.

Moreover, it is technically incorrect since the padding is different
depending on whether the first stage bootloader is for a SPI flash or
MMC storage medium.

Finally, this allows to use the CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
config option without redefining CONFIG_SPL_PAD_TO in other board header
files.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/dts/rockchip-u-boot.dtsi | 2 +-
 include/configs/rockchip-common.h | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arm/dts/rockchip-u-boot.dtsi b/arch/arm/dts/rockchip-u-boot.dtsi
index aef6c379e2..fc28ce5187 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -38,7 +38,7 @@
 #else
 		u-boot-img {
 #endif
-			offset = <CONFIG_SPL_PAD_TO>;
+			offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512)>;
 		};
 	};
 };
diff --git a/include/configs/rockchip-common.h b/include/configs/rockchip-common.h
index 0c08776ae2..40d5a02fc8 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -9,8 +9,6 @@
 
 #define CONFIG_SYS_NS16550_MEM32
 
-/* ((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512) */
-#define CONFIG_SPL_PAD_TO		8355840
 
 #ifndef CONFIG_SPL_BUILD
 
-- 
2.36.1

[RFC PATCH 4/8] rockchip: pad u-boot-rockchip.bin correctly

[Quentin Schulz]

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

On MMC storage media, the TPL/SPL needs to be flashed at offset 32KB.
Instead of requesting the user to put the input the appropriate offsets,
let's create u-boot-rockchip.bin with the padding already added.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/dts/rockchip-u-boot.dtsi | 3 ++-
 doc/board/rockchip/rockchip.rst   | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/rockchip-u-boot.dtsi b/arch/arm/dts/rockchip-u-boot.dtsi
index fc28ce5187..4cd243514e 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -18,6 +18,7 @@
 		pad-byte = <0xff>;
 
 		mkimage {
+			offset = <(32 * 1024)>; /* 32KB */
 			args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
 #ifndef CONFIG_TPL
 			u-boot-spl {
@@ -38,7 +39,7 @@
 #else
 		u-boot-img {
 #endif
-			offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512)>;
+			offset = <(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512)>;
 		};
 	};
 };
diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
index 4ca7b00b1f..1995882244 100644
--- a/doc/board/rockchip/rockchip.rst
+++ b/doc/board/rockchip/rockchip.rst
@@ -179,7 +179,7 @@ To write an image that boots from a SD card (assumed to be /dev/sda):
 
 .. code-block:: bash
 
-        sudo dd if=u-boot-rockchip.bin of=/dev/sda seek=64
+        sudo dd if=u-boot-rockchip.bin of=/dev/sda
         sync
 
 eMMC
-- 
2.36.1

[RFC PATCH 5/8] rockchip: simplify binman image dependencies addition to INPUTS

[Quentin Schulz]

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

By factoring SPL check in the first condition, this makes the checks a
bit less convoluted and more readable.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 Makefile | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index d4f53afc66..ad95cd0c96 100644
--- a/Makefile
+++ b/Makefile
@@ -990,19 +990,14 @@ ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
 INPUTS-y += u-boot-with-dtb.bin
 endif
 
-ifeq ($(CONFIG_ARCH_ROCKCHIP),y)
-# On ARM64 this target is produced by binman so we don't need this dep
+ifeq ($(CONFIG_ARCH_ROCKCHIP)$(CONFIG_SPL),yy)
+# Binman image dependencies
 ifeq ($(CONFIG_ARM64),y)
-ifeq ($(CONFIG_SPL),y)
 INPUTS-y += u-boot.itb
 endif
 else
-ifeq ($(CONFIG_SPL),y)
-# Generate these inputs for binman which will create the output files
 INPUTS-y += u-boot.img
 endif
-endif
-endif
 
 INPUTS-$(CONFIG_X86) += u-boot-x86-start16.bin u-boot-x86-reset16.bin \
 	$(if $(CONFIG_SPL_X86_16BIT_INIT),spl/u-boot-spl.bin) \
-- 
2.36.1

[RFC PATCH 6/8] rockchip: allow to build SPI images even without HAS_ROM option

[Quentin Schulz]

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

This prepares for the creation of a u-boot-rockchip-spi.bin image
similar to u-boot-rockchip.bin to the exception it's destined for
SPI-NOR flashes instead of MMC storage medium.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/dts/rk3288-u-boot.dtsi | 2 +-
 arch/arm/dts/rk3399-u-boot.dtsi | 2 +-
 arch/arm/mach-rockchip/Kconfig  | 6 ++----
 3 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index 9eb696b141..e411445ed6 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -56,7 +56,7 @@
 	};
 };
 
-#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+#if defined(CONFIG_ROCKCHIP_SPI_IMAGE) && defined(CONFIG_HAS_ROM)
 &binman {
 	rom {
 		filename = "u-boot.rom";
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index 716b9a433a..3c1a15fe51 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -60,7 +60,7 @@
 
 };
 
-#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+#if defined(CONFIG_ROCKCHIP_SPI_IMAGE) && defined(CONFIG_HAS_ROM)
 &binman {
 	rom {
 		filename = "u-boot.rom";
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index c561a77e6a..b46cea2f91 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -425,12 +425,10 @@ config SPL_MMC
 
 config ROCKCHIP_SPI_IMAGE
 	bool "Build a SPI image for rockchip"
-	depends on HAS_ROM
 	help
 	  Some Rockchip SoCs support booting from SPI flash. Enable this
-	  option to produce a 4MB SPI-flash image (called u-boot.rom)
-	  containing U-Boot. The image is built by binman. U-Boot sits near
-	  the start of the image.
+	  option to produce a SPI-flash image containing U-Boot. The image
+	  is built by binman. U-Boot sits near the start of the image.
 
 config LNX_KRNL_IMG_TEXT_OFFSET_BASE
 	default SYS_TEXT_BASE
-- 
2.36.1

[RFC PATCH 7/8] binman: add support for skipping file concatenation for mkimage

[Quentin Schulz]

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

Some image types handled by mkimage require the datafiles to be passed
independently (-d data1:data2) for specific handling of each. A
concatenation of datafiles prior to passing them to mkimage wouldn't
work.

That is the case for rksd and rkspi for example, which require page
alignment (plus some weird hack for rkspi) plus size data of each stage
to be embedded in the mkimage header.

This adds the ability to tell binman to pass the datafiles without
prior concatenation to mkimage, by adding the multiple-data-files
boolean property to the mkimage node.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 tools/binman/entries.rst      | 22 +++++++++++++++++++
 tools/binman/etype/mkimage.py | 41 +++++++++++++++++++++++++++++++----
 2 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index ae4305c99e..60c89aec59 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1101,6 +1101,9 @@ Entry: mkimage: Binary produced by mkimage
 
 Properties / Entry arguments:
     - datafile: Filename for -d argument
+    - multiple-data-files: boolean to tell binman to pass all files as
+      datafiles to mkimage instead of creating a temporary file the result
+      of datafiles concatenation
     - args: Other arguments to pass
 
 The data passed to mkimage is collected from subnodes of the mkimage node,
@@ -1117,6 +1120,25 @@ This calls mkimage to create an imximage with u-boot-spl.bin as the input
 file. The output from mkimage then becomes part of the image produced by
 binman.
 
+To pass all datafiles untouched to mkimage::
+
+    mkimage {
+        args = "-n rk3399 -T rkspi";
+        multiple-data-files;
+
+        u-boot-tpl {
+        };
+
+        u-boot-spl {
+        };
+    };
+
+This calls mkimage to create a Rockchip RK3399-specific first stage
+bootloader, made of TPL+SPL. Since this first stage bootloader requires to
+align the TPL and SPL but also some weird hacks that is handled by mkimage
+directly, binman is told to not perform the concatenation of datafiles prior
+to passing the data to mkimage.
+
 To use CONFIG options in the arguments, use a string list instead, as in
 this example which also produces four arguments::
 
diff --git a/tools/binman/etype/mkimage.py b/tools/binman/etype/mkimage.py
index 5f6def2287..52297c23ea 100644
--- a/tools/binman/etype/mkimage.py
+++ b/tools/binman/etype/mkimage.py
@@ -16,6 +16,9 @@ class Entry_mkimage(Entry):
 
     Properties / Entry arguments:
         - datafile: Filename for -d argument
+        - multiple-data-files: boolean to tell binman to pass all files as
+          datafiles to mkimage instead of creating a temporary file the result
+          of datafiles concatenation
         - args: Other arguments to pass
 
     The data passed to mkimage is collected from subnodes of the mkimage node,
@@ -32,6 +35,25 @@ class Entry_mkimage(Entry):
     file. The output from mkimage then becomes part of the image produced by
     binman.
 
+	To pass all datafiles untouched to mkimage::
+
+		mkimage {
+			args = "-n rk3399 -T rkspi";
+			multiple-data-files;
+
+			u-boot-tpl {
+			};
+
+			u-boot-spl {
+			};
+		};
+
+	This calls mkimage to create a Rockchip RK3399-specific first stage
+	bootloader, made of TPL+SPL. Since this first stage bootloader requires to
+	align the TPL and SPL but also some weird hacks that is handled by mkimage
+	directly, binman is told to not perform the concatenation of datafiles prior
+	to passing the data to mkimage.
+
     To use CONFIG options in the arguments, use a string list instead, as in
     this example which also produces four arguments::
 
@@ -46,16 +68,27 @@ class Entry_mkimage(Entry):
     def __init__(self, section, etype, node):
         super().__init__(section, etype, node)
         self._args = fdt_util.GetArgs(self._node, 'args')
+        self._multiple_data_files = fdt_util.GetBool(self._node, 'multiple-data-files')
         self._mkimage_entries = OrderedDict()
         self.align_default = None
         self.ReadEntries()
 
     def ObtainContents(self):
         # Use a non-zero size for any fake files to keep mkimage happy
-        data, input_fname, uniq = self.collect_contents_to_file(
-            self._mkimage_entries.values(), 'mkimage', 1024)
-        if data is None:
-            return False
+        fake_size = 1024
+        if self._multiple_data_files:
+            fnames = []
+            uniq = self.GetUniqueName()
+            for entry in self._mkimage_entries.values():
+                if not entry.ObtainContents(fake_size=fake_size):
+                    return False
+                fnames.append(entry.GetDefaultFilename())
+            input_fname = ":".join(fnames)
+        else:
+            data, input_fname, uniq = self.collect_contents_to_file(
+                self._mkimage_entries.values(), 'mkimage', fake_size)
+            if data is None:
+                return False
         output_fname = tools.get_output_filename('mkimage-out.%s' % uniq)
         if self.mkimage.run_cmd('-d', input_fname, *self._args,
                                 output_fname) is not None:
-- 
2.36.1

[RFC PATCH 8/8] rockchip: add u-boot-rockchip-spi.bin image for booting from SPI-NOR flash

[Quentin Schulz]

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

This new image is similar to u-boot-rockchip.bin except that it's
destined to be flashed on SPI-NOR flashes.

Cc: Quentin Schulz <foss+uboot@0leil.net>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
---
 arch/arm/dts/rockchip-u-boot.dtsi | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/dts/rockchip-u-boot.dtsi b/arch/arm/dts/rockchip-u-boot.dtsi
index 4cd243514e..d378d9d57b 100644
--- a/arch/arm/dts/rockchip-u-boot.dtsi
+++ b/arch/arm/dts/rockchip-u-boot.dtsi
@@ -42,5 +42,34 @@
 			offset = <(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512)>;
 		};
 	};
+
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+	simple-bin-spi {
+		filename = "u-boot-rockchip-spi.bin";
+		pad-byte = <0xff>;
+
+		mkimage {
+			args = "-n", CONFIG_SYS_SOC, "-T", "rkspi";
+#ifdef CONFIG_TPL
+			multiple-data-files;
+
+			u-boot-tpl {
+			};
+#endif
+			u-boot-spl {
+			};
+		};
+
+#ifdef CONFIG_ARM64
+		blob {
+			filename = "u-boot.itb";
+#else
+		u-boot-img {
+#endif
+			/* Sync with u-boot,spl-payload-offset if present */
+			offset = <CONFIG_SYS_SPI_U_BOOT_OFFS>;
+		};
+	};
+#endif
 };
 #endif
-- 
2.36.1

Re: [RFC PATCH 4/8] rockchip: pad u-boot-rockchip.bin correctly

[Philipp Tomsich]

On Fri, 15 Jul 2022 at 17:37, Quentin Schulz <foss+uboot@0leil.net> wrote:
>
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> On MMC storage media, the TPL/SPL needs to be flashed at offset 32KB.
> Instead of requesting the user to put the input the appropriate offsets,
> let's create u-boot-rockchip.bin with the padding already added.

NAK.

The storage layout provided by Rockchip leaves space for a
(protective) MBR and a primary GPT.
A bootloader update will overwrite the partition table if you create
the image as you suggest.

> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> ---
>  arch/arm/dts/rockchip-u-boot.dtsi | 3 ++-
>  doc/board/rockchip/rockchip.rst   | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/rockchip-u-boot.dtsi b/arch/arm/dts/rockchip-u-boot.dtsi
> index fc28ce5187..4cd243514e 100644
> --- a/arch/arm/dts/rockchip-u-boot.dtsi
> +++ b/arch/arm/dts/rockchip-u-boot.dtsi
> @@ -18,6 +18,7 @@
>                 pad-byte = <0xff>;
>
>                 mkimage {
> +                       offset = <(32 * 1024)>; /* 32KB */
>                         args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
>  #ifndef CONFIG_TPL
>                         u-boot-spl {
> @@ -38,7 +39,7 @@
>  #else
>                 u-boot-img {
>  #endif
> -                       offset = <((CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR - 64) * 512)>;
> +                       offset = <(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR * 512)>;
>                 };
>         };
>  };
> diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst
> index 4ca7b00b1f..1995882244 100644
> --- a/doc/board/rockchip/rockchip.rst
> +++ b/doc/board/rockchip/rockchip.rst
> @@ -179,7 +179,7 @@ To write an image that boots from a SD card (assumed to be /dev/sda):
>
>  .. code-block:: bash
>
> -        sudo dd if=u-boot-rockchip.bin of=/dev/sda seek=64
> +        sudo dd if=u-boot-rockchip.bin of=/dev/sda
>          sync
>
>  eMMC
> --
> 2.36.1
>

Re: [RFC PATCH 7/8] binman: add support for skipping file concatenation for mkimage

[Simon Glass]

On Fri, 15 Jul 2022 at 09:37, Quentin Schulz <foss+uboot@0leil.net> wrote:
>
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>
> Some image types handled by mkimage require the datafiles to be passed
> independently (-d data1:data2) for specific handling of each. A
> concatenation of datafiles prior to passing them to mkimage wouldn't
> work.
>
> That is the case for rksd and rkspi for example, which require page
> alignment (plus some weird hack for rkspi) plus size data of each stage
> to be embedded in the mkimage header.
>
> This adds the ability to tell binman to pass the datafiles without
> prior concatenation to mkimage, by adding the multiple-data-files
> boolean property to the mkimage node.
>
> Cc: Quentin Schulz <foss+uboot@0leil.net>
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> ---
>  tools/binman/entries.rst      | 22 +++++++++++++++++++
>  tools/binman/etype/mkimage.py | 41 +++++++++++++++++++++++++++++++----
>  2 files changed, 59 insertions(+), 4 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

I wonder if we should move this logic to binman (from mkimage) when
all the boards are converted to binman?

Re: [RFC PATCH 7/8] binman: add support for skipping file concatenation for mkimage

[Quentin Schulz]

Hi Simon,

On 7/16/22 13:58, Simon Glass wrote:
> On Fri, 15 Jul 2022 at 09:37, Quentin Schulz <foss+uboot@0leil.net> wrote:
>>
>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>
>> Some image types handled by mkimage require the datafiles to be passed
>> independently (-d data1:data2) for specific handling of each. A
>> concatenation of datafiles prior to passing them to mkimage wouldn't
>> work.
>>
>> That is the case for rksd and rkspi for example, which require page
>> alignment (plus some weird hack for rkspi) plus size data of each stage
>> to be embedded in the mkimage header.
>>

I forgot to rephrase the commit log. As seen in patch 1/8, there 
actually doesn't seem to be a need for rksd for passing multiple data 
files to mkimage, only the TPL could be passed to mkimage and SPL 
appended right after that blob generated by mkimage. Maybe it's luck but 
it seems to work for me the few tries I did on SD card and eMMC.

>> This adds the ability to tell binman to pass the datafiles without
>> prior concatenation to mkimage, by adding the multiple-data-files
>> boolean property to the mkimage node.
>>
>> Cc: Quentin Schulz <foss+uboot@0leil.net>
>> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>> ---
>>   tools/binman/entries.rst      | 22 +++++++++++++++++++
>>   tools/binman/etype/mkimage.py | 41 +++++++++++++++++++++++++++++++----
>>   2 files changed, 59 insertions(+), 4 deletions(-)
> 
> Reviewed-by: Simon Glass <sjg@chromium.org>
> 
> I wonder if we should move this logic to binman (from mkimage) when
> all the boards are converted to binman?

Not sure this fits the "Relationship to mkimage" section in binman.rst? 
What part of the logic exactly would you like to move from mkimage to 
binman?

Cheers,
Quentin

Re: [RFC PATCH 4/8] rockchip: pad u-boot-rockchip.bin correctly

[Quentin Schulz]

Hi Philipp,

On 7/15/22 18:06, Philipp Tomsich wrote:
> On Fri, 15 Jul 2022 at 17:37, Quentin Schulz <foss+uboot@0leil.net> wrote:
>>
>> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
>>
>> On MMC storage media, the TPL/SPL needs to be flashed at offset 32KB.
>> Instead of requesting the user to put the input the appropriate offsets,
>> let's create u-boot-rockchip.bin with the padding already added.
> 
> NAK.
> 
> The storage layout provided by Rockchip leaves space for a
> (protective) MBR and a primary GPT.
> A bootloader update will overwrite the partition table if you create
> the image as you suggest.
> 

Ah, that was what I was missing. Thanks, makes complete sense!

Cheers,
Quentin

Re: [RFC PATCH 7/8] binman: add support for skipping file concatenation for mkimage

[Simon Glass]

Hi Quentin,

On Mon, 18 Jul 2022 at 03:39, Quentin Schulz
<quentin.schulz@theobroma-systems.com> wrote:
>
> Hi Simon,
>
> On 7/16/22 13:58, Simon Glass wrote:
> > On Fri, 15 Jul 2022 at 09:37, Quentin Schulz <foss+uboot@0leil.net> wrote:
> >>
> >> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> >>
> >> Some image types handled by mkimage require the datafiles to be passed
> >> independently (-d data1:data2) for specific handling of each. A
> >> concatenation of datafiles prior to passing them to mkimage wouldn't
> >> work.
> >>
> >> That is the case for rksd and rkspi for example, which require page
> >> alignment (plus some weird hack for rkspi) plus size data of each stage
> >> to be embedded in the mkimage header.
> >>
>
> I forgot to rephrase the commit log. As seen in patch 1/8, there
> actually doesn't seem to be a need for rksd for passing multiple data
> files to mkimage, only the TPL could be passed to mkimage and SPL
> appended right after that blob generated by mkimage. Maybe it's luck but
> it seems to work for me the few tries I did on SD card and eMMC.

OK I see.

>
> >> This adds the ability to tell binman to pass the datafiles without
> >> prior concatenation to mkimage, by adding the multiple-data-files
> >> boolean property to the mkimage node.
> >>
> >> Cc: Quentin Schulz <foss+uboot@0leil.net>
> >> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> >> ---
> >>   tools/binman/entries.rst      | 22 +++++++++++++++++++
> >>   tools/binman/etype/mkimage.py | 41 +++++++++++++++++++++++++++++++----
> >>   2 files changed, 59 insertions(+), 4 deletions(-)
> >
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> >
> > I wonder if we should move this logic to binman (from mkimage) when
> > all the boards are converted to binman?
>
> Not sure this fits the "Relationship to mkimage" section in binman.rst?
> What part of the logic exactly would you like to move from mkimage to
> binman?

The concatenation of the files and the strange SPI processing, for
example. It's just an idea and it is OK to keep it in mkimage.

Regards,
Simon