[PATCH V5 00/12] IOT2050-related enhancements

[PATCH V5 00/12] IOT2050-related enhancements

[Jan Kiszka]

(Almost) flushing our upstream queue for the IOT2050 device, this mostly
brings board-specific changes such as:

 - updated build process and firmware layout for PG1 vs. PG2 devices
 - more watchdog preparations
 - preparations for verified boot on IOT2050 Advanced devices

This series depends on

https://lore.kernel.org/u-boot/cover.1675426972.git.jan.kiszka@siemens.com/
("env: Enhancements for establishing variable protection")

Changes in v5:
 - factored out two patches

Changes in v4:
 - rebased over latest master
 - make use of new CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN

Changes in v3:
 - further reworked patch 1 to load default env directly, leaving driver
   ordering alone

Changes in v2:
 - rebased over latest master
 - reworked patch 1 to be less invasive to the code
 - added "iot2050: use the named gpio to control the user-button"

Still in our backlog is support for a new variant that comes with M.2
slots. Related DT patches were sent to the kernel and are under review
now.

Jan


CC: chao zeng <chao.zeng@siemens.com>
CC: Su Baocheng <baocheng.su@siemens.com>

Jan Kiszka (9):
  iot2050: Update firmware layout
  iot2050: Add watchdog start to bootcmd
  iot2050: Add CONFIG_ENV_FLAGS_LIST_STATIC
  arm: dts: iot2050: Allow verifying U-Boot proper by SPL
  tools: Add script for converting public key into device tree include
  iot2050: Add script for signing artifacts
  arm: dts: iot2050: Optionally embed OTP programming data into image
  doc: iot2050: Add a note about the watchdog firmware
  iot2050: Refresh defconfigs and activate
    CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN

Su Baocheng (2):
  board: siemens: iot2050: Split the build for PG1 and PG2
  arm: dts: iot2050: Use the auto generator nodes for fdt

chao zeng (1):
  board: siemens: iot2050: use the named gpio to control the user-button

 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi  | 134 ++++++------------
 board/siemens/iot2050/Kconfig                 |  35 ++++-
 board/siemens/iot2050/board.c                 |  17 +--
 ...ot2050_defconfig => iot2050_pg1_defconfig} |  13 +-
 ...ot2050_defconfig => iot2050_pg2_defconfig} |  15 +-
 doc/board/siemens/iot2050.rst                 |  79 ++++++++++-
 include/configs/iot2050.h                     |  17 +++
 tools/binman/missing-blob-help                |  14 +-
 tools/iot2050-sign-fw.sh                      |  51 +++++++
 tools/key2dtsi.py                             |  64 +++++++++
 10 files changed, 309 insertions(+), 130 deletions(-)
 copy configs/{iot2050_defconfig => iot2050_pg1_defconfig} (93%)
 rename configs/{iot2050_defconfig => iot2050_pg2_defconfig} (91%)
 create mode 100755 tools/iot2050-sign-fw.sh
 create mode 100755 tools/key2dtsi.py

-- 
2.35.3

[PATCH V5 01/12] board: siemens: iot2050: Split the build for PG1 and PG2

[Jan Kiszka]

From: Su Baocheng <baocheng.su@siemens.com>

Due to different signature keys, the PG1 and the PG2 boards can no
longer use the same FSBL (tiboot3). This makes it impossible anyway to
maintaine a single flash.bin for both variants, so we can also split the
build.

A new target is added to indicates the build is for PG1 vs. PG2 boards.
Hence now the variants have separated defconfig files.

The runtime board_is_sr1() check does make no sense anymore, so remove
it and replace with build time check.

Documentation is updated accordingly. New binary artifacts are already
available via meta-iot2050.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: refactor config option into targets, tweak some wordings]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi  | 80 ++++++-------------
 board/siemens/iot2050/Kconfig                 | 28 ++++++-
 board/siemens/iot2050/board.c                 | 12 +--
 ...ot2050_defconfig => iot2050_pg1_defconfig} |  2 +-
 ...ot2050_defconfig => iot2050_pg2_defconfig} |  5 +-
 doc/board/siemens/iot2050.rst                 | 15 +++-
 6 files changed, 66 insertions(+), 76 deletions(-)
 copy configs/{iot2050_defconfig => iot2050_pg1_defconfig} (99%)
 rename configs/{iot2050_defconfig => iot2050_pg2_defconfig} (97%)

diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 27058370ccc..3135ad04715 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (c) Siemens AG, 2020-2021
+ * Copyright (c) Siemens AG, 2020-2022
  *
  * Authors:
  *   Jan Kiszka <jan.kiszka@siemens.com>
@@ -17,7 +17,11 @@
 
 		blob-ext@0x000000 {
 			offset = <0x000000>;
-			filename = "tiboot3.bin";
+#ifdef CONFIG_TARGET_IOT2050_A53_PG1
+			filename = "seboot_pg1.bin";
+#else
+			filename = "seboot_pg2.bin";
+#endif
 			missing-msg = "iot2050-seboot";
 		};
 
@@ -43,42 +47,30 @@
 				};
 
 				fdt-iot2050-basic {
-					description = "k3-am6528-iot2050-basic.dtb";
+					description = "k3-am6528-iot2050-basic*.dtb";
 					type = "flat_dt";
 					arch = "arm64";
 					compression = "none";
 					blob {
+#ifdef CONFIG_TARGET_IOT2050_A53_PG1
 						filename = "arch/arm/dts/k3-am6528-iot2050-basic.dtb";
-					};
-				};
-
-				fdt-iot2050-basic-pg2 {
-					description = "k3-am6528-iot2050-basic-pg2.dtb";
-					type = "flat_dt";
-					arch = "arm64";
-					compression = "none";
-					blob {
+#else
 						filename = "arch/arm/dts/k3-am6528-iot2050-basic-pg2.dtb";
+#endif
 					};
 				};
 
 				fdt-iot2050-advanced {
-					description = "k3-am6548-iot2050-advanced.dtb";
+					description = "k3-am6548-iot2050-advanced*.dtb";
 					type = "flat_dt";
 					arch = "arm64";
 					compression = "none";
 					blob {
+#ifdef CONFIG_TARGET_IOT2050_A53_PG1
 						filename = "arch/arm/dts/k3-am6548-iot2050-advanced.dtb";
-					};
-				};
-
-				fdt-iot2050-advanced-pg2 {
-					description = "k3-am6548-iot2050-advanced-pg2.dtb";
-					type = "flat_dt";
-					arch = "arm64";
-					compression = "none";
-					blob {
+#else
 						filename = "arch/arm/dts/k3-am6548-iot2050-advanced-pg2.dtb";
+#endif
 					};
 				};
 
@@ -108,30 +100,12 @@
 #endif
 				};
 
-				conf-iot2050-basic-pg2 {
-					description = "iot2050-basic-pg2";
-					firmware = "u-boot";
-					fdt = "fdt-iot2050-basic-pg2";
-#ifdef CONFIG_WDT_K3_RTI_FW_FILE
-					loadables = "k3-rti-wdt-firmware";
-#endif
-				};
-
 				conf-iot2050-advanced {
 					description = "iot2050-advanced";
 					firmware = "u-boot";
 					fdt = "fdt-iot2050-advanced";
 #ifdef CONFIG_WDT_K3_RTI_FW_FILE
 					loadables = "k3-rti-wdt-firmware";
-#endif
-				};
-
-				conf-iot2050-advanced-pg2 {
-					description = "iot2050-advanced-pg2";
-					firmware = "u-boot";
-					fdt = "fdt-iot2050-advanced-pg2";
-#ifdef CONFIG_WDT_K3_RTI_FW_FILE
-					loadables = "k3-rti-wdt-firmware";
 #endif
 				};
 			};
@@ -150,28 +124,24 @@
 			fill-byte = [00];
 		};
 
-		/* PG1 sysfw, basic variant */
+		/* sysfw, basic variant */
 		blob-ext@0x6c0000 {
 			offset = <0x6c0000>;
-			filename = "sysfw.itb";
+#ifdef CONFIG_TARGET_IOT2050_A53_PG1
+			filename = "sysfw_sr1.itb";
+#else
+			filename = "sysfw_sr2.itb";
+#endif
 			missing-msg = "iot2050-sysfw";
 		};
-		/* PG1 sysfw, advanced variant */
+		/* sysfw, advanced variant */
 		blob-ext@0x740000 {
 			offset = <0x740000>;
-			filename = "sysfw.itb_HS";
-			missing-msg = "iot2050-sysfw";
-		};
-		/* PG2 sysfw, basic variant */
-		blob-ext@0x7c0000 {
-			offset = <0x7c0000>;
-			filename = "sysfw_sr2.itb";
-			missing-msg = "iot2050-sysfw";
-		};
-		/* PG2 sysfw, advanced variant */
-		blob-ext@0x840000 {
-			offset = <0x840000>;
+#ifdef CONFIG_TARGET_IOT2050_A53_PG1
+			filename = "sysfw_sr1.itb_HS";
+#else
 			filename = "sysfw_sr2.itb_HS";
+#endif
 			missing-msg = "iot2050-sysfw";
 		};
 	};
diff --git a/board/siemens/iot2050/Kconfig b/board/siemens/iot2050/Kconfig
index 063142a43bf..a2b40881d11 100644
--- a/board/siemens/iot2050/Kconfig
+++ b/board/siemens/iot2050/Kconfig
@@ -1,20 +1,40 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
-# Copyright (c) Siemens AG, 2018-2021
+# Copyright (c) Siemens AG, 2018-2022
 #
 # Authors:
 #   Le Jin <le.jin@siemens.com>
 #   Jan Kiszka <jan.kiszka@siemens.com>
 
-config TARGET_IOT2050_A53
-	bool "IOT2050 running on A53"
+choice
+        prompt "Siemens SIMATIC IOT2050 boards"
+        optional
+
+config TARGET_IOT2050_A53_PG1
+	bool "IOT2050 PG1 running on A53"
+	select IOT2050_A53_COMMON
+	help
+	  This builds U-Boot for the Product Generation 1 (PG1) of the IOT2050
+	  devices.
+
+config TARGET_IOT2050_A53_PG2
+	bool "IOT2050 PG2 running on A53"
+	select IOT2050_A53_COMMON
+	help
+	  This builds U-Boot for the Product Generation 2 (PG2) of the IOT2050
+	  devices.
+
+endchoice
+
+config IOT2050_A53_COMMON
+	bool
 	select ARM64
 	select SOC_K3_AM654
 	select BOARD_LATE_INIT
 	select SYS_DISABLE_DCACHE_OPS
 	select BINMAN
 
-if TARGET_IOT2050_A53
+if IOT2050_A53_COMMON
 
 config SYS_BOARD
 	default "iot2050"
diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c
index 8f4b0eae495..dbf893000a7 100644
--- a/board/siemens/iot2050/board.c
+++ b/board/siemens/iot2050/board.c
@@ -55,14 +55,6 @@ static bool board_is_advanced(void)
 		strstr((char *)info->name, "IOT2050-ADVANCED") != NULL;
 }
 
