| Message ID | cover.1664958832.git.jan.kiszka@siemens.com |
|---|---|
| Headers | show |
| Series | IOT2050-related enhancements | expand |
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
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!
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.
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
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 ?
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
(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. Jan CC: chao zeng <chao.zeng@siemens.com> CC: Joe Hershberger <joe.hershberger@ni.com> CC: Marek Vasut <marex@denx.de> CC: Su Baocheng <baocheng.su@siemens.com> Jan Kiszka (10): env: Complete generic support for writable list env: Couple networking-related variable flags to CONFIG_NET tools: Add script for converting public key into device tree include 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 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 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} | 7 +- ...ot2050_defconfig => iot2050_pg2_defconfig} | 9 +- doc/board/siemens/iot2050.rst | 79 ++++++++++- env/Kconfig | 2 + env/env.c | 22 +++ env/flags.c | 10 +- include/configs/iot2050.h | 17 +++ include/env_flags.h | 4 +- tools/binman/missing-blob-help | 14 +- tools/iot2050-sign-fw.sh | 51 +++++++ tools/key2dtsi.py | 64 +++++++++ 14 files changed, 334 insertions(+), 131 deletions(-) copy configs/{iot2050_defconfig => iot2050_pg1_defconfig} (94%) rename configs/{iot2050_defconfig => iot2050_pg2_defconfig} (92%) create mode 100755 tools/iot2050-sign-fw.sh create mode 100755 tools/key2dtsi.py