[PATCH V5 00/12] IOT2050-related enhancements
(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
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.... 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
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
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... 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
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>
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.
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
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 */
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.
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
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>;
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')
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
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
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
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... [3] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files...
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...).
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... [3] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files...
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... [3] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files...
-- Siemens AG, Technology Competence Center Embedded Linux
Regards, Simon
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... [3] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files...
-- Siemens AG, Technology Competence Center Embedded Linux
Regards, Simon
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... [3] https://github.com/siemens/meta-iot2050/blob/master/recipes-bsp/u-boot/files...
-- Siemens AG, Technology Competence Center Embedded Linux
Regards, Simon
-- Siemens AG, Technology Competence Center Embedded Linux
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
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?
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
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.
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
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
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
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
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
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=*
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=*
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
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
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-... + 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
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
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
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:
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;
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
participants (4)
-
Jan Kiszka -
Lothar Waßmann -
Simon Glass -
Tom Rini