-static bool board_is_sr1(void)
-{
-	struct iot2050_info *info = IOT2050_INFO_DATA;
-
-	return info->magic == IOT2050_INFO_MAGIC &&
-		!strstr((char *)info->name, "-PG2");
-}
-
 static void remove_mmc1_target(void)
 {
 	char *boot_targets = strdup(env_get("boot_targets"));
@@ -109,12 +101,12 @@ void set_board_info_env(void)
 	}
 
 	if (board_is_advanced()) {
-		if (board_is_sr1())
+		if (IS_ENABLED(CONFIG_TARGET_IOT2050_A53_PG1))
 			fdtfile = "ti/k3-am6548-iot2050-advanced.dtb";
 		else
 			fdtfile = "ti/k3-am6548-iot2050-advanced-pg2.dtb";
 	} else {
-		if (board_is_sr1())
+		if (IS_ENABLED(CONFIG_TARGET_IOT2050_A53_PG1))
 			fdtfile = "ti/k3-am6528-iot2050-basic.dtb";
 		else
 			fdtfile = "ti/k3-am6528-iot2050-basic-pg2.dtb";
diff --git a/configs/iot2050_defconfig b/configs/iot2050_pg1_defconfig
similarity index 99%
copy from configs/iot2050_defconfig
copy to configs/iot2050_pg1_defconfig
index 4ae85f391b7..3dfebedfb97 100644
--- a/configs/iot2050_defconfig
+++ b/configs/iot2050_pg1_defconfig
@@ -8,7 +8,7 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_SOC_K3_AM654=y
-CONFIG_TARGET_IOT2050_A53=y
+CONFIG_TARGET_IOT2050_A53_PG1=y
 CONFIG_ENV_SIZE=0x20000
 CONFIG_ENV_OFFSET=0x680000
 CONFIG_ENV_SECT_SIZE=0x20000
diff --git a/configs/iot2050_defconfig b/configs/iot2050_pg2_defconfig
similarity index 97%
rename from configs/iot2050_defconfig
rename to configs/iot2050_pg2_defconfig
index 4ae85f391b7..4eba7a3476d 100644
--- a/configs/iot2050_defconfig
+++ b/configs/iot2050_pg2_defconfig
@@ -8,13 +8,13 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_SOC_K3_AM654=y
-CONFIG_TARGET_IOT2050_A53=y
+CONFIG_TARGET_IOT2050_A53_PG2=y
 CONFIG_ENV_SIZE=0x20000
 CONFIG_ENV_OFFSET=0x680000
 CONFIG_ENV_SECT_SIZE=0x20000
 CONFIG_DM_GPIO=y
 CONFIG_SPL_DM_SPI=y
-CONFIG_DEFAULT_DEVICE_TREE="k3-am6528-iot2050-basic"
+CONFIG_DEFAULT_DEVICE_TREE="k3-am6528-iot2050-basic-pg2"
 CONFIG_SPL_TEXT_BASE=0x80080000
 CONFIG_SYS_PROMPT="IOT2050> "
 CONFIG_SPL_SERIAL=y
@@ -74,6 +74,7 @@ CONFIG_SPL_OF_LIST="k3-am65-iot2050-spl"
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
+CONFIG_DM=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_SPL_REGMAP=y
diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index 7e97f817ce4..fd3431fa3f8 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -24,9 +24,10 @@ Binary dependencies can be found in
 https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild.
 The following binaries from that source need to be present in the build folder:
 
- - tiboot3.bin
- - sysfw.itb
- - sysfw.itb_HS
+ - seboot_pg1.bin
+ - sysfw_sr1.itb
+ - sysfw_sr1.itb_HS
+ - seboot_pg2.bin
  - sysfw_sr2.itb
  - sysfw_sr2.itb_HS
 
@@ -57,7 +58,13 @@ U-Boot:
 
  $ export ATF=/path/to/bl31.bin
  $ export TEE=/path/to/tee-pager_v2.bin
- $ make iot2050_defconfig
+
+ # configure for PG1
+ $ make iot2050_pg1_defconfig
+
+ # or configure for PG2
+ $ make iot2050_pg2_defconfig
+
  $ make
 
 Flashing
-- 
2.35.3

[PATCH V5 02/12] arm: dts: iot2050: Use the auto generator nodes for fdt

[Jan Kiszka]

From: Su Baocheng <baocheng.su@siemens.com>

Refactor according to the entry `fit: Entry containing a FIT` of
document tools/binman/README.entries.

As the generator uses the device tree name for the config description,
board_fit_config_name_match requires a small adjustment as well.

Signed-off-by: Su Baocheng <baocheng.su@siemens.com>
[Jan: re-add now required CONFIG_OF_LIST, update config matching]
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 44 ++++----------------
 board/siemens/iot2050/board.c                |  3 ++
 configs/iot2050_pg1_defconfig                |  1 +
 configs/iot2050_pg2_defconfig                |  1 +
 4 files changed, 12 insertions(+), 37 deletions(-)

diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 3135ad04715..46669576864 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -32,6 +32,7 @@
 
 		fit@0x280000 {
 			description = "U-Boot for IOT2050";
+			fit,fdt-list = "of-list";
 			offset = <0x280000>;
 			images {
 				u-boot {
@@ -46,32 +47,11 @@
 					};
 				};
 
-				fdt-iot2050-basic {
-					description = "k3-am6528-iot2050-basic*.dtb";
+				@fdt-SEQ {
+					description = "fdt-NAME";
 					type = "flat_dt";
 					arch = "arm64";
 					compression = "none";
-					blob {
-#ifdef CONFIG_TARGET_IOT2050_A53_PG1
-						filename = "arch/arm/dts/k3-am6528-iot2050-basic.dtb";
-#else
-						filename = "arch/arm/dts/k3-am6528-iot2050-basic-pg2.dtb";
-#endif
-					};
-				};
-
-				fdt-iot2050-advanced {
-					description = "k3-am6548-iot2050-advanced*.dtb";
-					type = "flat_dt";
-					arch = "arm64";
-					compression = "none";
-					blob {
-#ifdef CONFIG_TARGET_IOT2050_A53_PG1
-						filename = "arch/arm/dts/k3-am6548-iot2050-advanced.dtb";
-#else
-						filename = "arch/arm/dts/k3-am6548-iot2050-advanced-pg2.dtb";
-#endif
-					};
 				};
 
 #ifdef CONFIG_WDT_K3_RTI_FW_FILE
@@ -89,21 +69,11 @@
 			};
 
 			configurations {
-				default = "conf-iot2050-basic";
-
-				conf-iot2050-basic {
-					description = "iot2050-basic";
-					firmware = "u-boot";
-					fdt = "fdt-iot2050-basic";
-#ifdef CONFIG_WDT_K3_RTI_FW_FILE
-					loadables = "k3-rti-wdt-firmware";
-#endif
-				};
-
-				conf-iot2050-advanced {
-					description = "iot2050-advanced";
+				default = "@config-DEFAULT-SEQ";
+				@config-SEQ {
+					description = "NAME";
 					firmware = "u-boot";
-					fdt = "fdt-iot2050-advanced";
+					fdt = "fdt-SEQ";
 #ifdef CONFIG_WDT_K3_RTI_FW_FILE
 					loadables = "k3-rti-wdt-firmware";
 #endif
diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c
index dbf893000a7..57d7009e8c7 100644
--- a/board/siemens/iot2050/board.c
+++ b/board/siemens/iot2050/board.c
@@ -154,6 +154,9 @@ int board_fit_config_name_match(const char *name)
 	struct iot2050_info *info = IOT2050_INFO_DATA;
 	char upper_name[32];
 
+	/* skip the prefix "k3-am65x8-" */
+	name += 10;
+
 	if (info->magic != IOT2050_INFO_MAGIC ||
 	    strlen(name) >= sizeof(upper_name))
 		return -1;
diff --git a/configs/iot2050_pg1_defconfig b/configs/iot2050_pg1_defconfig
index 3dfebedfb97..85f153842cd 100644
--- a/configs/iot2050_pg1_defconfig
+++ b/configs/iot2050_pg1_defconfig
@@ -69,6 +69,7 @@ CONFIG_CMD_TIME=y
 # CONFIG_ISO_PARTITION is not set
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIST="k3-am6528-iot2050-basic k3-am6548-iot2050-advanced"
 CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_SPL_OF_LIST="k3-am65-iot2050-spl"
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
diff --git a/configs/iot2050_pg2_defconfig b/configs/iot2050_pg2_defconfig
index 4eba7a3476d..6b5e50a99a7 100644
--- a/configs/iot2050_pg2_defconfig
+++ b/configs/iot2050_pg2_defconfig
@@ -69,6 +69,7 @@ CONFIG_CMD_TIME=y
 # CONFIG_ISO_PARTITION is not set
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIST="k3-am6528-iot2050-basic-pg2 k3-am6548-iot2050-advanced-pg2"
 CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_SPL_OF_LIST="k3-am65-iot2050-spl"
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
-- 
2.35.3

[PATCH V5 03/12] iot2050: Update firmware layout

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

The latest version of the binary-only firmware parts come in a combined
form of FSBL and sysfw containers. This implies some layout changes to
the generated firmware image but also makes handling of artifacts much
simpler (4 files less). The env locations will not change, just the
space reserved for U-Boot will shrink from 4 to 3 MB - still plenty of
space left in practice.

Adjust configuration and documentation accordingly.

Along this change, add a new reservation for update commands of the
user-controlled OTP part. A specific userspace tool will fill it, and
the FSBL will evaluate it during boot. This reservation will use 64K of
the former sysfw section.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 30 ++++++--------------
 configs/iot2050_pg1_defconfig                |  2 +-
 configs/iot2050_pg2_defconfig                |  2 +-
 doc/board/siemens/iot2050.rst                |  4 ---
 tools/binman/missing-blob-help               |  8 +-----
 5 files changed, 11 insertions(+), 35 deletions(-)

diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 46669576864..3ee0842e993 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -25,15 +25,15 @@
 			missing-msg = "iot2050-seboot";
 		};
 
-		blob@0x080000 {
-			offset = <0x080000>;
+		blob@0x180000 {
+			offset = <0x180000>;
 			filename = "tispl.bin";
 		};
 
-		fit@0x280000 {
+		fit@0x380000 {
 			description = "U-Boot for IOT2050";
 			fit,fdt-list = "of-list";
-			offset = <0x280000>;
+			offset = <0x380000>;
 			images {
 				u-boot {
 					description = "U-Boot";
@@ -94,25 +94,11 @@
 			fill-byte = [00];
 		};
 
-		/* sysfw, basic variant */
-		blob-ext@0x6c0000 {
+		/* OTP update command block */
+		fill@0x6c0000 {
 			offset = <0x6c0000>;
-#ifdef CONFIG_TARGET_IOT2050_A53_PG1
-			filename = "sysfw_sr1.itb";
-#else
-			filename = "sysfw_sr2.itb";
-#endif
-			missing-msg = "iot2050-sysfw";
-		};
-		/* sysfw, advanced variant */
-		blob-ext@0x740000 {
-			offset = <0x740000>;
-#ifdef CONFIG_TARGET_IOT2050_A53_PG1
-			filename = "sysfw_sr1.itb_HS";
-#else
-			filename = "sysfw_sr2.itb_HS";
-#endif
-			missing-msg = "iot2050-sysfw";
+			size   = <0x010000>;
+			fill-byte = [ff];
 		};
 	};
 };
diff --git a/configs/iot2050_pg1_defconfig b/configs/iot2050_pg1_defconfig
index 85f153842cd..28930aac5eb 100644
--- a/configs/iot2050_pg1_defconfig
+++ b/configs/iot2050_pg1_defconfig
@@ -52,7 +52,7 @@ CONFIG_SPL_POWER_DOMAIN=y
 # CONFIG_SPL_SPI_FLASH_TINY is not set
 CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x280000
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x380000
 CONFIG_SYS_MAXARGS=64
 CONFIG_SYS_PBSIZE=1050
 CONFIG_CMD_ASKENV=y
diff --git a/configs/iot2050_pg2_defconfig b/configs/iot2050_pg2_defconfig
index 6b5e50a99a7..c76abcca672 100644
--- a/configs/iot2050_pg2_defconfig
+++ b/configs/iot2050_pg2_defconfig
@@ -52,7 +52,7 @@ CONFIG_SPL_POWER_DOMAIN=y
 # CONFIG_SPL_SPI_FLASH_TINY is not set
 CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x280000
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x380000
 CONFIG_SYS_MAXARGS=64
 CONFIG_SYS_PBSIZE=1050
 CONFIG_CMD_ASKENV=y
diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index fd3431fa3f8..26972e20ae9 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -25,11 +25,7 @@ https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot/files/pre
 The following binaries from that source need to be present in the build folder:
 
  - seboot_pg1.bin
- - sysfw_sr1.itb
- - sysfw_sr1.itb_HS
  - seboot_pg2.bin
- - sysfw_sr2.itb
- - sysfw_sr2.itb_HS
 
 Building
 --------
diff --git a/tools/binman/missing-blob-help b/tools/binman/missing-blob-help
index c61ca02a35e..5bb8961ce03 100644
--- a/tools/binman/missing-blob-help
+++ b/tools/binman/missing-blob-help
@@ -21,13 +21,7 @@ Please read the section on SCP firmware in board/sunxi/README.sunxi64
 iot2050-seboot:
 See the documentation for IOT2050 board. Your image is missing SEBoot
 which is mandatory for board startup. Prebuilt SEBoot located at
-meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild/tiboot3.bin.
-
-iot2050-sysfw:
-See the documentation for IOT2050 board. Your image is missing system
-firmware which is mandatory for board startup. Prebuilt system firmware
-located at meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild/
-with sysfw prefix.
+meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild/seboot_pg*.bin.
 
 k3-rti-wdt-firmware:
 If CONFIG_WDT_K3_RTI_LOAD_FW is enabled, a firmware image is needed for
-- 
2.35.3

[PATCH V5 04/12] iot2050: Add watchdog start to bootcmd

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Allows run-time control over watchdog auto-start and the timeout via
setting the environment variable watchdog_timeout_ms. A value of zero
means "do not start". Use CONFIG_WATCHDOG_TIMEOUT_MSECS as initial value
and this to zero by default. Users can then enable the watchdog once the
use and OS which picks it up during boot.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 configs/iot2050_pg1_defconfig | 2 ++
 configs/iot2050_pg2_defconfig | 2 ++
 include/configs/iot2050.h     | 9 +++++++++
 3 files changed, 13 insertions(+)

diff --git a/configs/iot2050_pg1_defconfig b/configs/iot2050_pg1_defconfig
index 28930aac5eb..6c6af35cdee 100644
--- a/configs/iot2050_pg1_defconfig
+++ b/configs/iot2050_pg1_defconfig
@@ -32,6 +32,7 @@ CONFIG_OF_BOARD_SETUP=y
 CONFIG_BOOTSTAGE=y
 CONFIG_SHOW_BOOT_PROGRESS=y
 CONFIG_SPL_SHOW_BOOT_PROGRESS=y
+CONFIG_BOOTCOMMAND="run start_watchdog; run distro_bootcmd"
 CONFIG_CONSOLE_MUX=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_MAX_SIZE=0x58000
@@ -141,6 +142,7 @@ CONFIG_USB_DWC3_GENERIC=y
 CONFIG_USB_KEYBOARD=y
 # CONFIG_WATCHDOG is not set
 # CONFIG_WATCHDOG_AUTOSTART is not set
+CONFIG_WATCHDOG_TIMEOUT_MSECS=0
 CONFIG_WDT=y
 CONFIG_WDT_K3_RTI=y
 CONFIG_WDT_K3_RTI_LOAD_FW=y
diff --git a/configs/iot2050_pg2_defconfig b/configs/iot2050_pg2_defconfig
index c76abcca672..43410160c8a 100644
--- a/configs/iot2050_pg2_defconfig
+++ b/configs/iot2050_pg2_defconfig
@@ -32,6 +32,7 @@ CONFIG_OF_BOARD_SETUP=y
 CONFIG_BOOTSTAGE=y
 CONFIG_SHOW_BOOT_PROGRESS=y
 CONFIG_SPL_SHOW_BOOT_PROGRESS=y
+CONFIG_BOOTCOMMAND="run start_watchdog; run distro_bootcmd"
 CONFIG_CONSOLE_MUX=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_MAX_SIZE=0x58000
@@ -142,6 +143,7 @@ CONFIG_USB_DWC3_GENERIC=y
 CONFIG_USB_KEYBOARD=y
 # CONFIG_WATCHDOG is not set
 # CONFIG_WATCHDOG_AUTOSTART is not set
+CONFIG_WATCHDOG_TIMEOUT_MSECS=0
 CONFIG_WDT=y
 CONFIG_WDT_K3_RTI=y
 CONFIG_WDT_K3_RTI_LOAD_FW=y
diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h
index 7d087413362..5186dfd8ff8 100644
--- a/include/configs/iot2050.h
+++ b/include/configs/iot2050.h
@@ -15,6 +15,14 @@
 
 /* SPL Loader Configuration */
 
+#define WATCHDOG_ENV							\
+	"watchdog_timeout_ms=" __stringify(CONFIG_WATCHDOG_TIMEOUT_MSECS) "\0" \
+	"start_watchdog=if test ${watchdog_timeout_ms} -gt 0; then "	\
+		"wdt dev watchdog@40610000; "				\
+		"wdt start ${watchdog_timeout_ms}; "			\
+		"echo Watchdog started, timeout ${watchdog_timeout_ms} ms; " \
+		"fi\0"
+
 /* U-Boot general configuration */
 #define EXTRA_ENV_IOT2050_BOARD_SETTINGS				\
 	"usb_pgood_delay=900\0"
@@ -43,6 +51,7 @@
 #define CFG_EXTRA_ENV_SETTINGS					\
 	DEFAULT_LINUX_BOOT_ENV						\
 	BOOTENV								\
+	WATCHDOG_ENV							\
 	EXTRA_ENV_IOT2050_BOARD_SETTINGS
 
 #include <configs/ti_armv7_common.h>
-- 
2.35.3

Re: [PATCH V5 04/12] iot2050: Add watchdog start to bootcmd

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1618 bytes --]

On Fri, Feb 03, 2023 at 01:26:33PM +0100, Jan Kiszka wrote:

> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> Allows run-time control over watchdog auto-start and the timeout via
> setting the environment variable watchdog_timeout_ms. A value of zero
> means "do not start". Use CONFIG_WATCHDOG_TIMEOUT_MSECS as initial value
> and this to zero by default. Users can then enable the watchdog once the
> use and OS which picks it up during boot.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
[snip]
> diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h
> index 7d087413362..5186dfd8ff8 100644
> --- a/include/configs/iot2050.h
> +++ b/include/configs/iot2050.h
> @@ -15,6 +15,14 @@
>  
>  /* SPL Loader Configuration */
>  
> +#define WATCHDOG_ENV							\
> +	"watchdog_timeout_ms=" __stringify(CONFIG_WATCHDOG_TIMEOUT_MSECS) "\0" \
> +	"start_watchdog=if test ${watchdog_timeout_ms} -gt 0; then "	\
> +		"wdt dev watchdog@40610000; "				\
> +		"wdt start ${watchdog_timeout_ms}; "			\
> +		"echo Watchdog started, timeout ${watchdog_timeout_ms} ms; " \
> +		"fi\0"
> +
>  /* U-Boot general configuration */
>  #define EXTRA_ENV_IOT2050_BOARD_SETTINGS				\
>  	"usb_pgood_delay=900\0"
> @@ -43,6 +51,7 @@
>  #define CFG_EXTRA_ENV_SETTINGS					\
>  	DEFAULT_LINUX_BOOT_ENV						\
>  	BOOTENV								\
> +	WATCHDOG_ENV							\
>  	EXTRA_ENV_IOT2050_BOARD_SETTINGS

As a follow-up I would like to see all of this migrated to the plain
text environment, see board/*/*/*.env for various more and less complex
examples of this kind of conversion.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH V5 04/12] iot2050: Add watchdog start to bootcmd

[Jan Kiszka]

On 03.02.23 19:51, Tom Rini wrote:
> On Fri, Feb 03, 2023 at 01:26:33PM +0100, Jan Kiszka wrote:
> 
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> Allows run-time control over watchdog auto-start and the timeout via
>> setting the environment variable watchdog_timeout_ms. A value of zero
>> means "do not start". Use CONFIG_WATCHDOG_TIMEOUT_MSECS as initial value
>> and this to zero by default. Users can then enable the watchdog once the
>> use and OS which picks it up during boot.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> [snip]
>> diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h
>> index 7d087413362..5186dfd8ff8 100644
>> --- a/include/configs/iot2050.h
>> +++ b/include/configs/iot2050.h
>> @@ -15,6 +15,14 @@
>>  
>>  /* SPL Loader Configuration */
>>  
>> +#define WATCHDOG_ENV							\
>> +	"watchdog_timeout_ms=" __stringify(CONFIG_WATCHDOG_TIMEOUT_MSECS) "\0" \
>> +	"start_watchdog=if test ${watchdog_timeout_ms} -gt 0; then "	\
>> +		"wdt dev watchdog@40610000; "				\
>> +		"wdt start ${watchdog_timeout_ms}; "			\
>> +		"echo Watchdog started, timeout ${watchdog_timeout_ms} ms; " \
>> +		"fi\0"
>> +
>>  /* U-Boot general configuration */
>>  #define EXTRA_ENV_IOT2050_BOARD_SETTINGS				\
>>  	"usb_pgood_delay=900\0"
>> @@ -43,6 +51,7 @@
>>  #define CFG_EXTRA_ENV_SETTINGS					\
>>  	DEFAULT_LINUX_BOOT_ENV						\
>>  	BOOTENV								\
>> +	WATCHDOG_ENV							\
>>  	EXTRA_ENV_IOT2050_BOARD_SETTINGS
> 
> As a follow-up I would like to see all of this migrated to the plain
> text environment, see board/*/*/*.env for various more and less complex
> examples of this kind of conversion.

As I have to do a v6 anyway, let me check if this could be done quickly
as well.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

[PATCH V5 05/12] iot2050: Add CONFIG_ENV_FLAGS_LIST_STATIC

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Will be needed when CONFIG_ENV_WRITEABLE_LIST is enabled. The listed
variables shall remain writable, for informational purposes - they have
to be considered untrusted because the persistent U-Boot env is not
protected.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 include/configs/iot2050.h | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h
index 5186dfd8ff8..52094e18ea8 100644
--- a/include/configs/iot2050.h
+++ b/include/configs/iot2050.h
@@ -56,4 +56,12 @@
 
 #include <configs/ti_armv7_common.h>
 
+#ifdef CONFIG_ENV_WRITEABLE_LIST
+/* relevant for secure boot with CONFIG_ENV_WRITEABLE_LIST=y */
+#define CONFIG_ENV_FLAGS_LIST_STATIC					\
+	"board_uuid:sw,board_name:sw,board_serial:sw,board_a5e:sw,"	\
+	"mlfb:sw,fw_version:sw,seboot_version:sw,"			\
+	"eth1addr:mw,eth2addr:mw,watchdog_timeout_ms:dw,boot_targets:sw"
+#endif
+
 #endif /* __CONFIG_IOT2050_H */
-- 
2.35.3

Re: [PATCH V5 05/12] iot2050: Add CONFIG_ENV_FLAGS_LIST_STATIC

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]

On Fri, Feb 03, 2023 at 01:26:34PM +0100, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> Will be needed when CONFIG_ENV_WRITEABLE_LIST is enabled. The listed
> variables shall remain writable, for informational purposes - they have
> to be considered untrusted because the persistent U-Boot env is not
> protected.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>  include/configs/iot2050.h | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h
> index 5186dfd8ff8..52094e18ea8 100644
> --- a/include/configs/iot2050.h
> +++ b/include/configs/iot2050.h
> @@ -56,4 +56,12 @@
>  
>  #include <configs/ti_armv7_common.h>
>  
> +#ifdef CONFIG_ENV_WRITEABLE_LIST
> +/* relevant for secure boot with CONFIG_ENV_WRITEABLE_LIST=y */
> +#define CONFIG_ENV_FLAGS_LIST_STATIC					\
> +	"board_uuid:sw,board_name:sw,board_serial:sw,board_a5e:sw,"	\
> +	"mlfb:sw,fw_version:sw,seboot_version:sw,"			\
> +	"eth1addr:mw,eth2addr:mw,watchdog_timeout_ms:dw,boot_targets:sw"
> +#endif
> +
>  #endif /* __CONFIG_IOT2050_H */

I don't think you've tested the whole series on top of current master,
this needs to be CFG_ENV_FLAGS_LIST_STATIC. If this is the only thing
that needs changing, I can just correct this while applying, otherwise a
v6, and I'll try my best to not forget to grab this before -rc2, I know
this whole series has been waiting a while so I thank you for your
patience and persistence here.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH V5 05/12] iot2050: Add CONFIG_ENV_FLAGS_LIST_STATIC

[Jan Kiszka]

On 03.02.23 19:52, Tom Rini wrote:
> On Fri, Feb 03, 2023 at 01:26:34PM +0100, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> Will be needed when CONFIG_ENV_WRITEABLE_LIST is enabled. The listed
>> variables shall remain writable, for informational purposes - they have
>> to be considered untrusted because the persistent U-Boot env is not
>> protected.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>  include/configs/iot2050.h | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/include/configs/iot2050.h b/include/configs/iot2050.h
>> index 5186dfd8ff8..52094e18ea8 100644
>> --- a/include/configs/iot2050.h
>> +++ b/include/configs/iot2050.h
>> @@ -56,4 +56,12 @@
>>  
>>  #include <configs/ti_armv7_common.h>
>>  
>> +#ifdef CONFIG_ENV_WRITEABLE_LIST
>> +/* relevant for secure boot with CONFIG_ENV_WRITEABLE_LIST=y */
>> +#define CONFIG_ENV_FLAGS_LIST_STATIC					\
>> +	"board_uuid:sw,board_name:sw,board_serial:sw,board_a5e:sw,"	\
>> +	"mlfb:sw,fw_version:sw,seboot_version:sw,"			\
>> +	"eth1addr:mw,eth2addr:mw,watchdog_timeout_ms:dw,boot_targets:sw"
>> +#endif
>> +
>>  #endif /* __CONFIG_IOT2050_H */
> 
> I don't think you've tested the whole series on top of current master,
> this needs to be CFG_ENV_FLAGS_LIST_STATIC. If this is the only thing
> that needs changing, I can just correct this while applying, otherwise a
> v6, and I'll try my best to not forget to grab this before -rc2, I know
> this whole series has been waiting a while so I thank you for your
> patience and persistence here.
> 

Oh, thanks for pointing that I indeed forgot to test the secure boot
case again this time. I'll fix up and do v6 ASAP.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

[PATCH V5 06/12] arm: dts: iot2050: Allow verifying U-Boot proper by SPL

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Add hashes and configuration signature stubs to prepare verified boot
of main U-Boot by SPL.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 3ee0842e993..9082a79a034 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -14,6 +14,7 @@
 		filename = "flash.bin";
 		pad-byte = <0xff>;
 		size = <0x8c0000>;
+		allow-repack;
 
 		blob-ext@0x000000 {
 			offset = <0x000000>;
@@ -45,6 +46,9 @@
 					entry = <0x80800000>;
 					u-boot-nodtb {
 					};
+					hash {
+						algo = "sha256";
+					};
 				};
 
 				@fdt-SEQ {
@@ -52,6 +56,9 @@
 					type = "flat_dt";
 					arch = "arm64";
 					compression = "none";
+					hash {
+						algo = "sha256";
+					};
 				};
 
 #ifdef CONFIG_WDT_K3_RTI_FW_FILE
@@ -64,6 +71,9 @@
 						filename = CONFIG_WDT_K3_RTI_FW_FILE;
 						missing-msg = "k3-rti-wdt-firmware";
 					};
+					hash {
+						algo = "sha256";
+					};
 				};
 #endif
 			};
