* [PATCH V2 01/13] env: Complete generic support for writable list
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
@ 2022-10-05 8:33 ` Jan Kiszka
2022-10-27 7:49 ` Stefan Herbrechtsmeier
2022-10-05 8:33 ` [PATCH V2 02/13] env: Couple networking-related variable flags to CONFIG_NET Jan Kiszka
` (12 subsequent siblings)
13 siblings, 1 reply; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 8:33 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Joe Hershberger, Marek Vasut
From: Jan Kiszka <jan.kiszka@siemens.com>
This completes what 890feecaab72 started by selecting ENV_APPEND and
ENV_IS_NOWHERE and by moving this driver to top if the list. This
ensures that load operations pick up both the default env and the
permitted parts of the next-prio location. When writing though, we must
use the regular ordering.
With this change, boards only need to define the list of writable
variables but no longer have to provide a custom env_get_location
implementation.
CC: Joe Hershberger <joe.hershberger@ni.com>
CC: Marek Vasut <marex@denx.de>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
env/Kconfig | 2 ++
env/env.c | 22 ++++++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/env/Kconfig b/env/Kconfig
index 24111dfaf47..05b5fbf17d1 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -715,6 +715,8 @@ config ENV_APPEND
config ENV_WRITEABLE_LIST
bool "Permit write access only to listed variables"
+ select ENV_IS_NOWHERE
+ select ENV_APPEND
help
If defined, only environment variables which explicitly set the 'w'
writeable flag can be written and modified at runtime. No variables
diff --git a/env/env.c b/env/env.c
index 69848fb0608..d0649f9540d 100644
--- a/env/env.c
+++ b/env/env.c
@@ -133,6 +133,28 @@ __weak enum env_location arch_env_get_location(enum env_operation op, int prio)
if (prio >= ARRAY_SIZE(env_locations))
return ENVL_UNKNOWN;
+ if (IS_ENABLED(CONFIG_ENV_WRITEABLE_LIST)) {
+ /*
+ * In writeable-list mode, ENVL_NOWHERE gains highest prio by
+ * virtually injecting it at prio 0.
+ */
+ if (prio == 0) {
+ /*
+ * Avoid the injection for write operations as that
+ * would block it.
+ */
+ if (op != ENVOP_SAVE && op != ENVOP_ERASE)
+ return ENVL_NOWHERE;
+ } else {
+ /*
+ * always subtract 1, also for writing because
+ * env_load_prio, which is used for writing, was
+ * initialized with that offset.
+ */
+ prio--;
+ }
+ }
+
return env_locations[prio];
}
--
2.35.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH V2 01/13] env: Complete generic support for writable list
2022-10-05 8:33 ` [PATCH V2 01/13] env: Complete generic support for writable list Jan Kiszka
@ 2022-10-27 7:49 ` Stefan Herbrechtsmeier
2022-10-27 12:38 ` Jan Kiszka
0 siblings, 1 reply; 26+ messages in thread
From: Stefan Herbrechtsmeier @ 2022-10-27 7:49 UTC (permalink / raw)
To: Jan Kiszka, U-Boot Mailing List, trini; +Cc: Joe Hershberger, Marek Vasut
Hi,
Am 05.10.2022 um 10:33 schrieb Jan Kiszka:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> This completes what 890feecaab72 started by selecting ENV_APPEND and
> ENV_IS_NOWHERE and by moving this driver to top if the list. This
> ensures that load operations pick up both the default env and the
> permitted parts of the next-prio location. When writing though, we must
> use the regular ordering.
>
> With this change, boards only need to define the list of writable
> variables but no longer have to provide a custom env_get_location
> implementation.
>
> CC: Joe Hershberger <joe.hershberger@ni.com>
> CC: Marek Vasut <marex@denx.de>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> env/Kconfig | 2 ++
> env/env.c | 22 ++++++++++++++++++++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/env/Kconfig b/env/Kconfig
> index 24111dfaf47..05b5fbf17d1 100644
> --- a/env/Kconfig
> +++ b/env/Kconfig
> @@ -715,6 +715,8 @@ config ENV_APPEND
>
> config ENV_WRITEABLE_LIST
> bool "Permit write access only to listed variables"
> + select ENV_IS_NOWHERE
> + select ENV_APPEND
> help
> If defined, only environment variables which explicitly set the 'w'
> writeable flag can be written and modified at runtime. No variables
> diff --git a/env/env.c b/env/env.c
> index 69848fb0608..d0649f9540d 100644
> --- a/env/env.c
> +++ b/env/env.c
> @@ -133,6 +133,28 @@ __weak enum env_location arch_env_get_location(enum env_operation op, int prio)
> if (prio >= ARRAY_SIZE(env_locations))
> return ENVL_UNKNOWN;
>
> + if (IS_ENABLED(CONFIG_ENV_WRITEABLE_LIST)) {
> + /*
> + * In writeable-list mode, ENVL_NOWHERE gains highest prio by
> + * virtually injecting it at prio 0.
> + */
> + if (prio == 0) {
> + /*
> + * Avoid the injection for write operations as that
> + * would block it.
> + */
> + if (op != ENVOP_SAVE && op != ENVOP_ERASE)
> + return ENVL_NOWHERE;
Is it consensus now to use ENVL_NOWHERE as synonym for default
environment? If I remember correct this was rejected in the past and
ENVL_NOWHERE should only be used if no enviroment is available.
Why don't you call env_set_default(NULL, 0) in env_load() before
env_driver_lookup()?
> + } else {
> + /*
> + * always subtract 1, also for writing because
> + * env_load_prio, which is used for writing, was
> + * initialized with that offset.
> + */
> + prio--;
> + }
> + }
> +
> return env_locations[prio];
> }
>
Regards
Stefan
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH V2 01/13] env: Complete generic support for writable list
2022-10-27 7:49 ` Stefan Herbrechtsmeier
@ 2022-10-27 12:38 ` Jan Kiszka
2022-10-28 8:34 ` Stefan Herbrechtsmeier
0 siblings, 1 reply; 26+ messages in thread
From: Jan Kiszka @ 2022-10-27 12:38 UTC (permalink / raw)
To: Stefan Herbrechtsmeier, U-Boot Mailing List, trini
Cc: Joe Hershberger, Marek Vasut
On 27.10.22 09:49, Stefan Herbrechtsmeier wrote:
> Hi,
>
> Am 05.10.2022 um 10:33 schrieb Jan Kiszka:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> This completes what 890feecaab72 started by selecting ENV_APPEND and
>> ENV_IS_NOWHERE and by moving this driver to top if the list. This
>> ensures that load operations pick up both the default env and the
>> permitted parts of the next-prio location. When writing though, we must
>> use the regular ordering.
>>
>> With this change, boards only need to define the list of writable
>> variables but no longer have to provide a custom env_get_location
>> implementation.
>>
>> CC: Joe Hershberger <joe.hershberger@ni.com>
>> CC: Marek Vasut <marex@denx.de>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>> env/Kconfig | 2 ++
>> env/env.c | 22 ++++++++++++++++++++++
>> 2 files changed, 24 insertions(+)
>>
>> diff --git a/env/Kconfig b/env/Kconfig
>> index 24111dfaf47..05b5fbf17d1 100644
>> --- a/env/Kconfig
>> +++ b/env/Kconfig
>> @@ -715,6 +715,8 @@ config ENV_APPEND
>> config ENV_WRITEABLE_LIST
>> bool "Permit write access only to listed variables"
>> + select ENV_IS_NOWHERE
>> + select ENV_APPEND
>> help
>> If defined, only environment variables which explicitly set
>> the 'w'
>> writeable flag can be written and modified at runtime. No
>> variables
>> diff --git a/env/env.c b/env/env.c
>> index 69848fb0608..d0649f9540d 100644
>> --- a/env/env.c
>> +++ b/env/env.c
>> @@ -133,6 +133,28 @@ __weak enum env_location
>> arch_env_get_location(enum env_operation op, int prio)
>> if (prio >= ARRAY_SIZE(env_locations))
>> return ENVL_UNKNOWN;
>> + if (IS_ENABLED(CONFIG_ENV_WRITEABLE_LIST)) {
>> + /*
>> + * In writeable-list mode, ENVL_NOWHERE gains highest prio by
>> + * virtually injecting it at prio 0.
>> + */
>> + if (prio == 0) {
>> + /*
>> + * Avoid the injection for write operations as that
>> + * would block it.
>> + */
>> + if (op != ENVOP_SAVE && op != ENVOP_ERASE)
>> + return ENVL_NOWHERE;
>
> Is it consensus now to use ENVL_NOWHERE as synonym for default
> environment? If I remember correct this was rejected in the past and
> ENVL_NOWHERE should only be used if no enviroment is available.
>
> Why don't you call env_set_default(NULL, 0) in env_load() before
> env_driver_lookup()?
Worth to explore... if that should avoid this logic here... Let me try.
Jan
>
>> + } else {
>> + /*
>> + * always subtract 1, also for writing because
>> + * env_load_prio, which is used for writing, was
>> + * initialized with that offset.
>> + */
>> + prio--;
>> + }
>> + }
>> +
>> return env_locations[prio];
>> }
>>
>
> Regards
>
> Stefan
>
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH V2 01/13] env: Complete generic support for writable list
2022-10-27 12:38 ` Jan Kiszka
@ 2022-10-28 8:34 ` Stefan Herbrechtsmeier
0 siblings, 0 replies; 26+ messages in thread
From: Stefan Herbrechtsmeier @ 2022-10-28 8:34 UTC (permalink / raw)
To: Jan Kiszka, U-Boot Mailing List, trini; +Cc: Joe Hershberger, Marek Vasut
Hi Jan,
Am 27.10.2022 um 14:38 schrieb Jan Kiszka:
> On 27.10.22 09:49, Stefan Herbrechtsmeier wrote:
>> Hi,
>>
>> Am 05.10.2022 um 10:33 schrieb Jan Kiszka:
>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>
>>> This completes what 890feecaab72 started by selecting ENV_APPEND and
>>> ENV_IS_NOWHERE and by moving this driver to top if the list. This
>>> ensures that load operations pick up both the default env and the
>>> permitted parts of the next-prio location. When writing though, we must
>>> use the regular ordering.
>>>
>>> With this change, boards only need to define the list of writable
>>> variables but no longer have to provide a custom env_get_location
>>> implementation.
>>>
>>> CC: Joe Hershberger <joe.hershberger@ni.com>
>>> CC: Marek Vasut <marex@denx.de>
>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>> ---
>>> env/Kconfig | 2 ++
>>> env/env.c | 22 ++++++++++++++++++++++
>>> 2 files changed, 24 insertions(+)
>>>
>>> diff --git a/env/Kconfig b/env/Kconfig
>>> index 24111dfaf47..05b5fbf17d1 100644
>>> --- a/env/Kconfig
>>> +++ b/env/Kconfig
>>> @@ -715,6 +715,8 @@ config ENV_APPEND
>>> config ENV_WRITEABLE_LIST
>>> bool "Permit write access only to listed variables"
>>> + select ENV_IS_NOWHERE
>>> + select ENV_APPEND
>>> help
>>> If defined, only environment variables which explicitly set
>>> the 'w'
>>> writeable flag can be written and modified at runtime. No
>>> variables
>>> diff --git a/env/env.c b/env/env.c
>>> index 69848fb0608..d0649f9540d 100644
>>> --- a/env/env.c
>>> +++ b/env/env.c
>>> @@ -133,6 +133,28 @@ __weak enum env_location
>>> arch_env_get_location(enum env_operation op, int prio)
>>> if (prio >= ARRAY_SIZE(env_locations))
>>> return ENVL_UNKNOWN;
>>> + if (IS_ENABLED(CONFIG_ENV_WRITEABLE_LIST)) {
>>> + /*
>>> + * In writeable-list mode, ENVL_NOWHERE gains highest prio by
>>> + * virtually injecting it at prio 0.
>>> + */
>>> + if (prio == 0) {
>>> + /*
>>> + * Avoid the injection for write operations as that
>>> + * would block it.
>>> + */
>>> + if (op != ENVOP_SAVE && op != ENVOP_ERASE)
>>> + return ENVL_NOWHERE;
>> Is it consensus now to use ENVL_NOWHERE as synonym for default
>> environment? If I remember correct this was rejected in the past and
>> ENVL_NOWHERE should only be used if no enviroment is available.
>>
>> Why don't you call env_set_default(NULL, 0) in env_load() before
>> env_driver_lookup()?
> Worth to explore... if that should avoid this logic here... Let me try.
Additionally we have remove the `#if !CONFIG_IS_ENABLED(ENV_APPEND)
arround the `return 0` in env_load() and the following change in env_export
--- a/env/common.c
+++ b/env/common.c
@@ -234,7 +234,7 @@ int env_export(env_t *env_out)
ssize_t len;
res = (char *)env_out->data;
- len = hexport_r(&env_htab, '\0', 0, &res, ENV_SIZE, 0, NULL);
+ len = hexport_r(&env_htab, '\0', H_EXTERNAL, &res, ENV_SIZE, 0, NULL);
if (len < 0) {
pr_err("Cannot export environment: errno = %d\n", errno);
return 1;
I can't remeber why the H_EXTERNAL in env_export was needed.
Regards
Stefan
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH V2 02/13] env: Couple networking-related variable flags to CONFIG_NET
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
2022-10-05 8:33 ` [PATCH V2 01/13] env: Complete generic support for writable list Jan Kiszka
@ 2022-10-05 8:33 ` Jan Kiszka
2022-10-05 8:33 ` [PATCH V2 03/13] tools: Add script for converting public key into device tree include Jan Kiszka
` (11 subsequent siblings)
13 siblings, 0 replies; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 8:33 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Joe Hershberger
From: Jan Kiszka <jan.kiszka@siemens.com>
Boards may set networking variables programmatically, thus may have
CONFIG_NET on but CONFIG_CMD_NET off. The IOT2050 is an example.
CC: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
env/flags.c | 10 +++++-----
include/env_flags.h | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/env/flags.c b/env/flags.c
index e3e833c4333..e2866361dfe 100644
--- a/env/flags.c
+++ b/env/flags.c
@@ -22,7 +22,7 @@
#include <env_internal.h>
#endif
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
#define ENV_FLAGS_NET_VARTYPE_REPS "im"
#else
#define ENV_FLAGS_NET_VARTYPE_REPS ""
@@ -57,7 +57,7 @@ static const char * const env_flags_vartype_names[] = {
"decimal",
"hexadecimal",
"boolean",
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
"IP address",
"MAC address",
#endif
@@ -211,7 +211,7 @@ static void skip_num(int hex, const char *value, const char **end,
*end = value;
}
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
int eth_validate_ethaddr_str(const char *addr)
{
const char *end;
@@ -244,7 +244,7 @@ static int _env_flags_validate_type(const char *value,
enum env_flags_vartype type)
{
const char *end;
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
const char *cur;
int i;
#endif
@@ -273,7 +273,7 @@ static int _env_flags_validate_type(const char *value,
if (value[1] != '\0')
return -1;
break;
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
case env_flags_vartype_ipaddr:
cur = value;
for (i = 0; i < 4; i++) {
diff --git a/include/env_flags.h b/include/env_flags.h
index 313cb8c49a6..b49ec8e80f1 100644
--- a/include/env_flags.h
+++ b/include/env_flags.h
@@ -12,7 +12,7 @@ enum env_flags_vartype {
env_flags_vartype_decimal,
env_flags_vartype_hex,
env_flags_vartype_bool,
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
env_flags_vartype_ipaddr,
env_flags_vartype_macaddr,
#endif
@@ -111,7 +111,7 @@ enum env_flags_varaccess env_flags_parse_varaccess(const char *flags);
*/
enum env_flags_varaccess env_flags_parse_varaccess_from_binflags(int binflags);
-#ifdef CONFIG_CMD_NET
+#ifdef CONFIG_NET
/*
* Check if a string has the format of an Ethernet MAC address
*/
--
2.35.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH V2 03/13] tools: Add script for converting public key into device tree include
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
2022-10-05 8:33 ` [PATCH V2 01/13] env: Complete generic support for writable list Jan Kiszka
2022-10-05 8:33 ` [PATCH V2 02/13] env: Couple networking-related variable flags to CONFIG_NET Jan Kiszka
@ 2022-10-05 8:33 ` Jan Kiszka
2022-10-05 8:33 ` [PATCH V2 04/13] board: siemens: iot2050: Split the build for PG1 and PG2 Jan Kiszka
` (10 subsequent siblings)
13 siblings, 0 replies; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 8:33 UTC (permalink / raw)
To: U-Boot Mailing List
From: Jan Kiszka <jan.kiszka@siemens.com>
Allows to create a public key device tree dtsi for inclusion into U-Boot
SPL and proper during first build already. This can be achieved via
CONFIG_DEVICE_TREE_INCLUDES.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
tools/key2dtsi.py | 64 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
create mode 100755 tools/key2dtsi.py
diff --git a/tools/key2dtsi.py b/tools/key2dtsi.py
new file mode 100755
index 00000000000..1dbb2cc94bf
--- /dev/null
+++ b/tools/key2dtsi.py
@@ -0,0 +1,64 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Public key to dtsi converter.
+#
+# Copyright (c) Siemens AG, 2022
+#
+
+from argparse import ArgumentParser, FileType
+from os.path import basename, splitext
+from Cryptodome.PublicKey import RSA
+from Cryptodome.Util.number import inverse
+
+def int_to_bytestr(n, length=None):
+ if not length:
+ length = (n.bit_length() + 7) // 8
+ byte_array = n.to_bytes(length, 'big')
+ return ' '.join(['{:02x}'.format(byte) for byte in byte_array])
+
+ap = ArgumentParser(description='Public key to dtsi converter')
+
+ap.add_argument('--hash', '-H', default='sha256',
+ help='hash to be used with key (default: sha256)')
+ap.add_argument('--required-conf', '-c', action='store_true',
+ help='mark key required for configuration')
+ap.add_argument('--required-image', '-i', action='store_true',
+ help='mark key required for image')
+ap.add_argument('--spl', '-s', action='store_true',
+ help='mark key for usage in SPL')
+ap.add_argument('key_file', metavar='KEY_FILE', type=FileType('r'),
+ help='key file (formats: X.509, PKCS#1, OpenSSH)')
+ap.add_argument('dtsi_file', metavar='DTSI_FILE', type=FileType('w'),
+ help='dtsi output file')
+
+args = ap.parse_args()
+
+key_name, _ = splitext(basename(args.key_file.name))
+
+key_data = args.key_file.read()
+key = RSA.importKey(key_data)
+
+r_squared = (2**key.size_in_bits())**2 % key.n
+n0_inverse = 2**32 - inverse(key.n, 2**32)
+
+out = args.dtsi_file
+out.write('/ {\n')
+out.write('\tsignature {\n')
+out.write('\t\tkey-{} {{\n'.format(key_name))
+out.write('\t\t\tkey-name-hint = "{}";\n'.format(key_name))
+out.write('\t\t\talgo = "{},rsa{}";\n'.format(args.hash, key.size_in_bits()))
+out.write('\t\t\trsa,num-bits = <{}>;\n'.format(key.size_in_bits()))
+out.write('\t\t\trsa,modulus = [{}];\n'.format(int_to_bytestr(key.n)))
+out.write('\t\t\trsa,exponent = [{}];\n'.format(int_to_bytestr(key.e, 8)))
+out.write('\t\t\trsa,r-squared = [{}];\n'.format(int_to_bytestr(r_squared)))
+out.write('\t\t\trsa,n0-inverse = <0x{:x}>;\n'.format(n0_inverse))
+if args.required_conf:
+ out.write('\t\t\trequired = "conf";\n')
+elif args.required_image:
+ out.write('\t\t\trequired = "image";\n')
+if args.spl:
+ out.write('\t\t\tu-boot,dm-spl;\n')
+out.write('\t\t};\n')
+out.write('\t};\n')
+out.write('};\n')
--
2.35.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH V2 04/13] board: siemens: iot2050: Split the build for PG1 and PG2
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
` (2 preceding siblings ...)
2022-10-05 8:33 ` [PATCH V2 03/13] tools: Add script for converting public key into device tree include Jan Kiszka
@ 2022-10-05 8:33 ` Jan Kiszka
2022-10-05 8:33 ` [PATCH V2 05/13] arm: dts: iot2050: Use the auto generator nodes for fdt Jan Kiszka
` (9 subsequent siblings)
13 siblings, 0 replies; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 8:33 UTC (permalink / raw)
To: U-Boot Mailing List
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} | 4 +-
doc/board/siemens/iot2050.rst | 15 +++-
6 files changed, 65 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 b965ae9fa49..050ddb5899b 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 81cce0812b5..4a591041491 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 81cce0812b5..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
diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index 7e97f817ce4..fd3431fa3f8 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -24,9 +24,10 @@ Binary dependencies can be found in
https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild.
The following binaries from that source need to be present in the build folder:
- - tiboot3.bin
- - sysfw.itb
- - sysfw.itb_HS
+ - seboot_pg1.bin
+ - sysfw_sr1.itb
+ - sysfw_sr1.itb_HS
+ - seboot_pg2.bin
- sysfw_sr2.itb
- sysfw_sr2.itb_HS
@@ -57,7 +58,13 @@ U-Boot:
$ export ATF=/path/to/bl31.bin
$ export TEE=/path/to/tee-pager_v2.bin
- $ make iot2050_defconfig
+
+ # configure for PG1
+ $ make iot2050_pg1_defconfig
+
+ # or configure for PG2
+ $ make iot2050_pg2_defconfig
+
$ make
Flashing
--
2.35.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH V2 05/13] arm: dts: iot2050: Use the auto generator nodes for fdt
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
` (3 preceding siblings ...)
2022-10-05 8:33 ` [PATCH V2 04/13] board: siemens: iot2050: Split the build for PG1 and PG2 Jan Kiszka
@ 2022-10-05 8:33 ` Jan Kiszka
2022-10-05 8:33 ` [PATCH V2 06/13] iot2050: Update firmware layout Jan Kiszka
` (8 subsequent siblings)
13 siblings, 0 replies; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 8:33 UTC (permalink / raw)
To: U-Boot Mailing List
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 050ddb5899b..2be5d1eefc3 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 4a591041491..953206b3432 100644
--- a/configs/iot2050_pg1_defconfig
+++ b/configs/iot2050_pg1_defconfig
@@ -69,6 +69,7 @@ CONFIG_CMD_TIME=y
# CONFIG_ISO_PARTITION is not set
CONFIG_OF_CONTROL=y
CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIST="k3-am6528-iot2050-basic k3-am6548-iot2050-advanced"
CONFIG_SPL_MULTI_DTB_FIT=y
CONFIG_SPL_OF_LIST="k3-am65-iot2050-spl"
CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
diff --git a/configs/iot2050_pg2_defconfig b/configs/iot2050_pg2_defconfig
index 4eba7a3476d..6b5e50a99a7 100644
--- a/configs/iot2050_pg2_defconfig
+++ b/configs/iot2050_pg2_defconfig
@@ -69,6 +69,7 @@ CONFIG_CMD_TIME=y
# CONFIG_ISO_PARTITION is not set
CONFIG_OF_CONTROL=y
CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIST="k3-am6528-iot2050-basic-pg2 k3-am6548-iot2050-advanced-pg2"
CONFIG_SPL_MULTI_DTB_FIT=y
CONFIG_SPL_OF_LIST="k3-am65-iot2050-spl"
CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
--
2.35.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH V2 06/13] iot2050: Update firmware layout
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
` (4 preceding siblings ...)
2022-10-05 8:33 ` [PATCH V2 05/13] arm: dts: iot2050: Use the auto generator nodes for fdt Jan Kiszka
@ 2022-10-05 8:33 ` Jan Kiszka
2022-10-05 8:33 ` [PATCH V2 07/13] iot2050: Add watchdog start to bootcmd Jan Kiszka
` (7 subsequent siblings)
13 siblings, 0 replies; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 8:33 UTC (permalink / raw)
To: U-Boot Mailing List
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 953206b3432..934266c26ef 100644
--- a/configs/iot2050_pg1_defconfig
+++ b/configs/iot2050_pg1_defconfig
@@ -52,7 +52,7 @@ CONFIG_SPL_POWER_DOMAIN=y
# CONFIG_SPL_SPI_FLASH_TINY is not set
CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x280000
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x380000
CONFIG_SYS_MAXARGS=64
CONFIG_SYS_PBSIZE=1050
CONFIG_CMD_ASKENV=y
diff --git a/configs/iot2050_pg2_defconfig b/configs/iot2050_pg2_defconfig
index 6b5e50a99a7..c76abcca672 100644
--- a/configs/iot2050_pg2_defconfig
+++ b/configs/iot2050_pg2_defconfig
@@ -52,7 +52,7 @@ CONFIG_SPL_POWER_DOMAIN=y
# CONFIG_SPL_SPI_FLASH_TINY is not set
CONFIG_SPL_SPI_FLASH_SFDP_SUPPORT=y
CONFIG_SPL_SPI_LOAD=y
-CONFIG_SYS_SPI_U_BOOT_OFFS=0x280000
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x380000
CONFIG_SYS_MAXARGS=64
CONFIG_SYS_PBSIZE=1050
CONFIG_CMD_ASKENV=y
diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index fd3431fa3f8..26972e20ae9 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -25,11 +25,7 @@ https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/u-boot/files/pre
The following binaries from that source need to be present in the build folder:
- seboot_pg1.bin
- - sysfw_sr1.itb
- - sysfw_sr1.itb_HS
- seboot_pg2.bin
- - sysfw_sr2.itb
- - sysfw_sr2.itb_HS
Building
--------
diff --git a/tools/binman/missing-blob-help b/tools/binman/missing-blob-help
index c61ca02a35e..5bb8961ce03 100644
--- a/tools/binman/missing-blob-help
+++ b/tools/binman/missing-blob-help
@@ -21,13 +21,7 @@ Please read the section on SCP firmware in board/sunxi/README.sunxi64
iot2050-seboot:
See the documentation for IOT2050 board. Your image is missing SEBoot
which is mandatory for board startup. Prebuilt SEBoot located at
-meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild/tiboot3.bin.
-
-iot2050-sysfw:
-See the documentation for IOT2050 board. Your image is missing system
-firmware which is mandatory for board startup. Prebuilt system firmware
-located at meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild/
-with sysfw prefix.
+meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild/seboot_pg*.bin.
k3-rti-wdt-firmware:
If CONFIG_WDT_K3_RTI_LOAD_FW is enabled, a firmware image is needed for
--
2.35.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH V2 07/13] iot2050: Add watchdog start to bootcmd
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
` (5 preceding siblings ...)
2022-10-05 8:33 ` [PATCH V2 06/13] iot2050: Update firmware layout Jan Kiszka
@ 2022-10-05 8:33 ` Jan Kiszka
2022-10-05 8:33 ` [PATCH V2 08/13] iot2050: Add CONFIG_ENV_FLAGS_LIST_STATIC Jan Kiszka
` (6 subsequent siblings)
13 siblings, 0 replies; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 8:33 UTC (permalink / raw)
To: U-Boot Mailing List
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 934266c26ef..49f81109364 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
@@ -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/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 0f6150fc9c7..dc4b5f90595 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 CONFIG_EXTRA_ENV_SETTINGS \
DEFAULT_LINUX_BOOT_ENV \
BOOTENV \
+ WATCHDOG_ENV \
EXTRA_ENV_IOT2050_BOARD_SETTINGS
#include <configs/ti_armv7_common.h>
--
2.35.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH V2 08/13] iot2050: Add CONFIG_ENV_FLAGS_LIST_STATIC
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
` (6 preceding siblings ...)
2022-10-05 8:33 ` [PATCH V2 07/13] iot2050: Add watchdog start to bootcmd Jan Kiszka
@ 2022-10-05 8:33 ` Jan Kiszka
2022-10-05 8:33 ` [PATCH V2 09/13] arm: dts: iot2050: Allow verifying U-Boot proper by SPL Jan Kiszka
` (5 subsequent siblings)
13 siblings, 0 replies; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 8:33 UTC (permalink / raw)
To: U-Boot Mailing List
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 dc4b5f90595..d2cba5acfdd 100644
--- a/include/configs/iot2050.h
+++ b/include/configs/iot2050.h
@@ -56,4 +56,12 @@
#include <configs/ti_armv7_common.h>
+#ifdef CONFIG_ENV_WRITEABLE_LIST
+/* relevant for secure boot with CONFIG_ENV_WRITEABLE_LIST=y */
+#define CONFIG_ENV_FLAGS_LIST_STATIC \
+ "board_uuid:sw,board_name:sw,board_serial:sw,board_a5e:sw," \
+ "mlfb:sw,fw_version:sw,seboot_version:sw," \
+ "eth1addr:mw,eth2addr:mw,watchdog_timeout_ms:dw,boot_targets:sw"
+#endif
+
#endif /* __CONFIG_IOT2050_H */
--
2.35.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH V2 09/13] arm: dts: iot2050: Allow verifying U-Boot proper by SPL
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
` (7 preceding siblings ...)
2022-10-05 8:33 ` [PATCH V2 08/13] iot2050: Add CONFIG_ENV_FLAGS_LIST_STATIC Jan Kiszka
@ 2022-10-05 8:33 ` Jan Kiszka
2022-10-05 8:33 ` [PATCH V2 10/13] iot2050: Add script for signing artifacts Jan Kiszka
` (4 subsequent siblings)
13 siblings, 0 replies; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 8:33 UTC (permalink / raw)
To: U-Boot Mailing List
From: Jan Kiszka <jan.kiszka@siemens.com>
Add hashes and configuration signature stubs to prepare verified boot
of main U-Boot by SPL.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 3ee0842e993..9082a79a034 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -14,6 +14,7 @@
filename = "flash.bin";
pad-byte = <0xff>;
size = <0x8c0000>;
+ allow-repack;
blob-ext@0x000000 {
offset = <0x000000>;
@@ -45,6 +46,9 @@
entry = <0x80800000>;
u-boot-nodtb {
};
+ hash {
+ algo = "sha256";
+ };
};
@fdt-SEQ {
@@ -52,6 +56,9 @@
type = "flat_dt";
arch = "arm64";
compression = "none";
+ hash {
+ algo = "sha256";
+ };
};
#ifdef CONFIG_WDT_K3_RTI_FW_FILE
@@ -64,6 +71,9 @@
filename = CONFIG_WDT_K3_RTI_FW_FILE;
missing-msg = "k3-rti-wdt-firmware";
};
+ hash {
+ algo = "sha256";
+ };
};
#endif
};
@@ -77,10 +87,16 @@
#ifdef CONFIG_WDT_K3_RTI_FW_FILE
loadables = "k3-rti-wdt-firmware";
#endif
+ signature {
+ sign-images = "firmware", "fdt", "loadables";
+ };
};
};
};
+ fdtmap {
+ };
+
/* primary env */
fill@0x680000 {
offset = <0x680000>;
--
2.35.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH V2 10/13] iot2050: Add script for signing artifacts
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
` (8 preceding siblings ...)
2022-10-05 8:33 ` [PATCH V2 09/13] arm: dts: iot2050: Allow verifying U-Boot proper by SPL Jan Kiszka
@ 2022-10-05 8:33 ` Jan Kiszka
2022-10-05 15:58 ` Simon Glass
2022-10-05 8:33 ` [PATCH V2 11/13] arm: dts: iot2050: Optionally embed OTP programming data into image Jan Kiszka
` (3 subsequent siblings)
13 siblings, 1 reply; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 8:33 UTC (permalink / raw)
To: U-Boot Mailing List
From: Jan Kiszka <jan.kiszka@siemens.com>
There are many ways to get a signed firmware for the IOT2050 devices,
namely for the parts under user-control. This script documents one way
of doing it, given a signing key. Augment the board documentation with
the required procedure around it.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
doc/board/siemens/iot2050.rst | 52 +++++++++++++++++++++++++++++++++++
tools/iot2050-sign-fw.sh | 51 ++++++++++++++++++++++++++++++++++
2 files changed, 103 insertions(+)
create mode 100755 tools/iot2050-sign-fw.sh
diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index 26972e20ae9..4e0925c72c9 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -79,3 +79,55 @@ Via external programmer Dediprog SF100 or SF600:
.. code-block:: text
$ dpcmd --vcc 2 -v -u flash.bin
+
+Signing (optional)
+------------------
+
+To enable verified boot for the firmware artifacts after the Siemens-managed
+first-stage loader (seboot_pg*.bin), the following steps need to be taken
+before and after the build:
+
+Generate dtsi holding the public key
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: text
+
+ tools/key2dtsi.py -c -s key.pem public-key.dtsi
+
+This will be used to embed the public key into U-Boot SPL and main so that each
+step can validate signatures of the succeeding one.
+
+Adjust U-Boot configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Enabled at least the following options in U-Boot:
+
+.. code-block:: text
+
+ CONFIG_SPL_FIT_SIGNATURE=y
+ CONFIG_DEVICE_TREE_INCLUDES="/path/to/public-key.dtsi"
+ CONFIG_RSA=y
+
+Note that there are more configuration changes needed in order to lock-down
+the command line and the boot process of U-Boot for secure scenarios. These are
+not in scope here.
+
+Build U-Boot
+^^^^^^^^^^^^
+
+See related section above.
+
+Sign flash.bin
+^^^^^^^^^^^^^^
+
+In the build folder still containing artifacts from step 3, invoke:
+
+.. code-block:: text
+
+ tools/iot2050-sign-fw.sh /path/to/key.pem
+
+Flash signed flash.bin
+^^^^^^^^^^^^^^^^^^^^^^
+
+The signing has happen in-place in flash.bin, thus the flashing procedure
+described above.
diff --git a/tools/iot2050-sign-fw.sh b/tools/iot2050-sign-fw.sh
new file mode 100755
index 00000000000..4d1d79498c2
--- /dev/null
+++ b/tools/iot2050-sign-fw.sh
@@ -0,0 +1,51 @@
+#!/bin/sh
+
+if [ -z "$1" ]; then
+ echo "Usage: $0 KEY"
+ exit 1
+fi
+
+TEMP_X509=$(mktemp XXXXXXXX.temp)
+
+REVISION=${2:-0}
+SHA_VAL=$(openssl dgst -sha512 -hex tispl.bin | sed -e "s/^.*= //g")
+BIN_SIZE=$(stat -c %s tispl.bin)
+
+cat <<EOF >$TEMP_X509
+[ req ]
+distinguished_name = req_distinguished_name
+x509_extensions = v3_ca
+prompt = no
+dirstring_type = nobmp
+
+[ req_distinguished_name ]
+CN = IOT2050 Firmware Signature
+
+[ v3_ca ]
+basicConstraints = CA:true
+1.3.6.1.4.1.294.1.3 = ASN1:SEQUENCE:swrv
+1.3.6.1.4.1.294.1.34 = ASN1:SEQUENCE:sysfw_image_integrity
+
+[ swrv ]
+swrv = INTEGER:$REVISION
+
+[ sysfw_image_integrity ]
+shaType = OID:2.16.840.1.101.3.4.2.3
+shaValue = FORMAT:HEX,OCT:$SHA_VAL
+imageSize = INTEGER:$BIN_SIZE
+EOF
+
+CERT_X509=$(mktemp XXXXXXXX.crt)
+
+openssl req -new -x509 -key $1 -nodes -outform DER -out $CERT_X509 -config $TEMP_X509 -sha512
+cat $CERT_X509 tispl.bin > tispl.bin_signed
+# currently broken in upstream
+#source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed blob@0x180000
+dd if=tispl.bin_signed of=flash.bin bs=$((0x1000)) seek=$((0x180000/0x1000)) conv=notrunc
+
+rm $TEMP_X509 $CERT_X509
+
+tools/mkimage -G $1 -r -o sha256,rsa4096 -F fit@0x380000.fit
+# currently broken in upstream
+#source/tools/binman/binman replace -i flash.bin -f fit@0x380000.fit fit@0x380000
+dd if=fit@0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
--
2.35.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH V2 10/13] iot2050: Add script for signing artifacts
2022-10-05 8:33 ` [PATCH V2 10/13] iot2050: Add script for signing artifacts Jan Kiszka
@ 2022-10-05 15:58 ` Simon Glass
2022-10-05 16:04 ` Jan Kiszka
0 siblings, 1 reply; 26+ messages in thread
From: Simon Glass @ 2022-10-05 15:58 UTC (permalink / raw)
To: Jan Kiszka; +Cc: U-Boot Mailing List
Hi Jan,
On Wed, 5 Oct 2022 at 02:36, Jan Kiszka <jan.kiszka@siemens.com> 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>
> ---
> 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
Please use binman for this. You can create new entry type for your
needs. We want to avoid adding arch-specific scripts with no tests.
Regards,
Simon
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH V2 10/13] iot2050: Add script for signing artifacts
2022-10-05 15:58 ` Simon Glass
@ 2022-10-05 16:04 ` Jan Kiszka
2022-10-05 16:16 ` Jan Kiszka
0 siblings, 1 reply; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 16:04 UTC (permalink / raw)
To: Simon Glass; +Cc: U-Boot Mailing List
On 05.10.22 17:58, Simon Glass wrote:
> Hi Jan,
>
> On Wed, 5 Oct 2022 at 02:36, Jan Kiszka <jan.kiszka@siemens.com> 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>
>> ---
>> 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
>
> Please use binman for this. You can create new entry type for your
> needs. We want to avoid adding arch-specific scripts with no tests.
We will need a script in the foreseeable future, even when binman should
be fixed /wrt replace - see how the certs need to be set up.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH V2 10/13] iot2050: Add script for signing artifacts
2022-10-05 16:04 ` Jan Kiszka
@ 2022-10-05 16:16 ` Jan Kiszka
0 siblings, 0 replies; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 16:16 UTC (permalink / raw)
To: Simon Glass; +Cc: U-Boot Mailing List
On 05.10.22 18:04, Jan Kiszka wrote:
> On 05.10.22 17:58, Simon Glass wrote:
>> Hi Jan,
>>
>> On Wed, 5 Oct 2022 at 02:36, Jan Kiszka <jan.kiszka@siemens.com> 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>
>>> ---
>>> 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
>>
>> Please use binman for this. You can create new entry type for your
>> needs. We want to avoid adding arch-specific scripts with no tests.
>
> We will need a script in the foreseeable future, even when binman should
> be fixed /wrt replace - see how the certs need to be set up.
...and 'binman replace' is still broken:
# source/tools/binman/binman replace -i flash.bin -f tispl.bin_signed blob@0x180000
binman: Error 1 running 'mkimage -t -F /tmp/binman.ip2gc0oy/fit@0x380000.fit': Usage: mkimage -l image
-l ==> list image header information
mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image
-A ==> set architecture to 'arch'
-O ==> set operating system to 'os'
-T ==> set image type to 'type'
-C ==> set compression type 'comp'
-a ==> set load address to 'addr' (hex)
-e ==> set entry point to 'ep' (hex)
-n ==> set image name to 'name'
-d ==> use image data from 'datafile'
-x ==> set XIP (execute in place)
mkimage [-D dtc_options] [-f fit-image.its|-F] fit-image
-D => set options for device tree compiler
-f => input filename for FIT source
Signing / verified boot options: [-k keydir] [-K dtb] [ -c <comment>] [-r]
-k => set directory containing private keys
-K => write public keys to this .dtb file
-c => add comment in signature node
-F => re-sign existing FIT image
-r => mark keys used as 'required' in dtb
mkimage -V ==> print version information and exit
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 26+ messages in thread
* [PATCH V2 11/13] arm: dts: iot2050: Optionally embed OTP programming data into image
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
` (9 preceding siblings ...)
2022-10-05 8:33 ` [PATCH V2 10/13] iot2050: Add script for signing artifacts Jan Kiszka
@ 2022-10-05 8:33 ` Jan Kiszka
2022-10-05 8:33 ` [PATCH V2 12/13] doc: iot2050: Add a note about the watchdog firmware Jan Kiszka
` (2 subsequent siblings)
13 siblings, 0 replies; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 8:33 UTC (permalink / raw)
To: U-Boot Mailing List
From: Jan Kiszka <jan.kiszka@siemens.com>
Use external blob otpcmd.bin to replace the 0xff filled OTP programming
command block to create a firmware image that provisions the OTP on
first boot. This otpcmd.bin is generated from the customer keys using
steps described in the meta-iot2050 integration layer for the device.
Based on original patch by Baocheng Su.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 8 ++++++++
board/siemens/iot2050/Kconfig | 7 +++++++
doc/board/siemens/iot2050.rst | 8 ++++++++
tools/binman/missing-blob-help | 8 ++++++++
4 files changed, 31 insertions(+)
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 9082a79a034..25a22a7b7b8 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -111,10 +111,18 @@
};
/* OTP update command block */
+#if CONFIG_IOT2050_EMBED_OTPCMD
+ blob-ext@0x6c0000 {
+ offset = <0x6c0000>;
+ size = <0x010000>;
+ filename = "otpcmd.bin";
+ missing-msg = "iot2050-otpcmd";
+#else
fill@0x6c0000 {
offset = <0x6c0000>;
size = <0x010000>;
fill-byte = [ff];
+#endif
};
};
};
diff --git a/board/siemens/iot2050/Kconfig b/board/siemens/iot2050/Kconfig
index a2b40881d11..e66b2427d95 100644
--- a/board/siemens/iot2050/Kconfig
+++ b/board/siemens/iot2050/Kconfig
@@ -49,4 +49,11 @@ config IOT2050_BOOT_SWITCH
bool "Disable eMMC boot via USER button (Advanced version only)"
default y
+config IOT2050_EMBED_OTPCMD
+ bool "Embed OTP programming data"
+ help
+ Embed signed OTP programming data 'otpcmd.bin' into the firmware
+ image. This data will be evaluated and executed on first boot of the
+ device.
+
endif
diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index 4e0925c72c9..cb49a0e36bf 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -27,6 +27,14 @@ The following binaries from that source need to be present in the build folder:
- seboot_pg1.bin
- seboot_pg2.bin
+For building an image containing the OTP key provisioning data, below binary
+needs to be present in the build folder:
+
+ - otpcmd.bin
+
+Regarding how to generating this otpcmd.bin, please refer to:
+https://github.com/siemens/meta-iot2050/tree/master/recipes-bsp/secure-boot-otp-provisioning/files/make-otpcmd.sh
+
Building
--------
diff --git a/tools/binman/missing-blob-help b/tools/binman/missing-blob-help
index 5bb8961ce03..7e88cd03954 100644
--- a/tools/binman/missing-blob-help
+++ b/tools/binman/missing-blob-help
@@ -23,6 +23,14 @@ See the documentation for IOT2050 board. Your image is missing SEBoot
which is mandatory for board startup. Prebuilt SEBoot located at
meta-iot2050/tree/master/recipes-bsp/u-boot/files/prebuild/seboot_pg*.bin.
+iot2050-otpcmd:
+See the documentation for IOT2050 board. Your image is missing OTP command data
+block which is used for provisioning the customer keys to the board.
+Please refer to
+meta-iot2050/tree/master/recipes-bsp/secure-boot-otp-provisioning/files/make-otpcmd.sh
+for how to generate this binary. If you are not using secure boot or do not
+intend to provision the keys, disable CONFIG_IOT2050_EMBED_OTPCMD.
+
k3-rti-wdt-firmware:
If CONFIG_WDT_K3_RTI_LOAD_FW is enabled, a firmware image is needed for
the R5F core(s) to trigger the system reset. One possible source is
--
2.35.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH V2 12/13] doc: iot2050: Add a note about the watchdog firmware
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
` (10 preceding siblings ...)
2022-10-05 8:33 ` [PATCH V2 11/13] arm: dts: iot2050: Optionally embed OTP programming data into image Jan Kiszka
@ 2022-10-05 8:33 ` Jan Kiszka
2022-10-05 8:33 ` [PATCH V2 13/13] board: siemens: iot2050: use the named gpio to control the user-button Jan Kiszka
2022-10-26 7:28 ` [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
13 siblings, 0 replies; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 8:33 UTC (permalink / raw)
To: U-Boot Mailing List
From: Jan Kiszka <jan.kiszka@siemens.com>
This is enabled by default, thus should be described as well.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
doc/board/siemens/iot2050.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/doc/board/siemens/iot2050.rst b/doc/board/siemens/iot2050.rst
index cb49a0e36bf..efe94a448a9 100644
--- a/doc/board/siemens/iot2050.rst
+++ b/doc/board/siemens/iot2050.rst
@@ -27,6 +27,10 @@ The following binaries from that source need to be present in the build folder:
- seboot_pg1.bin
- seboot_pg2.bin
+When using the watchdog, a related firmware for the R5 core(s) is needed, e.g.
+https://github.com/siemens/k3-rti-wdt. The name and location of the image is
+configured via CONFIG_WDT_K3_RTI_FW_FILE.
+
For building an image containing the OTP key provisioning data, below binary
needs to be present in the build folder:
--
2.35.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* [PATCH V2 13/13] board: siemens: iot2050: use the named gpio to control the user-button
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
` (11 preceding siblings ...)
2022-10-05 8:33 ` [PATCH V2 12/13] doc: iot2050: Add a note about the watchdog firmware Jan Kiszka
@ 2022-10-05 8:33 ` Jan Kiszka
2022-10-26 7:28 ` [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
13 siblings, 0 replies; 26+ messages in thread
From: Jan Kiszka @ 2022-10-05 8:33 UTC (permalink / raw)
To: U-Boot Mailing List
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 2be5d1eefc3..be30b9c4d18 100644
--- a/board/siemens/iot2050/board.c
+++ b/board/siemens/iot2050/board.c
@@ -183,7 +183,7 @@ static bool user_button_pressed(void)
memset(&gpio, 0, sizeof(gpio));
- if (dm_gpio_lookup_name("25", &gpio) < 0 ||
+ if (dm_gpio_lookup_name("gpio@42110000_25", &gpio) < 0 ||
dm_gpio_request(&gpio, "USER button") < 0 ||
dm_gpio_set_dir_flags(&gpio, GPIOD_IS_IN) < 0)
return false;
--
2.35.3
^ permalink raw reply related [flat|nested] 26+ messages in thread* Re: [PATCH V2 00/13] IOT2050-related enhancements
2022-10-05 8:33 [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
` (12 preceding siblings ...)
2022-10-05 8:33 ` [PATCH V2 13/13] board: siemens: iot2050: use the named gpio to control the user-button Jan Kiszka
@ 2022-10-26 7:28 ` Jan Kiszka
2022-10-26 13:54 ` Tom Rini
13 siblings, 1 reply; 26+ messages in thread
From: Jan Kiszka @ 2022-10-26 7:28 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: chao zeng, Joe Hershberger, Marek Vasut, Su Baocheng,
Simon Glass, Tom Rini
On 05.10.22 10:33, Jan Kiszka wrote:
> (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
>
> There are also some generic extensions in this series which are
> dependencies for the above:
>
> - env: Complete generic support for writable list
> - env: Couple networking-related variable flags to CONFIG_NET (repost)
> - tools: Add script for converting public key into device tree include
>
> 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. But that requires some more rework first.
>
Any remaining questions/remarks for this series? Asking also as we would
like to move forward with upstreaming that M.2 support which depends on
this one here.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [PATCH V2 00/13] IOT2050-related enhancements
2022-10-26 7:28 ` [PATCH V2 00/13] IOT2050-related enhancements Jan Kiszka
@ 2022-10-26 13:54 ` Tom Rini
2022-10-26 14:03 ` Marek Vasut
0 siblings, 1 reply; 26+ messages in thread
From: Tom Rini @ 2022-10-26 13:54 UTC (permalink / raw)
To: Jan Kiszka, Marek Vasut
Cc: U-Boot Mailing List, chao zeng, Su Baocheng, Joe Hershberger,
Simon Glass
[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]
On Wed, Oct 26, 2022 at 09:28:09AM +0200, Jan Kiszka wrote:
> On 05.10.22 10:33, Jan Kiszka wrote:
> > (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
> >
> > There are also some generic extensions in this series which are
> > dependencies for the above:
> >
> > - env: Complete generic support for writable list
> > - env: Couple networking-related variable flags to CONFIG_NET (repost)
> > - tools: Add script for converting public key into device tree include
> >
> > 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. But that requires some more rework first.
>
> Any remaining questions/remarks for this series? Asking also as we would
> like to move forward with upstreaming that M.2 support which depends on
> this one here.
Marek, I believe you had concerns about the environment side of v1 here,
is v2 more to your liking? Thanks!
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH V2 00/13] IOT2050-related enhancements
2022-10-26 13:54 ` Tom Rini
@ 2022-10-26 14:03 ` Marek Vasut
2022-10-26 15:55 ` Jan Kiszka
0 siblings, 1 reply; 26+ messages in thread
From: Marek Vasut @ 2022-10-26 14:03 UTC (permalink / raw)
To: Tom Rini, Jan Kiszka
Cc: U-Boot Mailing List, chao zeng, Su Baocheng, Joe Hershberger,
Simon Glass
On 10/26/22 15:54, Tom Rini wrote:
> On Wed, Oct 26, 2022 at 09:28:09AM +0200, Jan Kiszka wrote:
>> On 05.10.22 10:33, Jan Kiszka wrote:
>>> (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
>>>
>>> There are also some generic extensions in this series which are
>>> dependencies for the above:
>>>
>>> - env: Complete generic support for writable list
>>> - env: Couple networking-related variable flags to CONFIG_NET (repost)
>>> - tools: Add script for converting public key into device tree include
>>>
>>> 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. But that requires some more rework first.
>>
>> Any remaining questions/remarks for this series? Asking also as we would
>> like to move forward with upstreaming that M.2 support which depends on
>> this one here.
>
> Marek, I believe you had concerns about the environment side of v1 here,
> is v2 more to your liking? Thanks!
Nothing changed in V2 in that aspect as far as I can tell.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH V2 00/13] IOT2050-related enhancements
2022-10-26 14:03 ` Marek Vasut
@ 2022-10-26 15:55 ` Jan Kiszka
2022-10-26 21:02 ` Marek Vasut
0 siblings, 1 reply; 26+ messages in thread
From: Jan Kiszka @ 2022-10-26 15:55 UTC (permalink / raw)
To: Marek Vasut, Tom Rini
Cc: U-Boot Mailing List, chao zeng, Su Baocheng, Joe Hershberger,
Simon Glass
On 26.10.22 16:03, Marek Vasut wrote:
> On 10/26/22 15:54, Tom Rini wrote:
>> On Wed, Oct 26, 2022 at 09:28:09AM +0200, Jan Kiszka wrote:
>>> On 05.10.22 10:33, Jan Kiszka wrote:
>>>> (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
>>>>
>>>> There are also some generic extensions in this series which are
>>>> dependencies for the above:
>>>>
>>>> - env: Complete generic support for writable list
>>>> - env: Couple networking-related variable flags to CONFIG_NET
>>>> (repost)
>>>> - tools: Add script for converting public key into device tree
>>>> include
>>>>
>>>> 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. But that requires some more rework first.
>>>
>>> Any remaining questions/remarks for this series? Asking also as we would
>>> like to move forward with upstreaming that M.2 support which depends on
>>> this one here.
>>
>> Marek, I believe you had concerns about the environment side of v1 here,
>> is v2 more to your liking? Thanks!
>
> Nothing changed in V2 in that aspect as far as I can tell.
Well... patch 1 changes significantly and is much less invasive - as we
discussed around v1. Can you please update your comments then? I'm lost
now what else you would like to see changed.
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH V2 00/13] IOT2050-related enhancements
2022-10-26 15:55 ` Jan Kiszka
@ 2022-10-26 21:02 ` Marek Vasut
2022-10-27 4:32 ` Jan Kiszka
0 siblings, 1 reply; 26+ messages in thread
From: Marek Vasut @ 2022-10-26 21:02 UTC (permalink / raw)
To: Jan Kiszka, Tom Rini
Cc: U-Boot Mailing List, chao zeng, Su Baocheng, Joe Hershberger,
Simon Glass
On 10/26/22 17:55, Jan Kiszka wrote:
> On 26.10.22 16:03, Marek Vasut wrote:
>> On 10/26/22 15:54, Tom Rini wrote:
>>> On Wed, Oct 26, 2022 at 09:28:09AM +0200, Jan Kiszka wrote:
>>>> On 05.10.22 10:33, Jan Kiszka wrote:
>>>>> (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
>>>>>
>>>>> There are also some generic extensions in this series which are
>>>>> dependencies for the above:
>>>>>
>>>>> - env: Complete generic support for writable list
>>>>> - env: Couple networking-related variable flags to CONFIG_NET
>>>>> (repost)
>>>>> - tools: Add script for converting public key into device tree
>>>>> include
>>>>>
>>>>> 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. But that requires some more rework first.
>>>>
>>>> Any remaining questions/remarks for this series? Asking also as we would
>>>> like to move forward with upstreaming that M.2 support which depends on
>>>> this one here.
>>>
>>> Marek, I believe you had concerns about the environment side of v1 here,
>>> is v2 more to your liking? Thanks!
>>
>> Nothing changed in V2 in that aspect as far as I can tell.
>
> Well... patch 1 changes significantly and is much less invasive - as we
> discussed around v1. Can you please update your comments then? I'm lost
> now what else you would like to see changed.
IIRC my comment was that env prio ordering is board specific and so it
should be in board/ , wasn't it ?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [PATCH V2 00/13] IOT2050-related enhancements
2022-10-26 21:02 ` Marek Vasut
@ 2022-10-27 4:32 ` Jan Kiszka
0 siblings, 0 replies; 26+ messages in thread
From: Jan Kiszka @ 2022-10-27 4:32 UTC (permalink / raw)
To: Marek Vasut, Tom Rini
Cc: U-Boot Mailing List, chao zeng, Su Baocheng, Joe Hershberger,
Simon Glass
On 26.10.22 23:02, Marek Vasut wrote:
> On 10/26/22 17:55, Jan Kiszka wrote:
>> On 26.10.22 16:03, Marek Vasut wrote:
>>> On 10/26/22 15:54, Tom Rini wrote:
>>>> On Wed, Oct 26, 2022 at 09:28:09AM +0200, Jan Kiszka wrote:
>>>>> On 05.10.22 10:33, Jan Kiszka wrote:
>>>>>> (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
>>>>>>
>>>>>> There are also some generic extensions in this series which are
>>>>>> dependencies for the above:
>>>>>>
>>>>>> - env: Complete generic support for writable list
>>>>>> - env: Couple networking-related variable flags to CONFIG_NET
>>>>>> (repost)
>>>>>> - tools: Add script for converting public key into device tree
>>>>>> include
>>>>>>
>>>>>> 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. But that requires some more rework first.
>>>>>
>>>>> Any remaining questions/remarks for this series? Asking also as we
>>>>> would
>>>>> like to move forward with upstreaming that M.2 support which
>>>>> depends on
>>>>> this one here.
>>>>
>>>> Marek, I believe you had concerns about the environment side of v1
>>>> here,
>>>> is v2 more to your liking? Thanks!
>>>
>>> Nothing changed in V2 in that aspect as far as I can tell.
>>
>> Well... patch 1 changes significantly and is much less invasive - as we
>> discussed around v1. Can you please update your comments then? I'm lost
>> now what else you would like to see changed.
>
> IIRC my comment was that env prio ordering is board specific and so it
> should be in board/ , wasn't it ?
Please re-read the old discussion to its end. It ended with how to make
the approach less invasive.
The whole patch is about making it no longer board specific - because it
isn't for the variable protection scenario under secure boot. As I
pointed out in that thread, we have multiple downstream boards using
exactly this very same pattern already.
Thanks,
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 26+ messages in thread