@@ -77,10 +87,16 @@
 #ifdef CONFIG_WDT_K3_RTI_FW_FILE
 					loadables = "k3-rti-wdt-firmware";
 #endif
+					signature {
+						sign-images = "firmware", "fdt", "loadables";
+					};
 				};
 			};
 		};
 
+		fdtmap {
+		};
+
 		/* primary env */
 		fill@0x680000 {
 			offset = <0x680000>;
-- 
2.35.3

[PATCH V5 07/12] tools: Add script for converting public key into device tree include

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Allows to create a public key device tree dtsi for inclusion into U-Boot
SPL and proper during first build already. This can be achieved via
CONFIG_DEVICE_TREE_INCLUDES.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 tools/key2dtsi.py | 64 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 64 insertions(+)
 create mode 100755 tools/key2dtsi.py

diff --git a/tools/key2dtsi.py b/tools/key2dtsi.py
new file mode 100755
index 00000000000..1dbb2cc94bf
--- /dev/null
+++ b/tools/key2dtsi.py
@@ -0,0 +1,64 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Public key to dtsi converter.
+#
+# Copyright (c) Siemens AG, 2022
+#
+
+from argparse import ArgumentParser, FileType
+from os.path import basename, splitext
+from Cryptodome.PublicKey import RSA
+from Cryptodome.Util.number import inverse
+
+def int_to_bytestr(n, length=None):
+    if not length:
+        length = (n.bit_length() + 7) // 8
+    byte_array = n.to_bytes(length, 'big')
+    return ' '.join(['{:02x}'.format(byte) for byte in byte_array])
+
+ap = ArgumentParser(description='Public key to dtsi converter')
+
+ap.add_argument('--hash', '-H', default='sha256',
+                help='hash to be used with key (default: sha256)')
+ap.add_argument('--required-conf', '-c', action='store_true',
+                help='mark key required for configuration')
+ap.add_argument('--required-image', '-i', action='store_true',
+                help='mark key required for image')
+ap.add_argument('--spl', '-s', action='store_true',
+                help='mark key for usage in SPL')
+ap.add_argument('key_file', metavar='KEY_FILE', type=FileType('r'),
+                help='key file (formats: X.509, PKCS#1, OpenSSH)')
+ap.add_argument('dtsi_file', metavar='DTSI_FILE', type=FileType('w'),
+                help='dtsi output file')
+
+args = ap.parse_args()
+
+key_name, _ = splitext(basename(args.key_file.name))
+
+key_data = args.key_file.read()
+key = RSA.importKey(key_data)
+
+r_squared = (2**key.size_in_bits())**2 % key.n
+n0_inverse = 2**32 - inverse(key.n, 2**32)
+
+out = args.dtsi_file
+out.write('/ {\n')
+out.write('\tsignature {\n')
+out.write('\t\tkey-{} {{\n'.format(key_name))
+out.write('\t\t\tkey-name-hint = "{}";\n'.format(key_name))
+out.write('\t\t\talgo = "{},rsa{}";\n'.format(args.hash, key.size_in_bits()))
+out.write('\t\t\trsa,num-bits = <{}>;\n'.format(key.size_in_bits()))
+out.write('\t\t\trsa,modulus = [{}];\n'.format(int_to_bytestr(key.n)))
+out.write('\t\t\trsa,exponent = [{}];\n'.format(int_to_bytestr(key.e, 8)))
+out.write('\t\t\trsa,r-squared = [{}];\n'.format(int_to_bytestr(r_squared)))
+out.write('\t\t\trsa,n0-inverse = <0x{:x}>;\n'.format(n0_inverse))
+if args.required_conf:
+    out.write('\t\t\trequired = "conf";\n')
+elif args.required_image:
+    out.write('\t\t\trequired = "image";\n')
+if args.spl:
+    out.write('\t\t\tu-boot,dm-spl;\n')
+out.write('\t\t};\n')
+out.write('\t};\n')
+out.write('};\n')
-- 
2.35.3

Re: [PATCH V5 07/12] tools: Add script for converting public key into device tree include

[Simon Glass]

Hi Jan,

On Fri, 3 Feb 2023 at 05:29, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> Allows to create a public key device tree dtsi for inclusion into U-Boot
> SPL and proper during first build already. This can be achieved via
> CONFIG_DEVICE_TREE_INCLUDES.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>  tools/key2dtsi.py | 64 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 64 insertions(+)
>  create mode 100755 tools/key2dtsi.py

Please can you build this into Binman instead? We really don't want
any more of these scripts. Perhaps you can add a new entry type?

Regards,
Simon

Re: [PATCH V5 07/12] tools: Add script for converting public key into device tree include

[Jan Kiszka]

On 04.02.23 01:20, Simon Glass wrote:
> Hi Jan,
> 
> On Fri, 3 Feb 2023 at 05:29, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> Allows to create a public key device tree dtsi for inclusion into U-Boot
>> SPL and proper during first build already. This can be achieved via
>> CONFIG_DEVICE_TREE_INCLUDES.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>  tools/key2dtsi.py | 64 +++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 64 insertions(+)
>>  create mode 100755 tools/key2dtsi.py
> 
> Please can you build this into Binman instead? We really don't want
> any more of these scripts. Perhaps you can add a new entry type?
> 

I don't think you are requesting something that makes any sense:

"Binman creates and manipulate *images* for a board from a set of binaries"

Or is binman the new systemd?

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH V5 07/12] tools: Add script for converting public key into device tree include

[Simon Glass]

Hi Jan,

On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 04.02.23 01:20, Simon Glass wrote:
> > Hi Jan,
> >
> > On Fri, 3 Feb 2023 at 05:29, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>
> >> Allows to create a public key device tree dtsi for inclusion into U-Boot
> >> SPL and proper during first build already. This can be achieved via
> >> CONFIG_DEVICE_TREE_INCLUDES.
> >>
> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >> ---
> >>  tools/key2dtsi.py | 64 +++++++++++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 64 insertions(+)
> >>  create mode 100755 tools/key2dtsi.py
> >
> > Please can you build this into Binman instead? We really don't want
> > any more of these scripts. Perhaps you can add a new entry type?
> >
>
> I don't think you are requesting something that makes any sense:
>
> "Binman creates and manipulate *images* for a board from a set of binaries"

I mean that Binman can include a public key in the DT, if that it was
you are wanting. We don't want to add scripts for creating images and
pieces of images.

Perhaps I just don't understand the goal here. How would your script be used?

>
> Or is binman the new systemd?

Er, nope.

Regards,
Simon

Re: [PATCH V5 07/12] tools: Add script for converting public key into device tree include

[Jan Kiszka]

On 04.02.23 23:23, Simon Glass wrote:
> Hi Jan,
> 
> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 04.02.23 01:20, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Fri, 3 Feb 2023 at 05:29, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> Allows to create a public key device tree dtsi for inclusion into U-Boot
>>>> SPL and proper during first build already. This can be achieved via
>>>> CONFIG_DEVICE_TREE_INCLUDES.
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>> ---
>>>>  tools/key2dtsi.py | 64 +++++++++++++++++++++++++++++++++++++++++++++++
>>>>  1 file changed, 64 insertions(+)
>>>>  create mode 100755 tools/key2dtsi.py
>>>
>>> Please can you build this into Binman instead? We really don't want
>>> any more of these scripts. Perhaps you can add a new entry type?
>>>
>>
>> I don't think you are requesting something that makes any sense:
>>
>> "Binman creates and manipulate *images* for a board from a set of binaries"
> 
> I mean that Binman can include a public key in the DT, if that it was
> you are wanting. We don't want to add scripts for creating images and
> pieces of images.
> 
> Perhaps I just don't understand the goal here. How would your script be used?
> 

We feed the generated dtsi into the U-Boot build, using
CONFIG_DEVICE_TREE_INCLUDES. This ensures that will be signed along with
the built artifacts. Have a look at patch 9 for the steps, specifically
the doc update bits. Full bitbake (Isar) integration is available under
[1], specifically [2] in combination with [3].

Jan

[1] https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot
[2] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/rules.tmpl
[3] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/secure-boot.cfg

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH V5 07/12] tools: Add script for converting public key into device tree include

[Jan Kiszka]

On 06.02.23 11:42, Jan Kiszka wrote:
> On 04.02.23 23:23, Simon Glass wrote:
>> Hi Jan,
>>
>> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>
>>> On 04.02.23 01:20, Simon Glass wrote:
>>>> Hi Jan,
>>>>
>>>> On Fri, 3 Feb 2023 at 05:29, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>
>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>
>>>>> Allows to create a public key device tree dtsi for inclusion into U-Boot
>>>>> SPL and proper during first build already. This can be achieved via
>>>>> CONFIG_DEVICE_TREE_INCLUDES.
>>>>>
>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>> ---
>>>>>  tools/key2dtsi.py | 64 +++++++++++++++++++++++++++++++++++++++++++++++
>>>>>  1 file changed, 64 insertions(+)
>>>>>  create mode 100755 tools/key2dtsi.py
>>>>
>>>> Please can you build this into Binman instead? We really don't want
>>>> any more of these scripts. Perhaps you can add a new entry type?
>>>>
>>>
>>> I don't think you are requesting something that makes any sense:
>>>
>>> "Binman creates and manipulate *images* for a board from a set of binaries"
>>
>> I mean that Binman can include a public key in the DT, if that it was
>> you are wanting. We don't want to add scripts for creating images and
>> pieces of images.
>>
>> Perhaps I just don't understand the goal here. How would your script be used?
>>
> 
> We feed the generated dtsi into the U-Boot build, using
> CONFIG_DEVICE_TREE_INCLUDES. This ensures that will be signed along with
> the built artifacts. Have a look at patch 9 for the steps, specifically
> the doc update bits. Full bitbake (Isar) integration is available under
> [1], specifically [2] in combination with [3].

Correction: Patch 8
(https://lore.kernel.org/u-boot/cover.1675427201.git.jan.kiszka@siemens.com/T/#m48507dd6db008485b2ebfb0e61ec9b779dfaa2fd).


> 
> Jan
> 
> [1] https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot
> [2] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/rules.tmpl
> [3] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/secure-boot.cfg
> 

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH V5 07/12] tools: Add script for converting public key into device tree include

[Simon Glass]

Hi Jan,

On Mon, 6 Feb 2023 at 03:42, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 04.02.23 23:23, Simon Glass wrote:
> > Hi Jan,
> >
> > On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>
> >> On 04.02.23 01:20, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Fri, 3 Feb 2023 at 05:29, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>
> >>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>
> >>>> Allows to create a public key device tree dtsi for inclusion into U-Boot
> >>>> SPL and proper during first build already. This can be achieved via
> >>>> CONFIG_DEVICE_TREE_INCLUDES.
> >>>>
> >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>> ---
> >>>>  tools/key2dtsi.py | 64 +++++++++++++++++++++++++++++++++++++++++++++++
> >>>>  1 file changed, 64 insertions(+)
> >>>>  create mode 100755 tools/key2dtsi.py
> >>>
> >>> Please can you build this into Binman instead? We really don't want
> >>> any more of these scripts. Perhaps you can add a new entry type?
> >>>
> >>
> >> I don't think you are requesting something that makes any sense:
> >>
> >> "Binman creates and manipulate *images* for a board from a set of binaries"
> >
> > I mean that Binman can include a public key in the DT, if that it was
> > you are wanting. We don't want to add scripts for creating images and
> > pieces of images.
> >
> > Perhaps I just don't understand the goal here. How would your script be used?
> >
>
> We feed the generated dtsi into the U-Boot build, using
> CONFIG_DEVICE_TREE_INCLUDES. This ensures that will be signed along with
> the built artifacts. Have a look at patch 9 for the steps, specifically
> the doc update bits. Full bitbake (Isar) integration is available under
> [1], specifically [2] in combination with [3].
>

OK, so is Binman run in this case?

> Jan
>
> [1] https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot
> [2] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/rules.tmpl
> [3] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/secure-boot.cfg
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>

Regards,
Simon

Re: [PATCH V5 07/12] tools: Add script for converting public key into device tree include

[Jan Kiszka]

On 07.02.23 05:02, Simon Glass wrote:
> Hi Jan,
> 
> On Mon, 6 Feb 2023 at 03:42, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 04.02.23 23:23, Simon Glass wrote:
>>> Hi Jan,
>>>
>>> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>
>>>> On 04.02.23 01:20, Simon Glass wrote:
>>>>> Hi Jan,
>>>>>
>>>>> On Fri, 3 Feb 2023 at 05:29, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>
>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>
>>>>>> Allows to create a public key device tree dtsi for inclusion into U-Boot
>>>>>> SPL and proper during first build already. This can be achieved via
>>>>>> CONFIG_DEVICE_TREE_INCLUDES.
>>>>>>
>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>> ---
>>>>>>  tools/key2dtsi.py | 64 +++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>  1 file changed, 64 insertions(+)
>>>>>>  create mode 100755 tools/key2dtsi.py
>>>>>
>>>>> Please can you build this into Binman instead? We really don't want
>>>>> any more of these scripts. Perhaps you can add a new entry type?
>>>>>
>>>>
>>>> I don't think you are requesting something that makes any sense:
>>>>
>>>> "Binman creates and manipulate *images* for a board from a set of binaries"
>>>
>>> I mean that Binman can include a public key in the DT, if that it was
>>> you are wanting. We don't want to add scripts for creating images and
>>> pieces of images.
>>>
>>> Perhaps I just don't understand the goal here. How would your script be used?
>>>
>>
>> We feed the generated dtsi into the U-Boot build, using
>> CONFIG_DEVICE_TREE_INCLUDES. This ensures that will be signed along with
>> the built artifacts. Have a look at patch 9 for the steps, specifically
>> the doc update bits. Full bitbake (Isar) integration is available under
>> [1], specifically [2] in combination with [3].
>>
> 
> OK, so is Binman run in this case?
> 

It's run at the end of the build, to assemble the unsigned flash.bin.
And it should have been used also for signing that image (patch 8, see
the other discussion).

Jan

>> Jan
>>
>> [1] https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot
>> [2] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/rules.tmpl
>> [3] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/secure-boot.cfg
>>
>> --
>> Siemens AG, Technology
>> Competence Center Embedded Linux
>>
> 
> Regards,
> Simon

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH V5 07/12] tools: Add script for converting public key into device tree include

[Simon Glass]

Hi Jan,

On Mon, 6 Feb 2023 at 22:47, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 07.02.23 05:02, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 6 Feb 2023 at 03:42, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>
> >> On 04.02.23 23:23, Simon Glass wrote:
> >>> Hi Jan,
> >>>
> >>> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>
> >>>> On 04.02.23 01:20, Simon Glass wrote:
> >>>>> Hi Jan,
> >>>>>
> >>>>> On Fri, 3 Feb 2023 at 05:29, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>
> >>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>>
> >>>>>> Allows to create a public key device tree dtsi for inclusion into U-Boot
> >>>>>> SPL and proper during first build already. This can be achieved via
> >>>>>> CONFIG_DEVICE_TREE_INCLUDES.
> >>>>>>
> >>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>> ---
> >>>>>>  tools/key2dtsi.py | 64 +++++++++++++++++++++++++++++++++++++++++++++++
> >>>>>>  1 file changed, 64 insertions(+)
> >>>>>>  create mode 100755 tools/key2dtsi.py
> >>>>>
> >>>>> Please can you build this into Binman instead? We really don't want
> >>>>> any more of these scripts. Perhaps you can add a new entry type?
> >>>>>
> >>>>
> >>>> I don't think you are requesting something that makes any sense:
> >>>>
> >>>> "Binman creates and manipulate *images* for a board from a set of binaries"
> >>>
> >>> I mean that Binman can include a public key in the DT, if that it was
> >>> you are wanting. We don't want to add scripts for creating images and
> >>> pieces of images.
> >>>
> >>> Perhaps I just don't understand the goal here. How would your script be used?
> >>>
> >>
> >> We feed the generated dtsi into the U-Boot build, using
> >> CONFIG_DEVICE_TREE_INCLUDES. This ensures that will be signed along with
> >> the built artifacts. Have a look at patch 9 for the steps, specifically
> >> the doc update bits. Full bitbake (Isar) integration is available under
> >> [1], specifically [2] in combination with [3].
> >>
> >
> > OK, so is Binman run in this case?
> >
>
> It's run at the end of the build, to assemble the unsigned flash.bin.
> And it should have been used also for signing that image (patch 8, see
> the other discussion).

OK, so how can we get this signing thing into Binman? Does it need a
new entry type? Is there something I can help with there? The input
looks like it should be the key.pem file.

Regards,
SImon


>
> Jan
>
> >> Jan
> >>
> >> [1] https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot
> >> [2] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/rules.tmpl
> >> [3] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files/secure-boot.cfg
> >>
> >> --
> >> Siemens AG, Technology
> >> Competence Center Embedded Linux
> >>
> >
> > Regards,
> > Simon
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>

[PATCH V5 08/12] iot2050: Add script for signing artifacts

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

There are many ways to get a signed firmware for the IOT2050 devices,
namely for the parts under user-control. This script documents one way
of doing it, given a signing key. Augment the board documentation with
the required procedure around it.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 doc/board/siemens/iot2050.rst | 52 +++++++++++++++++++++++++++++++++++
 tools/iot2050-sign-fw.sh      | 51 ++++++++++++++++++++++++++++++++++
 2 files changed, 103 insertions(+)
 create mode 100755 tools/iot2050-sign-fw.sh

diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index 26972e20ae9..4e0925c72c9 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -79,3 +79,55 @@ Via external programmer Dediprog SF100 or SF600:
 .. code-block:: text
 
  $ dpcmd --vcc 2 -v -u flash.bin
+
+Signing (optional)
+------------------
+
+To enable verified boot for the firmware artifacts after the Siemens-managed
+first-stage loader (seboot_pg*.bin), the following steps need to be taken
+before and after the build:
+
+Generate dtsi holding the public key
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: text
+
+ tools/key2dtsi.py -c -s key.pem public-key.dtsi
+
+This will be used to embed the public key into U-Boot SPL and main so that each
+step can validate signatures of the succeeding one.
+
+Adjust U-Boot configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Enabled at least the following options in U-Boot:
+
+.. code-block:: text
+
+ CONFIG_SPL_FIT_SIGNATURE=y
+ CONFIG_DEVICE_TREE_INCLUDES="/path/to/public-key.dtsi"
+ CONFIG_RSA=y
+
+Note that there are more configuration changes needed in order to lock-down
+the command line and the boot process of U-Boot for secure scenarios. These are
+not in scope here.
+
+Build U-Boot
+^^^^^^^^^^^^
+
+See related section above.
+
+Sign flash.bin
+^^^^^^^^^^^^^^
+
+In the build folder still containing artifacts from step 3, invoke:
+
+.. code-block:: text
+
+ tools/iot2050-sign-fw.sh /path/to/key.pem
+
+Flash signed flash.bin
+^^^^^^^^^^^^^^^^^^^^^^
+
+The signing has happen in-place in flash.bin, thus the flashing procedure
+described above.
diff --git a/tools/iot2050-sign-fw.sh b/tools/iot2050-sign-fw.sh
new file mode 100755
index 00000000000..4d1d79498c2
--- /dev/null
+++ b/tools/iot2050-sign-fw.sh
@@ -0,0 +1,51 @@
+#!/bin/sh
+
+if [ -z "$1" ]; then
+	echo "Usage: $0 KEY"
+	exit 1
+fi
+
+TEMP_X509=$(mktemp XXXXXXXX.temp)
+
+REVISION=${2:-0}
+SHA_VAL=$(openssl dgst -sha512 -hex tispl.bin | sed -e "s/^.*= //g")
+BIN_SIZE=$(stat -c %s tispl.bin)
+
+cat <<EOF >$TEMP_X509
+[ req ]
+distinguished_name     = req_distinguished_name
+x509_extensions        = v3_ca
+prompt                 = no
+dirstring_type         = nobmp
+
+[ req_distinguished_name ]
+CN                     = IOT2050 Firmware Signature
+
+[ v3_ca ]
+basicConstraints       = CA:true
+1.3.6.1.4.1.294.1.3    = ASN1:SEQUENCE:swrv
+1.3.6.1.4.1.294.1.34   = ASN1:SEQUENCE:sysfw_image_integrity
+
+[ swrv ]
+swrv = INTEGER:$REVISION
+
+[ sysfw_image_integrity ]
+shaType                = OID:2.16.840.1.101.3.4.2.3
+shaValue               = FORMAT:HEX,OCT:$SHA_VAL
+imageSize              = INTEGER:$BIN_SIZE
+EOF
+
+CERT_X509=$(mktemp XXXXXXXX.crt)
+
+openssl req -new -x509 -key $1 -nodes -outform DER -out $CERT_X509 -config $TEMP_X509 -sha512
+cat $CERT_X509 tispl.bin > tispl.bin_signed
+# currently broken in upstream
+#source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed blob@0x180000
+dd if=tispl.bin_signed of=flash.bin bs=$((0x1000)) seek=$((0x180000/0x1000)) conv=notrunc
+
+rm $TEMP_X509 $CERT_X509
+
+tools/mkimage -G $1 -r -o sha256,rsa4096 -F fit@0x380000.fit
+# currently broken in upstream
+#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
+dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
-- 
2.35.3

Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote:

> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> There are many ways to get a signed firmware for the IOT2050 devices,
> namely for the parts under user-control. This script documents one way
> of doing it, given a signing key. Augment the board documentation with
> the required procedure around it.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
[snip]
> +# currently broken in upstream
> +#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
> +dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc

Is that still a true comment?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts

[Jan Kiszka]

On 03.02.23 19:51, Tom Rini wrote:
> On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote:
> 
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> There are many ways to get a signed firmware for the IOT2050 devices,
>> namely for the parts under user-control. This script documents one way
>> of doing it, given a signing key. Augment the board documentation with
>> the required procedure around it.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> [snip]
>> +# currently broken in upstream
>> +#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
>> +dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
> 
> Is that still a true comment?
> 

binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8870
(755824) is outside the section '/fit@0x380000' starting at 0x0 (0) of
size 0x400 (1024)

And for the second call:

binman: Node '/fit@0x380000': Replacing sections is not implemented yet

We tried fixing but eventually had to give up. binman is not easy to
understand in these corners.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

On Sat, Feb 04, 2023 at 07:34:46AM +0100, Jan Kiszka wrote:
> On 03.02.23 19:51, Tom Rini wrote:
> > On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote:
> > 
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>
> >> There are many ways to get a signed firmware for the IOT2050 devices,
> >> namely for the parts under user-control. This script documents one way
> >> of doing it, given a signing key. Augment the board documentation with
> >> the required procedure around it.
> >>
> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> > [snip]
> >> +# currently broken in upstream
> >> +#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
> >> +dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
> > 
> > Is that still a true comment?
> > 
> 
> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8870
> (755824) is outside the section '/fit@0x380000' starting at 0x0 (0) of
> size 0x400 (1024)
> 
> And for the second call:
> 
> binman: Node '/fit@0x380000': Replacing sections is not implemented yet
> 
> We tried fixing but eventually had to give up. binman is not easy to
> understand in these corners.

OK, thanks.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts

[Simon Glass]

Hi Jan,

On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 03.02.23 19:51, Tom Rini wrote:
> > On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote:
> >
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>
> >> There are many ways to get a signed firmware for the IOT2050 devices,
> >> namely for the parts under user-control. This script documents one way
> >> of doing it, given a signing key. Augment the board documentation with
> >> the required procedure around it.
> >>
> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> > [snip]
> >> +# currently broken in upstream
> >> +#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
> >> +dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
> >
> > Is that still a true comment?
> >
>
> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8870
> (755824) is outside the section '/fit@0x380000' starting at 0x0 (0) of
> size 0x400 (1024)
>
> And for the second call:
>
> binman: Node '/fit@0x380000': Replacing sections is not implemented yet

I sent a patch to implement that.

I'm not quite sure if this resolves the first problem, too. If not,
can you please provide a binman test for the case you need, or
instructions on how to cause the failure?

>
> We tried fixing but eventually had to give up. binman is not easy to
> understand in these corners.

Regards,
Simon

Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts

[Jan Kiszka]

On 04.02.23 23:26, Simon Glass wrote:
> Hi Jan,
> 
> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 03.02.23 19:51, Tom Rini wrote:
>>> On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote:
>>>
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>
>>>> There are many ways to get a signed firmware for the IOT2050 devices,
>>>> namely for the parts under user-control. This script documents one way
>>>> of doing it, given a signing key. Augment the board documentation with
>>>> the required procedure around it.
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>> [snip]
>>>> +# currently broken in upstream
>>>> +#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
>>>> +dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
>>>
>>> Is that still a true comment?
>>>
>>
>> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8870
>> (755824) is outside the section '/fit@0x380000' starting at 0x0 (0) of
>> size 0x400 (1024)
>>
>> And for the second call:
>>
>> binman: Node '/fit@0x380000': Replacing sections is not implemented yet
> 
> I sent a patch to implement that.
> 
> I'm not quite sure if this resolves the first problem, too. If not,
> can you please provide a binman test for the case you need, or
> instructions on how to cause the failure?

Instructions to reproduce are basically
 - apply this series
 - build flash.bin according to doc/board/siemens/iot2050.rst
 - drop the dd calls and activate binman in this signing script
 - run it

But I'll try your patch ASAP on my setup.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts

[Jan Kiszka]

On 06.02.23 11:47, Jan Kiszka wrote:
> On 04.02.23 23:26, Simon Glass wrote:
>> Hi Jan,
>>
>> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>
>>> On 03.02.23 19:51, Tom Rini wrote:
>>>> On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote:
>>>>
>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>
>>>>> There are many ways to get a signed firmware for the IOT2050 devices,
>>>>> namely for the parts under user-control. This script documents one way
>>>>> of doing it, given a signing key. Augment the board documentation with
>>>>> the required procedure around it.
>>>>>
>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>> [snip]
>>>>> +# currently broken in upstream
>>>>> +#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
>>>>> +dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
>>>>
>>>> Is that still a true comment?
>>>>
>>>
>>> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8870
>>> (755824) is outside the section '/fit@0x380000' starting at 0x0 (0) of
>>> size 0x400 (1024)
>>>
>>> And for the second call:
>>>
>>> binman: Node '/fit@0x380000': Replacing sections is not implemented yet
>>
>> I sent a patch to implement that.
>>
>> I'm not quite sure if this resolves the first problem, too. If not,
>> can you please provide a binman test for the case you need, or
>> instructions on how to cause the failure?
> 
> Instructions to reproduce are basically
>  - apply this series
>  - build flash.bin according to doc/board/siemens/iot2050.rst
>  - drop the dd calls and activate binman in this signing script
>  - run it
> 
> But I'll try your patch ASAP on my setup.

Still left with

binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8928
(756008) is outside the section '/fit@0x380000' starting at 0x0 (0) of
size 0x400 (1024)

and

binman: 'NoneType' object has no attribute 'props'

That was for the second call of binman (source/tools/binman/binman
replace -i flash.bin -f fit@0x380000.fit fit@0x380000). The "not
implemented messages is gone.

I've switched back to dd for the first call, but that did not work yet.
So the message above indicates a relevant error.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts

[Simon Glass]

Hi Jan,

On Mon, 6 Feb 2023 at 04:57, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 06.02.23 11:47, Jan Kiszka wrote:
> > On 04.02.23 23:26, Simon Glass wrote:
> >> Hi Jan,
> >>
> >> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>
> >>> On 03.02.23 19:51, Tom Rini wrote:
> >>>> On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote:
> >>>>
> >>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>
> >>>>> There are many ways to get a signed firmware for the IOT2050 devices,
> >>>>> namely for the parts under user-control. This script documents one way
> >>>>> of doing it, given a signing key. Augment the board documentation with
> >>>>> the required procedure around it.
> >>>>>
> >>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>> [snip]
> >>>>> +# currently broken in upstream
> >>>>> +#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
> >>>>> +dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
> >>>>
> >>>> Is that still a true comment?
> >>>>
> >>>
> >>> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8870
> >>> (755824) is outside the section '/fit@0x380000' starting at 0x0 (0) of
> >>> size 0x400 (1024)
> >>>
> >>> And for the second call:
> >>>
> >>> binman: Node '/fit@0x380000': Replacing sections is not implemented yet
> >>
> >> I sent a patch to implement that.
> >>
> >> I'm not quite sure if this resolves the first problem, too. If not,
> >> can you please provide a binman test for the case you need, or
> >> instructions on how to cause the failure?
> >
> > Instructions to reproduce are basically
> >  - apply this series
> >  - build flash.bin according to doc/board/siemens/iot2050.rst
> >  - drop the dd calls and activate binman in this signing script
> >  - run it
> >
> > But I'll try your patch ASAP on my setup.
>
> Still left with
>
> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8928
> (756008) is outside the section '/fit@0x380000' starting at 0x0 (0) of
> size 0x400 (1024)
>
> and
>
> binman: 'NoneType' object has no attribute 'props'
>
> That was for the second call of binman (source/tools/binman/binman
> replace -i flash.bin -f fit@0x380000.fit fit@0x380000). The "not
> implemented messages is gone.
>
> I've switched back to dd for the first call, but that did not work yet.
> So the message above indicates a relevant error.
>
> Jan

I thought I was able to follow all the steps (gosh, so many blobs) but
I got something different from the first 'binman' call in your script.

binman: Error 1 running 'mkimage -t -F
/tmp/binman.l_xl69mi/fit@0x380000.fit': mkimage: verify_header failed
for FIT Image support with exit code 1

I will take a look at that...it is trying to rebuild the FIT and it
should not. It is another case of rebuilding sections that I didn't
think of.

But actually, you need to create a new entry type for your signing
scheme. It looks like the signature is created by openssl and (rather
than putting it in a separate file) it creates a new file containing
both the signature and the file contents. That is a bit of a pain, but
can be made to work.

Basically you need a new entry type (of which the FIT is a child) that
gets the contents of its child, signs it and returns that as the
contents. You can see vblock for an example, and
collection_contents_to_file(). Let me know if you want me to create an
example.

The way it should work is that you run binman once (as part of the
U-Boot build) and it produces a final image. No messing about with
scripts, etc. In this case it looks like the key.pem file should be an
input to your new entry type.

Using binman replace to sign something later is fine, but it is not
the intended use. Binman is supposed to be a single-pass image
builder.

Since we get different results, I suggest pushing a tree somewhere, in
case something is different with the patches.

Regards,
Simon

Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts

[Jan Kiszka]

On 07.02.23 16:28, Simon Glass wrote:
> Hi Jan,
> 
> On Mon, 6 Feb 2023 at 04:57, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>
>> On 06.02.23 11:47, Jan Kiszka wrote:
>>> On 04.02.23 23:26, Simon Glass wrote:
>>>> Hi Jan,
>>>>
>>>> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>
>>>>> On 03.02.23 19:51, Tom Rini wrote:
>>>>>> On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote:
>>>>>>
>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>
>>>>>>> There are many ways to get a signed firmware for the IOT2050 devices,
>>>>>>> namely for the parts under user-control. This script documents one way
>>>>>>> of doing it, given a signing key. Augment the board documentation with
>>>>>>> the required procedure around it.
>>>>>>>
>>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>> [snip]
>>>>>>> +# currently broken in upstream
>>>>>>> +#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
>>>>>>> +dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
>>>>>>
>>>>>> Is that still a true comment?
>>>>>>
>>>>>
>>>>> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8870
>>>>> (755824) is outside the section '/fit@0x380000' starting at 0x0 (0) of
>>>>> size 0x400 (1024)
>>>>>
>>>>> And for the second call:
>>>>>
>>>>> binman: Node '/fit@0x380000': Replacing sections is not implemented yet
>>>>
>>>> I sent a patch to implement that.
>>>>
>>>> I'm not quite sure if this resolves the first problem, too. If not,
>>>> can you please provide a binman test for the case you need, or
>>>> instructions on how to cause the failure?
>>>
>>> Instructions to reproduce are basically
>>>  - apply this series
>>>  - build flash.bin according to doc/board/siemens/iot2050.rst
>>>  - drop the dd calls and activate binman in this signing script
>>>  - run it
>>>
>>> But I'll try your patch ASAP on my setup.
>>
>> Still left with
>>
>> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8928
>> (756008) is outside the section '/fit@0x380000' starting at 0x0 (0) of
>> size 0x400 (1024)
>>
>> and
>>
>> binman: 'NoneType' object has no attribute 'props'
>>
>> That was for the second call of binman (source/tools/binman/binman
>> replace -i flash.bin -f fit@0x380000.fit fit@0x380000). The "not
>> implemented messages is gone.
>>
>> I've switched back to dd for the first call, but that did not work yet.
>> So the message above indicates a relevant error.
>>
>> Jan
> 
> I thought I was able to follow all the steps (gosh, so many blobs) but
> I got something different from the first 'binman' call in your script.
> 
> binman: Error 1 running 'mkimage -t -F
> /tmp/binman.l_xl69mi/fit@0x380000.fit': mkimage: verify_header failed
> for FIT Image support with exit code 1
> 
> I will take a look at that...it is trying to rebuild the FIT and it
> should not. It is another case of rebuilding sections that I didn't
> think of.
> 
> But actually, you need to create a new entry type for your signing
> scheme. It looks like the signature is created by openssl and (rather
> than putting it in a separate file) it creates a new file containing
> both the signature and the file contents. That is a bit of a pain, but
> can be made to work.
> 
> Basically you need a new entry type (of which the FIT is a child) that
> gets the contents of its child, signs it and returns that as the
> contents. You can see vblock for an example, and
> collection_contents_to_file(). Let me know if you want me to create an
> example.
> 
> The way it should work is that you run binman once (as part of the
> U-Boot build) and it produces a final image. No messing about with
> scripts, etc. In this case it looks like the key.pem file should be an
> input to your new entry type.
> 
> Using binman replace to sign something later is fine, but it is not
> the intended use. Binman is supposed to be a single-pass image
> builder.

I strongly suspect we will need split build/sign also in the future
because those steps are generally separate in corporate production envs.
Maybe even 3 steps: assemble, extract hashes that should be signed and
embed signatures of those in the end.

> 
> Since we get different results, I suggest pushing a tree somewhere, in
> case something is different with the patches.

Tree is already at https://github.com/siemens/u-boot/commits/jan/iot2050

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts

[Simon Glass]

Hi Jan,

On Tue, 7 Feb 2023 at 09:45, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 07.02.23 16:28, Simon Glass wrote:
> > Hi Jan,
> >
> > On Mon, 6 Feb 2023 at 04:57, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>
> >> On 06.02.23 11:47, Jan Kiszka wrote:
> >>> On 04.02.23 23:26, Simon Glass wrote:
> >>>> Hi Jan,
> >>>>
> >>>> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>
> >>>>> On 03.02.23 19:51, Tom Rini wrote:
> >>>>>> On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote:
> >>>>>>
> >>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>>>
> >>>>>>> There are many ways to get a signed firmware for the IOT2050 devices,
> >>>>>>> namely for the parts under user-control. This script documents one way
> >>>>>>> of doing it, given a signing key. Augment the board documentation with
> >>>>>>> the required procedure around it.
> >>>>>>>
> >>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>> [snip]
> >>>>>>> +# currently broken in upstream
> >>>>>>> +#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
> >>>>>>> +dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
> >>>>>>
> >>>>>> Is that still a true comment?
> >>>>>>
> >>>>>
> >>>>> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8870
> >>>>> (755824) is outside the section '/fit@0x380000' starting at 0x0 (0) of
> >>>>> size 0x400 (1024)
> >>>>>
> >>>>> And for the second call:
> >>>>>
> >>>>> binman: Node '/fit@0x380000': Replacing sections is not implemented yet
> >>>>
> >>>> I sent a patch to implement that.
> >>>>
> >>>> I'm not quite sure if this resolves the first problem, too. If not,
> >>>> can you please provide a binman test for the case you need, or
> >>>> instructions on how to cause the failure?
> >>>
> >>> Instructions to reproduce are basically
> >>>  - apply this series
> >>>  - build flash.bin according to doc/board/siemens/iot2050.rst
> >>>  - drop the dd calls and activate binman in this signing script
> >>>  - run it
> >>>
> >>> But I'll try your patch ASAP on my setup.
> >>
> >> Still left with
> >>
> >> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8928
> >> (756008) is outside the section '/fit@0x380000' starting at 0x0 (0) of
> >> size 0x400 (1024)
> >>
> >> and
> >>
> >> binman: 'NoneType' object has no attribute 'props'
> >>
> >> That was for the second call of binman (source/tools/binman/binman
> >> replace -i flash.bin -f fit@0x380000.fit fit@0x380000). The "not
> >> implemented messages is gone.
> >>
> >> I've switched back to dd for the first call, but that did not work yet.
> >> So the message above indicates a relevant error.
> >>
> >> Jan
> >
> > I thought I was able to follow all the steps (gosh, so many blobs) but
> > I got something different from the first 'binman' call in your script.
> >
> > binman: Error 1 running 'mkimage -t -F
> > /tmp/binman.l_xl69mi/fit@0x380000.fit': mkimage: verify_header failed
> > for FIT Image support with exit code 1
> >
> > I will take a look at that...it is trying to rebuild the FIT and it
> > should not. It is another case of rebuilding sections that I didn't
> > think of.
> >
> > But actually, you need to create a new entry type for your signing
> > scheme. It looks like the signature is created by openssl and (rather
> > than putting it in a separate file) it creates a new file containing
> > both the signature and the file contents. That is a bit of a pain, but
> > can be made to work.
> >
> > Basically you need a new entry type (of which the FIT is a child) that
> > gets the contents of its child, signs it and returns that as the
> > contents. You can see vblock for an example, and
> > collection_contents_to_file(). Let me know if you want me to create an
> > example.
> >
> > The way it should work is that you run binman once (as part of the
> > U-Boot build) and it produces a final image. No messing about with
> > scripts, etc. In this case it looks like the key.pem file should be an
> > input to your new entry type.
> >
> > Using binman replace to sign something later is fine, but it is not
> > the intended use. Binman is supposed to be a single-pass image
> > builder.
>
> I strongly suspect we will need split build/sign also in the future
> because those steps are generally separate in corporate production envs.
> Maybe even 3 steps: assemble, extract hashes that should be signed and
> embed signatures of those in the end.

Yes I'm sure you are right, that's what I would expect. There is a
'binman sign' command coming[1] so I hope we can use that to make it
easier, too.

Still, we must have a single-step build in U-Boot, so we do need a new
entry type. Let me know if you want me to hack up something as a
starting point.

>
> >
> > Since we get different results, I suggest pushing a tree somewhere, in
> > case something is different with the patches.
>
> Tree is already at https://github.com/siemens/u-boot/commits/jan/iot2050
>
> Jan
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=291386&state=*

Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts

[Simon Glass]

Hi Jan,

On Tue, 7 Feb 2023 at 11:39, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Jan,
>
> On Tue, 7 Feb 2023 at 09:45, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >
> > On 07.02.23 16:28, Simon Glass wrote:
> > > Hi Jan,
> > >
> > > On Mon, 6 Feb 2023 at 04:57, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > >>
> > >> On 06.02.23 11:47, Jan Kiszka wrote:
> > >>> On 04.02.23 23:26, Simon Glass wrote:
> > >>>> Hi Jan,
> > >>>>
> > >>>> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> > >>>>>
> > >>>>> On 03.02.23 19:51, Tom Rini wrote:
> > >>>>>> On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote:
> > >>>>>>
> > >>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> > >>>>>>>
> > >>>>>>> There are many ways to get a signed firmware for the IOT2050 devices,
> > >>>>>>> namely for the parts under user-control. This script documents one way
> > >>>>>>> of doing it, given a signing key. Augment the board documentation with
> > >>>>>>> the required procedure around it.
> > >>>>>>>
> > >>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> > >>>>>> [snip]
> > >>>>>>> +# currently broken in upstream
> > >>>>>>> +#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
> > >>>>>>> +dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
> > >>>>>>
> > >>>>>> Is that still a true comment?
> > >>>>>>
> > >>>>>
> > >>>>> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8870
> > >>>>> (755824) is outside the section '/fit@0x380000' starting at 0x0 (0) of
> > >>>>> size 0x400 (1024)
> > >>>>>
> > >>>>> And for the second call:
> > >>>>>
> > >>>>> binman: Node '/fit@0x380000': Replacing sections is not implemented yet
> > >>>>
> > >>>> I sent a patch to implement that.
> > >>>>
> > >>>> I'm not quite sure if this resolves the first problem, too. If not,
> > >>>> can you please provide a binman test for the case you need, or
> > >>>> instructions on how to cause the failure?
> > >>>
> > >>> Instructions to reproduce are basically
> > >>>  - apply this series
> > >>>  - build flash.bin according to doc/board/siemens/iot2050.rst
> > >>>  - drop the dd calls and activate binman in this signing script
> > >>>  - run it
> > >>>
> > >>> But I'll try your patch ASAP on my setup.
> > >>
> > >> Still left with
> > >>
> > >> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8928
> > >> (756008) is outside the section '/fit@0x380000' starting at 0x0 (0) of
> > >> size 0x400 (1024)
> > >>
> > >> and
> > >>
> > >> binman: 'NoneType' object has no attribute 'props'
> > >>
> > >> That was for the second call of binman (source/tools/binman/binman
> > >> replace -i flash.bin -f fit@0x380000.fit fit@0x380000). The "not
> > >> implemented messages is gone.
> > >>
> > >> I've switched back to dd for the first call, but that did not work yet.
> > >> So the message above indicates a relevant error.
> > >>
> > >> Jan
> > >
> > > I thought I was able to follow all the steps (gosh, so many blobs) but
> > > I got something different from the first 'binman' call in your script.
> > >
> > > binman: Error 1 running 'mkimage -t -F
> > > /tmp/binman.l_xl69mi/fit@0x380000.fit': mkimage: verify_header failed
> > > for FIT Image support with exit code 1
> > >
> > > I will take a look at that...it is trying to rebuild the FIT and it
> > > should not. It is another case of rebuilding sections that I didn't
> > > think of.
> > >
> > > But actually, you need to create a new entry type for your signing
> > > scheme. It looks like the signature is created by openssl and (rather
> > > than putting it in a separate file) it creates a new file containing
> > > both the signature and the file contents. That is a bit of a pain, but
> > > can be made to work.
> > >
> > > Basically you need a new entry type (of which the FIT is a child) that
> > > gets the contents of its child, signs it and returns that as the
> > > contents. You can see vblock for an example, and
> > > collection_contents_to_file(). Let me know if you want me to create an
> > > example.
> > >
> > > The way it should work is that you run binman once (as part of the
> > > U-Boot build) and it produces a final image. No messing about with
> > > scripts, etc. In this case it looks like the key.pem file should be an
> > > input to your new entry type.
> > >
> > > Using binman replace to sign something later is fine, but it is not
> > > the intended use. Binman is supposed to be a single-pass image
> > > builder.
> >
> > I strongly suspect we will need split build/sign also in the future
> > because those steps are generally separate in corporate production envs.
> > Maybe even 3 steps: assemble, extract hashes that should be signed and
> > embed signatures of those in the end.
>
> Yes I'm sure you are right, that's what I would expect. There is a
> 'binman sign' command coming[1] so I hope we can use that to make it
> easier, too.
>
> Still, we must have a single-step build in U-Boot, so we do need a new
> entry type. Let me know if you want me to hack up something as a
> starting point.

Please see here:

https://github.com/sjg20/u-boot/tree/for-jan

There is an entry type to create an x509 certificate, which I think it
part of what you are trying to do in your shell script.

Please take a look and see what you think.

The problem with the 'binman replace' command in the script is that it
seems to be overwriting the fdtmap. I am not sure why but will take a
look.

In any case, we should not be using the script, so let's try to get
the binman description complete for your board, so it contains all the
steps.

Regards,
Simon


>
> >
> > >
> > > Since we get different results, I suggest pushing a tree somewhere, in
> > > case something is different with the patches.
> >
> > Tree is already at https://github.com/siemens/u-boot/commits/jan/iot2050
> >
> > Jan
> >
> > --
> > Siemens AG, Technology
> > Competence Center Embedded Linux
> >
>
> Regards,
> Simon
>
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=291386&state=*

Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts

[Jan Kiszka]

On 13.02.23 05:26, Simon Glass wrote:
> Hi Jan,
> 
> On Tue, 7 Feb 2023 at 11:39, Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi Jan,
>>
>> On Tue, 7 Feb 2023 at 09:45, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>
>>> On 07.02.23 16:28, Simon Glass wrote:
>>>> Hi Jan,
>>>>
>>>> On Mon, 6 Feb 2023 at 04:57, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>
>>>>> On 06.02.23 11:47, Jan Kiszka wrote:
>>>>>> On 04.02.23 23:26, Simon Glass wrote:
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>>>>>>>>
>>>>>>>> On 03.02.23 19:51, Tom Rini wrote:
>>>>>>>>> On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote:
>>>>>>>>>
>>>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>>>>
>>>>>>>>>> There are many ways to get a signed firmware for the IOT2050 devices,
>>>>>>>>>> namely for the parts under user-control. This script documents one way
>>>>>>>>>> of doing it, given a signing key. Augment the board documentation with
>>>>>>>>>> the required procedure around it.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>>>>> [snip]
>>>>>>>>>> +# currently broken in upstream
>>>>>>>>>> +#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
>>>>>>>>>> +dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
>>>>>>>>>
>>>>>>>>> Is that still a true comment?
>>>>>>>>>
>>>>>>>>
>>>>>>>> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8870
>>>>>>>> (755824) is outside the section '/fit@0x380000' starting at 0x0 (0) of
>>>>>>>> size 0x400 (1024)
>>>>>>>>
>>>>>>>> And for the second call:
>>>>>>>>
>>>>>>>> binman: Node '/fit@0x380000': Replacing sections is not implemented yet
>>>>>>>
>>>>>>> I sent a patch to implement that.
>>>>>>>
>>>>>>> I'm not quite sure if this resolves the first problem, too. If not,
>>>>>>> can you please provide a binman test for the case you need, or
>>>>>>> instructions on how to cause the failure?
>>>>>>
>>>>>> Instructions to reproduce are basically
>>>>>>  - apply this series
>>>>>>  - build flash.bin according to doc/board/siemens/iot2050.rst
>>>>>>  - drop the dd calls and activate binman in this signing script
>>>>>>  - run it
>>>>>>
>>>>>> But I'll try your patch ASAP on my setup.
>>>>>
>>>>> Still left with
>>>>>
>>>>> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8928
>>>>> (756008) is outside the section '/fit@0x380000' starting at 0x0 (0) of
>>>>> size 0x400 (1024)
>>>>>
>>>>> and
>>>>>
>>>>> binman: 'NoneType' object has no attribute 'props'
>>>>>
>>>>> That was for the second call of binman (source/tools/binman/binman
>>>>> replace -i flash.bin -f fit@0x380000.fit fit@0x380000). The "not
>>>>> implemented messages is gone.
>>>>>
>>>>> I've switched back to dd for the first call, but that did not work yet.
>>>>> So the message above indicates a relevant error.
>>>>>
>>>>> Jan
>>>>
>>>> I thought I was able to follow all the steps (gosh, so many blobs) but
>>>> I got something different from the first 'binman' call in your script.
>>>>
>>>> binman: Error 1 running 'mkimage -t -F
>>>> /tmp/binman.l_xl69mi/fit@0x380000.fit': mkimage: verify_header failed
>>>> for FIT Image support with exit code 1
>>>>
>>>> I will take a look at that...it is trying to rebuild the FIT and it
>>>> should not. It is another case of rebuilding sections that I didn't
>>>> think of.
>>>>
>>>> But actually, you need to create a new entry type for your signing
>>>> scheme. It looks like the signature is created by openssl and (rather
>>>> than putting it in a separate file) it creates a new file containing
>>>> both the signature and the file contents. That is a bit of a pain, but
>>>> can be made to work.
>>>>
>>>> Basically you need a new entry type (of which the FIT is a child) that
>>>> gets the contents of its child, signs it and returns that as the
>>>> contents. You can see vblock for an example, and
>>>> collection_contents_to_file(). Let me know if you want me to create an
>>>> example.
>>>>
>>>> The way it should work is that you run binman once (as part of the
>>>> U-Boot build) and it produces a final image. No messing about with
>>>> scripts, etc. In this case it looks like the key.pem file should be an
>>>> input to your new entry type.
>>>>
>>>> Using binman replace to sign something later is fine, but it is not
>>>> the intended use. Binman is supposed to be a single-pass image
>>>> builder.
>>>
>>> I strongly suspect we will need split build/sign also in the future
>>> because those steps are generally separate in corporate production envs.
>>> Maybe even 3 steps: assemble, extract hashes that should be signed and
>>> embed signatures of those in the end.
>>
>> Yes I'm sure you are right, that's what I would expect. There is a
>> 'binman sign' command coming[1] so I hope we can use that to make it
>> easier, too.
>>
>> Still, we must have a single-step build in U-Boot, so we do need a new
>> entry type. Let me know if you want me to hack up something as a
>> starting point.
> 
> Please see here:
> 
> https://github.com/sjg20/u-boot/tree/for-jan
> 
> There is an entry type to create an x509 certificate, which I think it
> part of what you are trying to do in your shell script.
> 
> Please take a look and see what you think.
> 

Generating the cert is one problem, and it is surely valuable to have
such a feature in the end - BTW, also for TI's reference boards when
U-Boot is the FSBL (see also board/ti/am65x/README). But the cert is
opt-in for non-secure mode. It moves the payload up when present. That
also needs to be modeled correctly.

> The problem with the 'binman replace' command in the script is that it
> seems to be overwriting the fdtmap. I am not sure why but will take a
> look.

Indeed! TIA.

> 
> In any case, we should not be using the script, so let's try to get
> the binman description complete for your board, so it contains all the
> steps.

I'm open for it, but the path seems longer. Meanwhile, I would
appreciate if we could document to procedure with that script, maybe
leaving a note that this is purely transitional.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [PATCH V5 08/12] iot2050: Add script for signing artifacts

[Simon Glass]

Hi Jan,

On Sun, 12 Feb 2023 at 22:33, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 13.02.23 05:26, Simon Glass wrote:
> > Hi Jan,
> >
> > On Tue, 7 Feb 2023 at 11:39, Simon Glass <sjg@chromium.org> wrote:
> >>
> >> Hi Jan,
> >>
> >> On Tue, 7 Feb 2023 at 09:45, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>
> >>> On 07.02.23 16:28, Simon Glass wrote:
> >>>> Hi Jan,
> >>>>
> >>>> On Mon, 6 Feb 2023 at 04:57, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>
> >>>>> On 06.02.23 11:47, Jan Kiszka wrote:
> >>>>>> On 04.02.23 23:26, Simon Glass wrote:
> >>>>>>> Hi Jan,
> >>>>>>>
> >>>>>>> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka@siemens.com> wrote:
> >>>>>>>>
> >>>>>>>> On 03.02.23 19:51, Tom Rini wrote:
> >>>>>>>>> On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote:
> >>>>>>>>>
> >>>>>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>>>>>>
> >>>>>>>>>> There are many ways to get a signed firmware for the IOT2050 devices,
> >>>>>>>>>> namely for the parts under user-control. This script documents one way
> >>>>>>>>>> of doing it, given a signing key. Augment the board documentation with
> >>>>>>>>>> the required procedure around it.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>>>>> [snip]
> >>>>>>>>>> +# currently broken in upstream
> >>>>>>>>>> +#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
> >>>>>>>>>> +dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
> >>>>>>>>>
> >>>>>>>>> Is that still a true comment?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8870
> >>>>>>>> (755824) is outside the section '/fit@0x380000' starting at 0x0 (0) of
> >>>>>>>> size 0x400 (1024)
> >>>>>>>>
> >>>>>>>> And for the second call:
> >>>>>>>>
> >>>>>>>> binman: Node '/fit@0x380000': Replacing sections is not implemented yet
> >>>>>>>
> >>>>>>> I sent a patch to implement that.
> >>>>>>>
> >>>>>>> I'm not quite sure if this resolves the first problem, too. If not,
> >>>>>>> can you please provide a binman test for the case you need, or
> >>>>>>> instructions on how to cause the failure?
> >>>>>>
> >>>>>> Instructions to reproduce are basically
> >>>>>>  - apply this series
> >>>>>>  - build flash.bin according to doc/board/siemens/iot2050.rst
> >>>>>>  - drop the dd calls and activate binman in this signing script
> >>>>>>  - run it
> >>>>>>
> >>>>>> But I'll try your patch ASAP on my setup.
> >>>>>
> >>>>> Still left with
> >>>>>
> >>>>> binman: Node '/fit@0x380000/images/u-boot': Offset 0x0 (0) size 0xb8928
> >>>>> (756008) is outside the section '/fit@0x380000' starting at 0x0 (0) of
> >>>>> size 0x400 (1024)
> >>>>>
> >>>>> and
> >>>>>
> >>>>> binman: 'NoneType' object has no attribute 'props'
> >>>>>
> >>>>> That was for the second call of binman (source/tools/binman/binman
> >>>>> replace -i flash.bin -f fit@0x380000.fit fit@0x380000). The "not
> >>>>> implemented messages is gone.
> >>>>>
> >>>>> I've switched back to dd for the first call, but that did not work yet.
> >>>>> So the message above indicates a relevant error.
> >>>>>
> >>>>> Jan
> >>>>
> >>>> I thought I was able to follow all the steps (gosh, so many blobs) but
> >>>> I got something different from the first 'binman' call in your script.
> >>>>
> >>>> binman: Error 1 running 'mkimage -t -F
> >>>> /tmp/binman.l_xl69mi/fit@0x380000.fit': mkimage: verify_header failed
> >>>> for FIT Image support with exit code 1
> >>>>
> >>>> I will take a look at that...it is trying to rebuild the FIT and it
> >>>> should not. It is another case of rebuilding sections that I didn't
> >>>> think of.
> >>>>
> >>>> But actually, you need to create a new entry type for your signing
> >>>> scheme. It looks like the signature is created by openssl and (rather
> >>>> than putting it in a separate file) it creates a new file containing
> >>>> both the signature and the file contents. That is a bit of a pain, but
> >>>> can be made to work.
> >>>>
> >>>> Basically you need a new entry type (of which the FIT is a child) that
> >>>> gets the contents of its child, signs it and returns that as the
> >>>> contents. You can see vblock for an example, and
> >>>> collection_contents_to_file(). Let me know if you want me to create an
> >>>> example.
> >>>>
> >>>> The way it should work is that you run binman once (as part of the
> >>>> U-Boot build) and it produces a final image. No messing about with
> >>>> scripts, etc. In this case it looks like the key.pem file should be an
> >>>> input to your new entry type.
> >>>>
> >>>> Using binman replace to sign something later is fine, but it is not
> >>>> the intended use. Binman is supposed to be a single-pass image
> >>>> builder.
> >>>
> >>> I strongly suspect we will need split build/sign also in the future
> >>> because those steps are generally separate in corporate production envs.
> >>> Maybe even 3 steps: assemble, extract hashes that should be signed and
> >>> embed signatures of those in the end.
> >>
> >> Yes I'm sure you are right, that's what I would expect. There is a
> >> 'binman sign' command coming[1] so I hope we can use that to make it
> >> easier, too.
> >>
> >> Still, we must have a single-step build in U-Boot, so we do need a new
> >> entry type. Let me know if you want me to hack up something as a
> >> starting point.
> >
> > Please see here:
> >
> > https://github.com/sjg20/u-boot/tree/for-jan
> >
> > There is an entry type to create an x509 certificate, which I think it
> > part of what you are trying to do in your shell script.
> >
> > Please take a look and see what you think.
> >
>
> Generating the cert is one problem, and it is surely valuable to have
> such a feature in the end - BTW, also for TI's reference boards when
> U-Boot is the FSBL (see also board/ti/am65x/README). But the cert is
> opt-in for non-secure mode. It moves the payload up when present. That
> also needs to be modeled correctly.

Does this mean that the entry needs to be optional? How can we tell
binman what to do? One option is to use the -a entry argument to
provide the key. If that is not present it can mark the entry as zero
size perhaps, or drop it altogether?

>
> > The problem with the 'binman replace' command in the script is that it
> > seems to be overwriting the fdtmap. I am not sure why but will take a
> > look.
>
> Indeed! TIA.

I suppose you saw that this is fixed, or seems t obe.

>
> >
> > In any case, we should not be using the script, so let's try to get
> > the binman description complete for your board, so it contains all the
> > steps.
>
> I'm open for it, but the path seems longer. Meanwhile, I would
> appreciate if we could document to procedure with that script, maybe
> leaving a note that this is purely transitional.

The problem is that these things tend to stick around for a long time.
It took an unreasonable amount of effort for me to remove much of the
SPL_FIT_GENERATOR stuff, for example. It is better to do it correctly
the first time. Migrating things over is always difficult because
sometimes things break, people cannot test the board quickly, patches
languish around, etc.

Putting it another way, here is an exciting oppty to use a data-driven
firmware packer with tests and automatic tool installation!

Regards,
Simon

[PATCH V5 09/12] arm: dts: iot2050: Optionally embed OTP programming data into image

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

Use external blob otpcmd.bin to replace the 0xff filled OTP programming
command block to create a firmware image that provisions the OTP on
first boot. This otpcmd.bin is generated from the customer keys using
steps described in the meta-iot2050 integration layer for the device.

Based on original patch by Baocheng Su.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 8 ++++++++
 board/siemens/iot2050/Kconfig                | 7 +++++++
 doc/board/siemens/iot2050.rst                | 8 ++++++++
 tools/binman/missing-blob-help               | 8 ++++++++
 4 files changed, 31 insertions(+)

diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 9082a79a034..25a22a7b7b8 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -111,10 +111,18 @@
 		};
 
 		/* OTP update command block */
+#if CONFIG_IOT2050_EMBED_OTPCMD
+		blob-ext@0x6c0000 {
+			offset = <0x6c0000>;
+			size   = <0x010000>;
+			filename = "otpcmd.bin";
+			missing-msg = "iot2050-otpcmd";
+#else
 		fill@0x6c0000 {
 			offset = <0x6c0000>;
 			size   = <0x010000>;
 			fill-byte = [ff];
+#endif
 		};
 	};
 };
diff --git a/board/siemens/iot2050/Kconfig b/board/siemens/iot2050/Kconfig
index a2b40881d11..e66b2427d95 100644
--- a/board/siemens/iot2050/Kconfig
+++ b/board/siemens/iot2050/Kconfig
@@ -49,4 +49,11 @@ config IOT2050_BOOT_SWITCH
 	bool "Disable eMMC boot via USER button (Advanced version only)"
 	default y
 
+config IOT2050_EMBED_OTPCMD
+	bool "Embed OTP programming data"
+	help
+	  Embed signed OTP programming data 'otpcmd.bin' into the firmware
+	  image. This data will be evaluated and executed on first boot of the
+	  device.
+
 endif
diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index 4e0925c72c9..cb49a0e36bf 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -27,6 +27,14 @@ The following binaries from that source need to be present in the build folder:
  - seboot_pg1.bin
  - seboot_pg2.bin
 
+For building an image containing the OTP key provisioning data, below binary
+needs to be present in the build folder:
+
+ - otpcmd.bin
+
+Regarding how to generating this otpcmd.bin, please refer to:
+https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/secure-boot-otp-provisioning/files/make-otpcmd.sh
+
 Building
 --------
 
diff --git a/tools/binman/missing-blob-help b/tools/binman/missing-blob-help
index 5bb8961ce03..7e88cd03954 100644
--- a/tools/binman/missing-blob-help
+++ b/tools/binman/missing-blob-help
@@ -23,6 +23,14 @@ See the documentation for IOT2050 board. Your image is missing SEBoot
 which is mandatory for board startup. Prebuilt SEBoot located at
 meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild/seboot_pg*.bin.
 
+iot2050-otpcmd:
+See the documentation for IOT2050 board. Your image is missing OTP command data
+block which is used for provisioning the customer keys to the board.
+Please refer to
+meta-iot2050/tree/master/recipes-bsp/secure-boot-otp-provisioning/files/make-otpcmd.sh
+for how to generate this binary. If you are not using secure boot or do not
+intend to provision the keys, disable CONFIG_IOT2050_EMBED_OTPCMD.
+
 k3-rti-wdt-firmware:
 If CONFIG_WDT_K3_RTI_LOAD_FW is enabled, a firmware image is needed for
 the R5F core(s) to trigger the system reset. One possible source is
-- 
2.35.3

Re: [PATCH V5 09/12] arm: dts: iot2050: Optionally embed OTP programming data into image

[Lothar Waßmann]

Hi,

On Fri,  3 Feb 2023 13:26:38 +0100 Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> 
> Use external blob otpcmd.bin to replace the 0xff filled OTP programming
> command block to create a firmware image that provisions the OTP on
> first boot. This otpcmd.bin is generated from the customer keys using
> steps described in the meta-iot2050 integration layer for the device.
> 
> Based on original patch by Baocheng Su.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>  arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 8 ++++++++
>  board/siemens/iot2050/Kconfig                | 7 +++++++
>  doc/board/siemens/iot2050.rst                | 8 ++++++++
>  tools/binman/missing-blob-help               | 8 ++++++++
>  4 files changed, 31 insertions(+)
> 
> diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> index 9082a79a034..25a22a7b7b8 100644
> --- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> +++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
> @@ -111,10 +111,18 @@
>  		};
>  
>  		/* OTP update command block */
> +#if CONFIG_IOT2050_EMBED_OTPCMD
> +		blob-ext@0x6c0000 {
> +			offset = <0x6c0000>;
> +			size   = <0x010000>;
> +			filename = "otpcmd.bin";
> +			missing-msg = "iot2050-otpcmd";
> +#else
>  		fill@0x6c0000 {
>  			offset = <0x6c0000>;
>  			size   = <0x010000>;
>  			fill-byte = [ff];
> +#endif
>  		};
>
I would rather include the closing brace in the #if #else block...
Otherwise people who might copy part of the code will have a bad
experience.


Lothar Waßmann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________

Re: [PATCH V5 09/12] arm: dts: iot2050: Optionally embed OTP programming data into image

[Jan Kiszka]

On 03.02.23 13:37, Lothar Waßmann wrote:
> Hi,
> 
> On Fri,  3 Feb 2023 13:26:38 +0100 Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> Use external blob otpcmd.bin to replace the 0xff filled OTP programming
>> command block to create a firmware image that provisions the OTP on
>> first boot. This otpcmd.bin is generated from the customer keys using
>> steps described in the meta-iot2050 integration layer for the device.
>>
>> Based on original patch by Baocheng Su.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>  arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 8 ++++++++
>>  board/siemens/iot2050/Kconfig                | 7 +++++++
>>  doc/board/siemens/iot2050.rst                | 8 ++++++++
>>  tools/binman/missing-blob-help               | 8 ++++++++
>>  4 files changed, 31 insertions(+)
>>
>> diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
>> index 9082a79a034..25a22a7b7b8 100644
>> --- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
>> +++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
>> @@ -111,10 +111,18 @@
>>  		};
>>  
>>  		/* OTP update command block */
>> +#if CONFIG_IOT2050_EMBED_OTPCMD
>> +		blob-ext@0x6c0000 {
>> +			offset = <0x6c0000>;
>> +			size   = <0x010000>;
>> +			filename = "otpcmd.bin";
>> +			missing-msg = "iot2050-otpcmd";
>> +#else
>>  		fill@0x6c0000 {
>>  			offset = <0x6c0000>;
>>  			size   = <0x010000>;
>>  			fill-byte = [ff];
>> +#endif
>>  		};
>>
> I would rather include the closing brace in the #if #else block...
> Otherwise people who might copy part of the code will have a bad
> experience.
> 

Yeah, will address if there is a need for v6, otherwise later on top.

Thanks,
Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

[PATCH V5 10/12] doc: iot2050: Add a note about the watchdog firmware

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

This is enabled by default, thus should be described as well.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 doc/board/siemens/iot2050.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index cb49a0e36bf..efe94a448a9 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -27,6 +27,10 @@ The following binaries from that source need to be present in the build folder:
  - seboot_pg1.bin
  - seboot_pg2.bin
 
+When using the watchdog, a related firmware for the R5 core(s) is needed, e.g.
+https://github.com/siemens/k3-rti-wdt. The name and location of the image is
+configured via CONFIG_WDT_K3_RTI_FW_FILE.
+
 For building an image containing the OTP key provisioning data, below binary
 needs to be present in the build folder:
 
-- 
2.35.3

[PATCH V5 11/12] board: siemens: iot2050: use the named gpio to control the user-button

[Jan Kiszka]

From: chao zeng <chao.zeng@siemens.com>

User-button is controlled by the mcu domain gpio number 25.
But main0 main1 mcu domain all have gpio number 25.

To identify where the gpio is from, Using gpio controll base as the prefix
to indicate the gpio resource.

Signed-off-by: chao zeng <chao.zeng@siemens.com>
---
 board/siemens/iot2050/board.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/siemens/iot2050/board.c b/board/siemens/iot2050/board.c
index 57d7009e8c7..2735ae3fb74 100644
--- a/board/siemens/iot2050/board.c
+++ b/board/siemens/iot2050/board.c
@@ -183,7 +183,7 @@ static bool user_button_pressed(void)
 
 	memset(&gpio, 0, sizeof(gpio));
 
-	if (dm_gpio_lookup_name("25", &gpio) < 0 ||
+	if (dm_gpio_lookup_name("gpio@42110000_25", &gpio) < 0 ||
 	    dm_gpio_request(&gpio, "USER button") < 0 ||
 	    dm_gpio_set_dir_flags(&gpio, GPIOD_IS_IN) < 0)
 		return false;
-- 
2.35.3

[PATCH V5 12/12] iot2050: Refresh defconfigs and activate CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN

[Jan Kiszka]

From: Jan Kiszka <jan.kiszka@siemens.com>

This feature is desired on the platform.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 configs/iot2050_pg1_defconfig | 6 +++---
 configs/iot2050_pg2_defconfig | 7 +++----
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/configs/iot2050_pg1_defconfig b/configs/iot2050_pg1_defconfig
index 6c6af35cdee..6f2ab72f921 100644
--- a/configs/iot2050_pg1_defconfig
+++ b/configs/iot2050_pg1_defconfig
@@ -9,6 +9,8 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_SOC_K3_AM654=y
 CONFIG_TARGET_IOT2050_A53_PG1=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80100000
 CONFIG_ENV_SIZE=0x20000
 CONFIG_ENV_OFFSET=0x680000
 CONFIG_ENV_SECT_SIZE=0x20000
@@ -23,11 +25,8 @@ CONFIG_ENV_OFFSET_REDUND=0x6a0000
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI=y
 CONFIG_DISTRO_DEFAULTS=y
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80100000
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL_LOAD_FIT=y
-# CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_BOOTSTAGE=y
 CONFIG_SHOW_BOOT_PROGRESS=y
@@ -147,3 +146,4 @@ CONFIG_WDT=y
 CONFIG_WDT_K3_RTI=y
 CONFIG_WDT_K3_RTI_LOAD_FW=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN=y
diff --git a/configs/iot2050_pg2_defconfig b/configs/iot2050_pg2_defconfig
index 43410160c8a..d2bdeab593b 100644
--- a/configs/iot2050_pg2_defconfig
+++ b/configs/iot2050_pg2_defconfig
@@ -9,6 +9,8 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_SOC_K3_AM654=y
 CONFIG_TARGET_IOT2050_A53_PG2=y
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80100000
 CONFIG_ENV_SIZE=0x20000
 CONFIG_ENV_OFFSET=0x680000
 CONFIG_ENV_SECT_SIZE=0x20000
@@ -23,11 +25,8 @@ CONFIG_ENV_OFFSET_REDUND=0x6a0000
 CONFIG_SPL_SPI_FLASH_SUPPORT=y
 CONFIG_SPL_SPI=y
 CONFIG_DISTRO_DEFAULTS=y
-CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
-CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x80100000
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL_LOAD_FIT=y
-# CONFIG_USE_SPL_FIT_GENERATOR is not set
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_BOOTSTAGE=y
 CONFIG_SHOW_BOOT_PROGRESS=y
@@ -76,7 +75,6 @@ CONFIG_SPL_OF_LIST="k3-am65-iot2050-spl"
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
 CONFIG_ENV_IS_IN_SPI_FLASH=y
 CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
-CONFIG_DM=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
 CONFIG_SPL_REGMAP=y
@@ -148,3 +146,4 @@ CONFIG_WDT=y
 CONFIG_WDT_K3_RTI=y
 CONFIG_WDT_K3_RTI_LOAD_FW=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_EFI_SCROLL_ON_CLEAR_SCREEN=y
-- 
2.35.3