| Message ID | 20240217160244.1320482-1-dario.binacchi@amarulasolutions.com |
|---|---|
| Headers | show |
| Series | Add support for AM62x-SK HS-FS devices | expand |
Hi Dario! On Sat, 2024-02-17 at 17:02 +0100, Dario Binacchi wrote: > This series, which in my humble opinion, should have been immediately > considered to correct the compilation errors in case of HS-FS devcies, has > seen an increase in patches in version 4 to remove the ti-k3-image-gen I wasn't aware of the preceeding versions, but... > package thanks to Binman. Additionally, it shares some modifications and > views on how to implement certain changes with the series > https://patchwork.ozlabs.org/project/buildroot/list/?series=394840. > Therefore, I think it is necessary not to run them in parallel but to decide > whether to merge one before the other or to consider a single series where > the patches can be coherent with each other. I am available for both solutions. > Let me know. ... as the broken HS-FS went unnoticed, seems there is no rush to fix the build now? I'd vote for a combined series, because yours and Romains do overlap here and there, but I personally would pick different parts from different series. I'd not introduce secdev package unless absolutely necessary, and I actually build HS-FS images with yocto with custom keys and using upstream U-Boot binman alone, so maybe I miss something, but I don't see the package as required. From my side I can offer testing on SK-AM62x variants, both GP and HS-FS. I will definitely test your v4 because in contrast to Romain's U-Boot v2024.01 bump yours may actually boot...
Hi Dario, On Sat, 2024-02-17 at 17:02 +0100, Dario Binacchi wrote: > The SK-AM62B-P1 is the newest version of SK-AM62 which includes > high-security field-securable (HS-FS) silicon to optionally customize keys > and encryption for security applications. > This requires enabling the BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS option, > which, however, was buggy. This series fixes the errors and bumps the Linux > kernel and U-Boot required for such a new device. > > This series, which in my humble opinion, should have been immediately > considered to correct the compilation errors in case of HS-FS devcies, has > seen an increase in patches in version 4 to remove the ti-k3-image-gen > package thanks to Binman. Additionally, it shares some modifications and > views on how to implement certain changes with the series > https://patchwork.ozlabs.org/project/buildroot/list/?series=394840. > Therefore, I think it is necessary not to run them in parallel but to decide > whether to merge one before the other or to consider a single series where > the patches can be coherent with each other. I am available for both solutions. > Let me know. > > Dario Binacchi (20): > configs/ti_am62x_sk_defconfig: fix BR2_TARGET_OPTEE_OS_PLATFORM > setting > configs/ti_am64x_sk_defconfig: fix BR2_TARGET_OPTEE_OS_PLATFORM > setting > configs/ti_am62x_sk_defconfig: explicitly set the ti-k3-r5-loader > version > configs/ti_am64x_sk_defconfig: explicitly set the ti-k3-r5-loader > version > boot/ti-k3-r5-loader: bump to version 2024.01 > boot/ti-k3-core-secdev: new package > boot/ti-k3-image-gen: manage HS hardware > package/python-jsonschema: add host variant > package/python-attrs: add host variant > package/python-referencing: add host variant > package/python-rpds-py: add host variant > package/python-jsonschema-specifications: add host variant > boot/ti-k3-r5-loader: set binman environment > boot/uboot: set BINMAN_INDIRS for TI K3 DM > configs/ti_am62x_sk_defconfig: bump U-Boot version to 2024.01 > configs/ti_am62x_sk_defconfig: bump Linux version to 6.6.1 > boot: move ti-k3-* packages to 'ti-k3' directory > boot/ti-k3: move TI_K3_{SECTYPE,SOC} out of the image-gen scope > boot/ti-k3/ti-k3-r5-loader: install tiboot3.bin > configs/ti_am62x_sk_defconfig: don't use ti-k3-image-gen anymore the series: - builds and starts on SK-AM62B (HS-FS) - builds for am62x GP Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Hello Dario, Le 17/02/2024 à 17:02, Dario Binacchi a écrit : > The SK-AM62B-P1 is the newest version of SK-AM62 which includes > high-security field-securable (HS-FS) silicon to optionally customize keys > and encryption for security applications. > This requires enabling the BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS option, > which, however, was buggy. This series fixes the errors and bumps the Linux > kernel and U-Boot required for such a new device. > > This series, which in my humble opinion, should have been immediately > considered to correct the compilation errors in case of HS-FS devcies, has > seen an increase in patches in version 4 to remove the ti-k3-image-gen > package thanks to Binman. Additionally, it shares some modifications and > views on how to implement certain changes with the series > https://patchwork.ozlabs.org/project/buildroot/list/?series=394840. > Therefore, I think it is necessary not to run them in parallel but to decide > whether to merge one before the other or to consider a single series where > the patches can be coherent with each other. I am available for both solutions. > Let me know. Thanks for this new version. I beleive both series should be merged into one since we want to follow u-boot switch to binman, add more TI K3 SoC support and keeping exising am62x ans am64x working in GP or HS/HS-FS. My main concern is to avoid adding a new package for a tool that is already deprecated ti-k3-image-gen (not sure if ti-k3-core-secdev is really deprecated) [1]. Also the topic is not only "AM62x-SK HS-FS devices" but "TI K3 HS-FS devices". [1] http://lists.busybox.net/pipermail/buildroot/2024-February/685820.html Best regards, Romain > > Dario Binacchi (20): > configs/ti_am62x_sk_defconfig: fix BR2_TARGET_OPTEE_OS_PLATFORM > setting > configs/ti_am64x_sk_defconfig: fix BR2_TARGET_OPTEE_OS_PLATFORM > setting > configs/ti_am62x_sk_defconfig: explicitly set the ti-k3-r5-loader > version > configs/ti_am64x_sk_defconfig: explicitly set the ti-k3-r5-loader > version > boot/ti-k3-r5-loader: bump to version 2024.01 > boot/ti-k3-core-secdev: new package > boot/ti-k3-image-gen: manage HS hardware > package/python-jsonschema: add host variant > package/python-attrs: add host variant > package/python-referencing: add host variant > package/python-rpds-py: add host variant > package/python-jsonschema-specifications: add host variant > boot/ti-k3-r5-loader: set binman environment > boot/uboot: set BINMAN_INDIRS for TI K3 DM > configs/ti_am62x_sk_defconfig: bump U-Boot version to 2024.01 > configs/ti_am62x_sk_defconfig: bump Linux version to 6.6.1 > boot: move ti-k3-* packages to 'ti-k3' directory > boot/ti-k3: move TI_K3_{SECTYPE,SOC} out of the image-gen scope > boot/ti-k3/ti-k3-r5-loader: install tiboot3.bin > configs/ti_am62x_sk_defconfig: don't use ti-k3-image-gen anymore > > DEVELOPERS | 1 + > board/ti/am62x-sk/genimage.cfg | 7 +- > board/ti/am62x-sk/post-build.sh | 49 ++++++++++++ > board/ti/am62x-sk/post-image.sh | 5 ++ > boot/Config.in | 4 +- > boot/ti-k3-image-gen/Config.in | 77 ------------------- > boot/ti-k3/Config.in | 59 ++++++++++++++ > boot/ti-k3/common.mk | 1 + > .../{ => ti-k3}/ti-k3-boot-firmware/Config.in | 0 > .../ti-k3-boot-firmware.hash | 0 > .../ti-k3-boot-firmware.mk | 0 > boot/ti-k3/ti-k3-core-secdev/Config.in | 9 +++ > .../ti-k3-core-secdev/ti-k3-core-secdev.hash | 3 + > .../ti-k3-core-secdev/ti-k3-core-secdev.mk | 22 ++++++ > boot/ti-k3/ti-k3-image-gen/Config.in | 25 ++++++ > .../ti-k3-image-gen/ti-k3-image-gen.hash | 0 > .../ti-k3-image-gen/ti-k3-image-gen.mk | 20 ++++- > boot/{ => ti-k3}/ti-k3-r5-loader/Config.in | 4 +- > .../ti-k3-r5-loader/ti-k3-r5-loader.hash | 2 +- > .../ti-k3-r5-loader/ti-k3-r5-loader.mk | 16 +++- > boot/uboot/Config.in | 7 +- > boot/uboot/uboot.mk | 3 +- > configs/ti_am62x_sk_defconfig | 23 +++--- > configs/ti_am64x_sk_defconfig | 8 +- > package/python-attrs/python-attrs.mk | 6 ++ > .../python-jsonschema-specifications.mk | 5 ++ > .../python-jsonschema/python-jsonschema.mk | 6 ++ > .../python-referencing/python-referencing.mk | 5 ++ > package/python-rpds-py/python-rpds-py.mk | 1 + > 29 files changed, 263 insertions(+), 105 deletions(-) > create mode 100755 board/ti/am62x-sk/post-build.sh > create mode 100755 board/ti/am62x-sk/post-image.sh > delete mode 100644 boot/ti-k3-image-gen/Config.in > create mode 100644 boot/ti-k3/Config.in > create mode 100644 boot/ti-k3/common.mk > rename boot/{ => ti-k3}/ti-k3-boot-firmware/Config.in (100%) > rename boot/{ => ti-k3}/ti-k3-boot-firmware/ti-k3-boot-firmware.hash (100%) > rename boot/{ => ti-k3}/ti-k3-boot-firmware/ti-k3-boot-firmware.mk (100%) > create mode 100644 boot/ti-k3/ti-k3-core-secdev/Config.in > create mode 100644 boot/ti-k3/ti-k3-core-secdev/ti-k3-core-secdev.hash > create mode 100644 boot/ti-k3/ti-k3-core-secdev/ti-k3-core-secdev.mk > create mode 100644 boot/ti-k3/ti-k3-image-gen/Config.in > rename boot/{ => ti-k3}/ti-k3-image-gen/ti-k3-image-gen.hash (100%) > rename boot/{ => ti-k3}/ti-k3-image-gen/ti-k3-image-gen.mk (67%) > rename boot/{ => ti-k3}/ti-k3-r5-loader/Config.in (97%) > rename boot/{ => ti-k3}/ti-k3-r5-loader/ti-k3-r5-loader.hash (54%) > rename boot/{ => ti-k3}/ti-k3-r5-loader/ti-k3-r5-loader.mk (85%) >
Hello Alexander, Le 17/02/2024 à 18:40, Alexander Sverdlin a écrit : > Hi Dario! > > On Sat, 2024-02-17 at 17:02 +0100, Dario Binacchi wrote: >> This series, which in my humble opinion, should have been immediately >> considered to correct the compilation errors in case of HS-FS devcies, has >> seen an increase in patches in version 4 to remove the ti-k3-image-gen > > I wasn't aware of the preceeding versions, but... > >> package thanks to Binman. Additionally, it shares some modifications and >> views on how to implement certain changes with the series >> https://patchwork.ozlabs.org/project/buildroot/list/?series=394840. >> Therefore, I think it is necessary not to run them in parallel but to decide >> whether to merge one before the other or to consider a single series where >> the patches can be coherent with each other. I am available for both solutions. >> Let me know. > > ... as the broken HS-FS went unnoticed, seems there is no rush to fix the > build now? I'd vote for a combined series, because yours and Romains do > overlap here and there, but I personally would pick different parts from > different series. I'd not introduce secdev package unless absolutely > necessary, and I actually build HS-FS images with yocto with custom keys > and using upstream U-Boot binman alone, so maybe I miss something, but > I don't see the package as required. > > From my side I can offer testing on SK-AM62x variants, both GP and HS-FS. > I will definitely test your v4 because in contrast to Romain's U-Boot > v2024.01 bump yours may actually boot... > Can you merge Dario changes (extlinux.conf and post-build.sh) and try again? Best regards, Romain
Hi Romain On Mon, Feb 19, 2024 at 10:30 AM Romain Naour <romain.naour@smile.fr> wrote: > > Hello Dario, > > Le 17/02/2024 à 17:02, Dario Binacchi a écrit : > > The SK-AM62B-P1 is the newest version of SK-AM62 which includes > > high-security field-securable (HS-FS) silicon to optionally customize keys > > and encryption for security applications. > > This requires enabling the BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS option, > > which, however, was buggy. This series fixes the errors and bumps the Linux > > kernel and U-Boot required for such a new device. > > > > This series, which in my humble opinion, should have been immediately > > considered to correct the compilation errors in case of HS-FS devcies, has > > seen an increase in patches in version 4 to remove the ti-k3-image-gen > > package thanks to Binman. Additionally, it shares some modifications and > > views on how to implement certain changes with the series > > https://patchwork.ozlabs.org/project/buildroot/list/?series=394840. > > Therefore, I think it is necessary not to run them in parallel but to decide > > whether to merge one before the other or to consider a single series where > > the patches can be coherent with each other. I am available for both solutions. > > Let me know. > > Thanks for this new version. I beleive both series should be merged into one > since we want to follow u-boot switch to binman, add more TI K3 SoC support and > keeping exising am62x ans am64x working in GP or HS/HS-FS. > Because the Dario patchset was sent before (end of November), it's reasonable to review and adjust that one and apply your changes for ti_j721e_sk on top of it. It think that is a standard way to make people happy about their work and contribution. Michael > My main concern is to avoid adding a new package for a tool that is already > deprecated ti-k3-image-gen (not sure if ti-k3-core-secdev is really deprecated) [1]. > > Also the topic is not only "AM62x-SK HS-FS devices" but "TI K3 HS-FS devices". > > [1] http://lists.busybox.net/pipermail/buildroot/2024-February/685820.html > > Best regards, > Romain > > > > > Dario Binacchi (20): > > configs/ti_am62x_sk_defconfig: fix BR2_TARGET_OPTEE_OS_PLATFORM > > setting > > configs/ti_am64x_sk_defconfig: fix BR2_TARGET_OPTEE_OS_PLATFORM > > setting > > configs/ti_am62x_sk_defconfig: explicitly set the ti-k3-r5-loader > > version > > configs/ti_am64x_sk_defconfig: explicitly set the ti-k3-r5-loader > > version > > boot/ti-k3-r5-loader: bump to version 2024.01 > > boot/ti-k3-core-secdev: new package > > boot/ti-k3-image-gen: manage HS hardware > > package/python-jsonschema: add host variant > > package/python-attrs: add host variant > > package/python-referencing: add host variant > > package/python-rpds-py: add host variant > > package/python-jsonschema-specifications: add host variant > > boot/ti-k3-r5-loader: set binman environment > > boot/uboot: set BINMAN_INDIRS for TI K3 DM > > configs/ti_am62x_sk_defconfig: bump U-Boot version to 2024.01 > > configs/ti_am62x_sk_defconfig: bump Linux version to 6.6.1 > > boot: move ti-k3-* packages to 'ti-k3' directory > > boot/ti-k3: move TI_K3_{SECTYPE,SOC} out of the image-gen scope > > boot/ti-k3/ti-k3-r5-loader: install tiboot3.bin > > configs/ti_am62x_sk_defconfig: don't use ti-k3-image-gen anymore > > > > DEVELOPERS | 1 + > > board/ti/am62x-sk/genimage.cfg | 7 +- > > board/ti/am62x-sk/post-build.sh | 49 ++++++++++++ > > board/ti/am62x-sk/post-image.sh | 5 ++ > > boot/Config.in | 4 +- > > boot/ti-k3-image-gen/Config.in | 77 ------------------- > > boot/ti-k3/Config.in | 59 ++++++++++++++ > > boot/ti-k3/common.mk | 1 + > > .../{ => ti-k3}/ti-k3-boot-firmware/Config.in | 0 > > .../ti-k3-boot-firmware.hash | 0 > > .../ti-k3-boot-firmware.mk | 0 > > boot/ti-k3/ti-k3-core-secdev/Config.in | 9 +++ > > .../ti-k3-core-secdev/ti-k3-core-secdev.hash | 3 + > > .../ti-k3-core-secdev/ti-k3-core-secdev.mk | 22 ++++++ > > boot/ti-k3/ti-k3-image-gen/Config.in | 25 ++++++ > > .../ti-k3-image-gen/ti-k3-image-gen.hash | 0 > > .../ti-k3-image-gen/ti-k3-image-gen.mk | 20 ++++- > > boot/{ => ti-k3}/ti-k3-r5-loader/Config.in | 4 +- > > .../ti-k3-r5-loader/ti-k3-r5-loader.hash | 2 +- > > .../ti-k3-r5-loader/ti-k3-r5-loader.mk | 16 +++- > > boot/uboot/Config.in | 7 +- > > boot/uboot/uboot.mk | 3 +- > > configs/ti_am62x_sk_defconfig | 23 +++--- > > configs/ti_am64x_sk_defconfig | 8 +- > > package/python-attrs/python-attrs.mk | 6 ++ > > .../python-jsonschema-specifications.mk | 5 ++ > > .../python-jsonschema/python-jsonschema.mk | 6 ++ > > .../python-referencing/python-referencing.mk | 5 ++ > > package/python-rpds-py/python-rpds-py.mk | 1 + > > 29 files changed, 263 insertions(+), 105 deletions(-) > > create mode 100755 board/ti/am62x-sk/post-build.sh > > create mode 100755 board/ti/am62x-sk/post-image.sh > > delete mode 100644 boot/ti-k3-image-gen/Config.in > > create mode 100644 boot/ti-k3/Config.in > > create mode 100644 boot/ti-k3/common.mk > > rename boot/{ => ti-k3}/ti-k3-boot-firmware/Config.in (100%) > > rename boot/{ => ti-k3}/ti-k3-boot-firmware/ti-k3-boot-firmware.hash (100%) > > rename boot/{ => ti-k3}/ti-k3-boot-firmware/ti-k3-boot-firmware.mk (100%) > > create mode 100644 boot/ti-k3/ti-k3-core-secdev/Config.in > > create mode 100644 boot/ti-k3/ti-k3-core-secdev/ti-k3-core-secdev.hash > > create mode 100644 boot/ti-k3/ti-k3-core-secdev/ti-k3-core-secdev.mk > > create mode 100644 boot/ti-k3/ti-k3-image-gen/Config.in > > rename boot/{ => ti-k3}/ti-k3-image-gen/ti-k3-image-gen.hash (100%) > > rename boot/{ => ti-k3}/ti-k3-image-gen/ti-k3-image-gen.mk (67%) > > rename boot/{ => ti-k3}/ti-k3-r5-loader/Config.in (97%) > > rename boot/{ => ti-k3}/ti-k3-r5-loader/ti-k3-r5-loader.hash (54%) > > rename boot/{ => ti-k3}/ti-k3-r5-loader/ti-k3-r5-loader.mk (85%) > > >
Hello Michael, Le 19/02/2024 à 12:02, Michael Nazzareno Trimarchi a écrit : > Hi Romain > > On Mon, Feb 19, 2024 at 10:30 AM Romain Naour <romain.naour@smile.fr> wrote: >> >> Hello Dario, >> >> Le 17/02/2024 à 17:02, Dario Binacchi a écrit : >>> The SK-AM62B-P1 is the newest version of SK-AM62 which includes >>> high-security field-securable (HS-FS) silicon to optionally customize keys >>> and encryption for security applications. >>> This requires enabling the BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS option, >>> which, however, was buggy. This series fixes the errors and bumps the Linux >>> kernel and U-Boot required for such a new device. >>> >>> This series, which in my humble opinion, should have been immediately >>> considered to correct the compilation errors in case of HS-FS devcies, has >>> seen an increase in patches in version 4 to remove the ti-k3-image-gen >>> package thanks to Binman. Additionally, it shares some modifications and >>> views on how to implement certain changes with the series >>> https://patchwork.ozlabs.org/project/buildroot/list/?series=394840. >>> Therefore, I think it is necessary not to run them in parallel but to decide >>> whether to merge one before the other or to consider a single series where >>> the patches can be coherent with each other. I am available for both solutions. >>> Let me know. >> >> Thanks for this new version. I beleive both series should be merged into one >> since we want to follow u-boot switch to binman, add more TI K3 SoC support and >> keeping exising am62x ans am64x working in GP or HS/HS-FS. >> > > Because the Dario patchset was sent before (end of November), it's > reasonable to review and adjust that one > and apply your changes for ti_j721e_sk on top of it. It think that is > a standard way to make people happy about > their work and contribution. Actually, the two series are about the same topic: TI K3 SoC support (GP, HS, HS-FS) not only AM62x-SK HS-FS devices But due to the complexity of the BSP, the boot flow (4 way to boot!) and the switch from custom tool to binman... this series is really difficult to review without having a good understanding of TI K3 architecture peculiarity and having one of each TI evaluation boards 🙂 The series (based on Dario's work) about ti_j721e_sk suggested to remove TI custom tools replaced by binman along with other improvements. I'll way for v5 and rebase the ti_j721e_sk on top of it. Best regards, Romain > > Michael > >> My main concern is to avoid adding a new package for a tool that is already >> deprecated ti-k3-image-gen (not sure if ti-k3-core-secdev is really deprecated) [1]. >> >> Also the topic is not only "AM62x-SK HS-FS devices" but "TI K3 HS-FS devices". >> >> [1] http://lists.busybox.net/pipermail/buildroot/2024-February/685820.html >> >> Best regards, >> Romain >> >>> >>> Dario Binacchi (20): >>> configs/ti_am62x_sk_defconfig: fix BR2_TARGET_OPTEE_OS_PLATFORM >>> setting >>> configs/ti_am64x_sk_defconfig: fix BR2_TARGET_OPTEE_OS_PLATFORM >>> setting >>> configs/ti_am62x_sk_defconfig: explicitly set the ti-k3-r5-loader >>> version >>> configs/ti_am64x_sk_defconfig: explicitly set the ti-k3-r5-loader >>> version >>> boot/ti-k3-r5-loader: bump to version 2024.01 >>> boot/ti-k3-core-secdev: new package >>> boot/ti-k3-image-gen: manage HS hardware >>> package/python-jsonschema: add host variant >>> package/python-attrs: add host variant >>> package/python-referencing: add host variant >>> package/python-rpds-py: add host variant >>> package/python-jsonschema-specifications: add host variant >>> boot/ti-k3-r5-loader: set binman environment >>> boot/uboot: set BINMAN_INDIRS for TI K3 DM >>> configs/ti_am62x_sk_defconfig: bump U-Boot version to 2024.01 >>> configs/ti_am62x_sk_defconfig: bump Linux version to 6.6.1 >>> boot: move ti-k3-* packages to 'ti-k3' directory >>> boot/ti-k3: move TI_K3_{SECTYPE,SOC} out of the image-gen scope >>> boot/ti-k3/ti-k3-r5-loader: install tiboot3.bin >>> configs/ti_am62x_sk_defconfig: don't use ti-k3-image-gen anymore >>> >>> DEVELOPERS | 1 + >>> board/ti/am62x-sk/genimage.cfg | 7 +- >>> board/ti/am62x-sk/post-build.sh | 49 ++++++++++++ >>> board/ti/am62x-sk/post-image.sh | 5 ++ >>> boot/Config.in | 4 +- >>> boot/ti-k3-image-gen/Config.in | 77 ------------------- >>> boot/ti-k3/Config.in | 59 ++++++++++++++ >>> boot/ti-k3/common.mk | 1 + >>> .../{ => ti-k3}/ti-k3-boot-firmware/Config.in | 0 >>> .../ti-k3-boot-firmware.hash | 0 >>> .../ti-k3-boot-firmware.mk | 0 >>> boot/ti-k3/ti-k3-core-secdev/Config.in | 9 +++ >>> .../ti-k3-core-secdev/ti-k3-core-secdev.hash | 3 + >>> .../ti-k3-core-secdev/ti-k3-core-secdev.mk | 22 ++++++ >>> boot/ti-k3/ti-k3-image-gen/Config.in | 25 ++++++ >>> .../ti-k3-image-gen/ti-k3-image-gen.hash | 0 >>> .../ti-k3-image-gen/ti-k3-image-gen.mk | 20 ++++- >>> boot/{ => ti-k3}/ti-k3-r5-loader/Config.in | 4 +- >>> .../ti-k3-r5-loader/ti-k3-r5-loader.hash | 2 +- >>> .../ti-k3-r5-loader/ti-k3-r5-loader.mk | 16 +++- >>> boot/uboot/Config.in | 7 +- >>> boot/uboot/uboot.mk | 3 +- >>> configs/ti_am62x_sk_defconfig | 23 +++--- >>> configs/ti_am64x_sk_defconfig | 8 +- >>> package/python-attrs/python-attrs.mk | 6 ++ >>> .../python-jsonschema-specifications.mk | 5 ++ >>> .../python-jsonschema/python-jsonschema.mk | 6 ++ >>> .../python-referencing/python-referencing.mk | 5 ++ >>> package/python-rpds-py/python-rpds-py.mk | 1 + >>> 29 files changed, 263 insertions(+), 105 deletions(-) >>> create mode 100755 board/ti/am62x-sk/post-build.sh >>> create mode 100755 board/ti/am62x-sk/post-image.sh >>> delete mode 100644 boot/ti-k3-image-gen/Config.in >>> create mode 100644 boot/ti-k3/Config.in >>> create mode 100644 boot/ti-k3/common.mk >>> rename boot/{ => ti-k3}/ti-k3-boot-firmware/Config.in (100%) >>> rename boot/{ => ti-k3}/ti-k3-boot-firmware/ti-k3-boot-firmware.hash (100%) >>> rename boot/{ => ti-k3}/ti-k3-boot-firmware/ti-k3-boot-firmware.mk (100%) >>> create mode 100644 boot/ti-k3/ti-k3-core-secdev/Config.in >>> create mode 100644 boot/ti-k3/ti-k3-core-secdev/ti-k3-core-secdev.hash >>> create mode 100644 boot/ti-k3/ti-k3-core-secdev/ti-k3-core-secdev.mk >>> create mode 100644 boot/ti-k3/ti-k3-image-gen/Config.in >>> rename boot/{ => ti-k3}/ti-k3-image-gen/ti-k3-image-gen.hash (100%) >>> rename boot/{ => ti-k3}/ti-k3-image-gen/ti-k3-image-gen.mk (67%) >>> rename boot/{ => ti-k3}/ti-k3-r5-loader/Config.in (97%) >>> rename boot/{ => ti-k3}/ti-k3-r5-loader/ti-k3-r5-loader.hash (54%) >>> rename boot/{ => ti-k3}/ti-k3-r5-loader/ti-k3-r5-loader.mk (85%) >>> >>
On Sun, 18 Feb 2024 at 04:40, Alexander Sverdlin <alexander.sverdlin@gmail.com> wrote: > > Hi Dario! > > On Sat, 2024-02-17 at 17:02 +0100, Dario Binacchi wrote: > > This series, which in my humble opinion, should have been immediately > > considered to correct the compilation errors in case of HS-FS devcies, has > > seen an increase in patches in version 4 to remove the ti-k3-image-gen > > I wasn't aware of the preceeding versions, but... > > > package thanks to Binman. Additionally, it shares some modifications and > > views on how to implement certain changes with the series > > https://patchwork.ozlabs.org/project/buildroot/list/?series=394840. > > Therefore, I think it is necessary not to run them in parallel but to decide > > whether to merge one before the other or to consider a single series where > > the patches can be coherent with each other. I am available for both solutions. > > Let me know. > > ... as the broken HS-FS went unnoticed, seems there is no rush to fix the > build now? I noticed, and hacked in some am64x specific fixes here: https://github.com/relectrify/buildroot/commits/2023.11.1_relectrify. I was going to submit a cleaned up version of the patches, but I got distracted by fixing encrypted boot (see below) and never got back to cleaning them up. Sorry about that. Apparently TI don't support encrypted boot in their Linux SDK (yet?), only in the MCU SDK. There's a python script in the MCU SDK (rom_image_gen.py) which kinda works once you teach it how to read ascii keys as generated by the keywriter package. Except, it changes the size of the plaintext because it aligns it to 16-bytes and appends 32 random bytes, which causes a boot failure somewhere early on in U-Boot. I hacked around that by sticking the original binary size into some of those random bytes (it's not part of the X509 cert..) and teaching U-Boot to detect the encrypted image (https://github.com/relectrify/u-boot/commit/d16b4705ffebb0881633dfd5300bf4ac8490e75c) and doing a fixup. Once you do that, and change all the right places to run rom_image_gen.py it works, but it's pretty painful to get there. Hopefully this situation is a bit better in the binman version. Patrick
On Mon, Feb 19, 2024 at 12:24:52PM +0100, Romain Naour wrote: > Hello Michael, > > Le 19/02/2024 à 12:02, Michael Nazzareno Trimarchi a écrit : > > Hi Romain > > > > On Mon, Feb 19, 2024 at 10:30 AM Romain Naour <romain.naour@smile.fr> wrote: > >> > >> Hello Dario, > >> > >> Le 17/02/2024 à 17:02, Dario Binacchi a écrit : > >>> The SK-AM62B-P1 is the newest version of SK-AM62 which includes > >>> high-security field-securable (HS-FS) silicon to optionally customize keys > >>> and encryption for security applications. > >>> This requires enabling the BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS option, > >>> which, however, was buggy. This series fixes the errors and bumps the Linux > >>> kernel and U-Boot required for such a new device. > >>> > >>> This series, which in my humble opinion, should have been immediately > >>> considered to correct the compilation errors in case of HS-FS devcies, has > >>> seen an increase in patches in version 4 to remove the ti-k3-image-gen > >>> package thanks to Binman. Additionally, it shares some modifications and > >>> views on how to implement certain changes with the series > >>> https://patchwork.ozlabs.org/project/buildroot/list/?series=394840. > >>> Therefore, I think it is necessary not to run them in parallel but to decide > >>> whether to merge one before the other or to consider a single series where > >>> the patches can be coherent with each other. I am available for both solutions. > >>> Let me know. > >> > >> Thanks for this new version. I beleive both series should be merged into one > >> since we want to follow u-boot switch to binman, add more TI K3 SoC support and > >> keeping exising am62x ans am64x working in GP or HS/HS-FS. > >> > > > > Because the Dario patchset was sent before (end of November), it's > > reasonable to review and adjust that one > > and apply your changes for ti_j721e_sk on top of it. It think that is > > a standard way to make people happy about > > their work and contribution. > > Actually, the two series are about the same topic: TI K3 SoC support (GP, HS, > HS-FS) not only AM62x-SK HS-FS devices > > But due to the complexity of the BSP, the boot flow (4 way to boot!) and the > switch from custom tool to binman... this series is really difficult to review > without having a good understanding of TI K3 architecture peculiarity and having > one of each TI evaluation boards 🙂 Although I helped conceive some of this and the associated tooling early on, some of the what may look strange architectural decisions were driven by different use cases and requirements for the different devices (especially around automotive fast/early boot, but also security) in combination with limited on-chip SRAM... So this where we are at now. A future AM6x device variant will have yet another boot flow, but I can already say it will be very much simplified over what we have today :) > The series (based on Dario's work) about ti_j721e_sk suggested to remove TI > custom tools replaced by binman along with other improvements. > > I'll way for v5 and rebase the ti_j721e_sk on top of it. Thank you Romain for your buy-in. Let's focus on getting Dario's series in good shape and then move onto yours. I'd also like to re-introduce graphics (I had that working before) but I need to wait for all the "baseline" stuff to settle first. -- Andreas Dannenberg Texas Instruments Inc > > Best regards, > Romain > > > > > > Michael > > > >> My main concern is to avoid adding a new package for a tool that is already > >> deprecated ti-k3-image-gen (not sure if ti-k3-core-secdev is really deprecated) [1]. > >> > >> Also the topic is not only "AM62x-SK HS-FS devices" but "TI K3 HS-FS devices". > >> > >> [1] http://lists.busybox.net/pipermail/buildroot/2024-February/685820.html > >> > >> Best regards, > >> Romain > >> > >>> > >>> Dario Binacchi (20): > >>> configs/ti_am62x_sk_defconfig: fix BR2_TARGET_OPTEE_OS_PLATFORM > >>> setting > >>> configs/ti_am64x_sk_defconfig: fix BR2_TARGET_OPTEE_OS_PLATFORM > >>> setting > >>> configs/ti_am62x_sk_defconfig: explicitly set the ti-k3-r5-loader > >>> version > >>> configs/ti_am64x_sk_defconfig: explicitly set the ti-k3-r5-loader > >>> version > >>> boot/ti-k3-r5-loader: bump to version 2024.01 > >>> boot/ti-k3-core-secdev: new package > >>> boot/ti-k3-image-gen: manage HS hardware > >>> package/python-jsonschema: add host variant > >>> package/python-attrs: add host variant > >>> package/python-referencing: add host variant > >>> package/python-rpds-py: add host variant > >>> package/python-jsonschema-specifications: add host variant > >>> boot/ti-k3-r5-loader: set binman environment > >>> boot/uboot: set BINMAN_INDIRS for TI K3 DM > >>> configs/ti_am62x_sk_defconfig: bump U-Boot version to 2024.01 > >>> configs/ti_am62x_sk_defconfig: bump Linux version to 6.6.1 > >>> boot: move ti-k3-* packages to 'ti-k3' directory > >>> boot/ti-k3: move TI_K3_{SECTYPE,SOC} out of the image-gen scope > >>> boot/ti-k3/ti-k3-r5-loader: install tiboot3.bin > >>> configs/ti_am62x_sk_defconfig: don't use ti-k3-image-gen anymore > >>> > >>> DEVELOPERS | 1 + > >>> board/ti/am62x-sk/genimage.cfg | 7 +- > >>> board/ti/am62x-sk/post-build.sh | 49 ++++++++++++ > >>> board/ti/am62x-sk/post-image.sh | 5 ++ > >>> boot/Config.in | 4 +- > >>> boot/ti-k3-image-gen/Config.in | 77 ------------------- > >>> boot/ti-k3/Config.in | 59 ++++++++++++++ > >>> boot/ti-k3/common.mk | 1 + > >>> .../{ => ti-k3}/ti-k3-boot-firmware/Config.in | 0 > >>> .../ti-k3-boot-firmware.hash | 0 > >>> .../ti-k3-boot-firmware.mk | 0 > >>> boot/ti-k3/ti-k3-core-secdev/Config.in | 9 +++ > >>> .../ti-k3-core-secdev/ti-k3-core-secdev.hash | 3 + > >>> .../ti-k3-core-secdev/ti-k3-core-secdev.mk | 22 ++++++ > >>> boot/ti-k3/ti-k3-image-gen/Config.in | 25 ++++++ > >>> .../ti-k3-image-gen/ti-k3-image-gen.hash | 0 > >>> .../ti-k3-image-gen/ti-k3-image-gen.mk | 20 ++++- > >>> boot/{ => ti-k3}/ti-k3-r5-loader/Config.in | 4 +- > >>> .../ti-k3-r5-loader/ti-k3-r5-loader.hash | 2 +- > >>> .../ti-k3-r5-loader/ti-k3-r5-loader.mk | 16 +++- > >>> boot/uboot/Config.in | 7 +- > >>> boot/uboot/uboot.mk | 3 +- > >>> configs/ti_am62x_sk_defconfig | 23 +++--- > >>> configs/ti_am64x_sk_defconfig | 8 +- > >>> package/python-attrs/python-attrs.mk | 6 ++ > >>> .../python-jsonschema-specifications.mk | 5 ++ > >>> .../python-jsonschema/python-jsonschema.mk | 6 ++ > >>> .../python-referencing/python-referencing.mk | 5 ++ > >>> package/python-rpds-py/python-rpds-py.mk | 1 + > >>> 29 files changed, 263 insertions(+), 105 deletions(-) > >>> create mode 100755 board/ti/am62x-sk/post-build.sh > >>> create mode 100755 board/ti/am62x-sk/post-image.sh > >>> delete mode 100644 boot/ti-k3-image-gen/Config.in > >>> create mode 100644 boot/ti-k3/Config.in > >>> create mode 100644 boot/ti-k3/common.mk > >>> rename boot/{ => ti-k3}/ti-k3-boot-firmware/Config.in (100%) > >>> rename boot/{ => ti-k3}/ti-k3-boot-firmware/ti-k3-boot-firmware.hash (100%) > >>> rename boot/{ => ti-k3}/ti-k3-boot-firmware/ti-k3-boot-firmware.mk (100%) > >>> create mode 100644 boot/ti-k3/ti-k3-core-secdev/Config.in > >>> create mode 100644 boot/ti-k3/ti-k3-core-secdev/ti-k3-core-secdev.hash > >>> create mode 100644 boot/ti-k3/ti-k3-core-secdev/ti-k3-core-secdev.mk > >>> create mode 100644 boot/ti-k3/ti-k3-image-gen/Config.in > >>> rename boot/{ => ti-k3}/ti-k3-image-gen/ti-k3-image-gen.hash (100%) > >>> rename boot/{ => ti-k3}/ti-k3-image-gen/ti-k3-image-gen.mk (67%) > >>> rename boot/{ => ti-k3}/ti-k3-r5-loader/Config.in (97%) > >>> rename boot/{ => ti-k3}/ti-k3-r5-loader/ti-k3-r5-loader.hash (54%) > >>> rename boot/{ => ti-k3}/ti-k3-r5-loader/ti-k3-r5-loader.mk (85%) > >>> > >> >
Hello Andreas, Le 20/02/2024 à 01:41, Andreas Dannenberg a écrit : > On Mon, Feb 19, 2024 at 12:24:52PM +0100, Romain Naour wrote: >> Hello Michael, >> >> Le 19/02/2024 à 12:02, Michael Nazzareno Trimarchi a écrit : >>> Hi Romain >>> >>> On Mon, Feb 19, 2024 at 10:30 AM Romain Naour <romain.naour@smile.fr> wrote: >>>> >>>> Hello Dario, >>>> >>>> Le 17/02/2024 à 17:02, Dario Binacchi a écrit : >>>>> The SK-AM62B-P1 is the newest version of SK-AM62 which includes >>>>> high-security field-securable (HS-FS) silicon to optionally customize keys >>>>> and encryption for security applications. >>>>> This requires enabling the BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS option, >>>>> which, however, was buggy. This series fixes the errors and bumps the Linux >>>>> kernel and U-Boot required for such a new device. >>>>> >>>>> This series, which in my humble opinion, should have been immediately >>>>> considered to correct the compilation errors in case of HS-FS devcies, has >>>>> seen an increase in patches in version 4 to remove the ti-k3-image-gen >>>>> package thanks to Binman. Additionally, it shares some modifications and >>>>> views on how to implement certain changes with the series >>>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=394840. >>>>> Therefore, I think it is necessary not to run them in parallel but to decide >>>>> whether to merge one before the other or to consider a single series where >>>>> the patches can be coherent with each other. I am available for both solutions. >>>>> Let me know. >>>> >>>> Thanks for this new version. I beleive both series should be merged into one >>>> since we want to follow u-boot switch to binman, add more TI K3 SoC support and >>>> keeping exising am62x ans am64x working in GP or HS/HS-FS. >>>> >>> >>> Because the Dario patchset was sent before (end of November), it's >>> reasonable to review and adjust that one >>> and apply your changes for ti_j721e_sk on top of it. It think that is >>> a standard way to make people happy about >>> their work and contribution. >> >> Actually, the two series are about the same topic: TI K3 SoC support (GP, HS, >> HS-FS) not only AM62x-SK HS-FS devices >> >> But due to the complexity of the BSP, the boot flow (4 way to boot!) and the >> switch from custom tool to binman... this series is really difficult to review >> without having a good understanding of TI K3 architecture peculiarity and having >> one of each TI evaluation boards 🙂 > > Although I helped conceive some of this and the associated tooling early > on, some of the what may look strange architectural decisions were driven > by different use cases and requirements for the different devices > (especially around automotive fast/early boot, but also security) in > combination with limited on-chip SRAM... So this where we are at now. A > future AM6x device variant will have yet another boot flow, but I can > already say it will be very much simplified over what we have today :) About existing boot flow, I found two recent commit in u-boot that state that the "Split binary" (that requires sysfw.itb) is already a legacy boot flow: arm: dts: k3-binman: Add support for FIT templates Add templates for FIT images used extensively across K3 boards with most of the code common. This includes the FIT portions of: - tispl.bin - u-boot.img - sysfw.itb (in case of legacy boot flow) https://gitlab.com/u-boot/u-boot/-/commit/b153bad0f14168d5fcc02ba6bf1a2cd98daba9b5 arm: dts: k3-*-binman: Move to using templated FITs Reduce redundancy in code by using templates to generate the A72 boot binaries (tispl.bin and u-boot.img) as well as R5 boot binary sysfw.itb (for legacy boot following devices J721E and AM65x). https://gitlab.com/u-boot/u-boot/-/commit/4509b9ff0b8cb26907f9e9c3571b43565c859275 Which one should be recommended or avoided for a new design? Best regards, Romain > >> The series (based on Dario's work) about ti_j721e_sk suggested to remove TI >> custom tools replaced by binman along with other improvements. >> >> I'll way for v5 and rebase the ti_j721e_sk on top of it. > > Thank you Romain for your buy-in. Let's focus on getting Dario's series > in good shape and then move onto yours. I'd also like to re-introduce > graphics (I had that working before) but I need to wait for all the > "baseline" stuff to settle first. > > > -- > Andreas Dannenberg > Texas Instruments Inc > > > >> >> Best regards, >> Romain >> >> >>> >>> Michael >>> >>>> My main concern is to avoid adding a new package for a tool that is already >>>> deprecated ti-k3-image-gen (not sure if ti-k3-core-secdev is really deprecated) [1]. >>>> >>>> Also the topic is not only "AM62x-SK HS-FS devices" but "TI K3 HS-FS devices". >>>> >>>> [1] http://lists.busybox.net/pipermail/buildroot/2024-February/685820.html >>>> >>>> Best regards, >>>> Romain >>>> >>>>>
Hi Romain, On Tue, Feb 20, 2024 at 11:03:54AM +0100, Romain Naour wrote: > Hello Andreas, > > Le 20/02/2024 à 01:41, Andreas Dannenberg a écrit : > > On Mon, Feb 19, 2024 at 12:24:52PM +0100, Romain Naour wrote: > >> Hello Michael, > >> > >> Le 19/02/2024 à 12:02, Michael Nazzareno Trimarchi a écrit : > >>> Hi Romain > >>> > >>> On Mon, Feb 19, 2024 at 10:30 AM Romain Naour <romain.naour@smile.fr> wrote: > >>>> > >>>> Hello Dario, > >>>> > >>>> Le 17/02/2024 à 17:02, Dario Binacchi a écrit : > >>>>> The SK-AM62B-P1 is the newest version of SK-AM62 which includes > >>>>> high-security field-securable (HS-FS) silicon to optionally customize keys > >>>>> and encryption for security applications. > >>>>> This requires enabling the BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS option, > >>>>> which, however, was buggy. This series fixes the errors and bumps the Linux > >>>>> kernel and U-Boot required for such a new device. > >>>>> > >>>>> This series, which in my humble opinion, should have been immediately > >>>>> considered to correct the compilation errors in case of HS-FS devcies, has > >>>>> seen an increase in patches in version 4 to remove the ti-k3-image-gen > >>>>> package thanks to Binman. Additionally, it shares some modifications and > >>>>> views on how to implement certain changes with the series > >>>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=394840. > >>>>> Therefore, I think it is necessary not to run them in parallel but to decide > >>>>> whether to merge one before the other or to consider a single series where > >>>>> the patches can be coherent with each other. I am available for both solutions. > >>>>> Let me know. > >>>> > >>>> Thanks for this new version. I beleive both series should be merged into one > >>>> since we want to follow u-boot switch to binman, add more TI K3 SoC support and > >>>> keeping exising am62x ans am64x working in GP or HS/HS-FS. > >>>> > >>> > >>> Because the Dario patchset was sent before (end of November), it's > >>> reasonable to review and adjust that one > >>> and apply your changes for ti_j721e_sk on top of it. It think that is > >>> a standard way to make people happy about > >>> their work and contribution. > >> > >> Actually, the two series are about the same topic: TI K3 SoC support (GP, HS, > >> HS-FS) not only AM62x-SK HS-FS devices > >> > >> But due to the complexity of the BSP, the boot flow (4 way to boot!) and the > >> switch from custom tool to binman... this series is really difficult to review > >> without having a good understanding of TI K3 architecture peculiarity and having > >> one of each TI evaluation boards 🙂 > > > > Although I helped conceive some of this and the associated tooling early > > on, some of the what may look strange architectural decisions were driven > > by different use cases and requirements for the different devices > > (especially around automotive fast/early boot, but also security) in > > combination with limited on-chip SRAM... So this where we are at now. A > > future AM6x device variant will have yet another boot flow, but I can > > already say it will be very much simplified over what we have today :) > > About existing boot flow, I found two recent commit in u-boot that state that > the "Split binary" (that requires sysfw.itb) is already a legacy boot flow: It's called "legacy boot flow" because it was the boot flow used on the first K3 devices that were released (AM65x, J721E). This boot flow was not used on follow-on devices. The characteristics of this boot flow is that the initial FW image that gets loaded (tiboot3.bin) doesn't contain any device firmwares, but only a bootloader (such as U-Boot SPL). Then this boot loader will load the System Firmware firmware + config data blob (sysfw.itb) into the dedicated core (called "DMSC" = Device Manager and Security Controller). And then addiitonal boot stages will be loaded. These devices require this boot flow, and with this it is required to be supported by U-Boot (and any Linux distribution or build systems that build on that). TI is still making/selling those "legacy boot flow" devices, and will continue to do so for a very long time. One promiment community incarnation that you are probably aware of is the BeagleBone AI-64. > arm: dts: k3-binman: Add support for FIT templates > > Add templates for FIT images used extensively across K3 boards with most > of the code common. This includes the FIT portions of: > - tispl.bin > - u-boot.img > - sysfw.itb (in case of legacy boot flow) > > https://gitlab.com/u-boot/u-boot/-/commit/b153bad0f14168d5fcc02ba6bf1a2cd98daba9b5 > > arm: dts: k3-*-binman: Move to using templated FITs > > Reduce redundancy in code by using templates to generate the A72 boot > binaries (tispl.bin and u-boot.img) as well as R5 boot binary sysfw.itb > (for legacy boot following devices J721E and AM65x). > > https://gitlab.com/u-boot/u-boot/-/commit/4509b9ff0b8cb26907f9e9c3571b43565c859275 > > Which one should be recommended or avoided for a new design? Those commits are just a simplification to reduce duplication. As per earlier comment the "legacy boot flow" is something we continue needing to support. It isn't supposed to imply that those devices are about to disappear. Not sure if this answered your question; please let me know. -- Andreas Dannenberg Texas Instruments Inc > > Best regards, > Romain > > > > > >> The series (based on Dario's work) about ti_j721e_sk suggested to remove TI > >> custom tools replaced by binman along with other improvements. > >> > >> I'll way for v5 and rebase the ti_j721e_sk on top of it. > > > > Thank you Romain for your buy-in. Let's focus on getting Dario's series > > in good shape and then move onto yours. I'd also like to re-introduce > > graphics (I had that working before) but I need to wait for all the > > "baseline" stuff to settle first. > > > > > > -- > > Andreas Dannenberg > > Texas Instruments Inc > > > > > > > >> > >> Best regards, > >> Romain > >> > >> > >>> > >>> Michael > >>> > >>>> My main concern is to avoid adding a new package for a tool that is already > >>>> deprecated ti-k3-image-gen (not sure if ti-k3-core-secdev is really deprecated) [1]. > >>>> > >>>> Also the topic is not only "AM62x-SK HS-FS devices" but "TI K3 HS-FS devices". > >>>> > >>>> [1] http://lists.busybox.net/pipermail/buildroot/2024-February/685820.html > >>>> > >>>> Best regards, > >>>> Romain > >>>> > >>>>> >
Hi Andreas, Le 20/02/2024 à 21:04, Andreas Dannenberg a écrit : > Hi Romain, > > On Tue, Feb 20, 2024 at 11:03:54AM +0100, Romain Naour wrote: >> Hello Andreas, >> >> Le 20/02/2024 à 01:41, Andreas Dannenberg a écrit : >>> On Mon, Feb 19, 2024 at 12:24:52PM +0100, Romain Naour wrote: >>>> Hello Michael, >>>> >>>> Le 19/02/2024 à 12:02, Michael Nazzareno Trimarchi a écrit : >>>>> Hi Romain >>>>> >>>>> On Mon, Feb 19, 2024 at 10:30 AM Romain Naour <romain.naour@smile.fr> wrote: >>>>>> >>>>>> Hello Dario, >>>>>> >>>>>> Le 17/02/2024 à 17:02, Dario Binacchi a écrit : >>>>>>> The SK-AM62B-P1 is the newest version of SK-AM62 which includes >>>>>>> high-security field-securable (HS-FS) silicon to optionally customize keys >>>>>>> and encryption for security applications. >>>>>>> This requires enabling the BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS option, >>>>>>> which, however, was buggy. This series fixes the errors and bumps the Linux >>>>>>> kernel and U-Boot required for such a new device. >>>>>>> >>>>>>> This series, which in my humble opinion, should have been immediately >>>>>>> considered to correct the compilation errors in case of HS-FS devcies, has >>>>>>> seen an increase in patches in version 4 to remove the ti-k3-image-gen >>>>>>> package thanks to Binman. Additionally, it shares some modifications and >>>>>>> views on how to implement certain changes with the series >>>>>>> https://patchwork.ozlabs.org/project/buildroot/list/?series=394840. >>>>>>> Therefore, I think it is necessary not to run them in parallel but to decide >>>>>>> whether to merge one before the other or to consider a single series where >>>>>>> the patches can be coherent with each other. I am available for both solutions. >>>>>>> Let me know. >>>>>> >>>>>> Thanks for this new version. I beleive both series should be merged into one >>>>>> since we want to follow u-boot switch to binman, add more TI K3 SoC support and >>>>>> keeping exising am62x ans am64x working in GP or HS/HS-FS. >>>>>> >>>>> >>>>> Because the Dario patchset was sent before (end of November), it's >>>>> reasonable to review and adjust that one >>>>> and apply your changes for ti_j721e_sk on top of it. It think that is >>>>> a standard way to make people happy about >>>>> their work and contribution. >>>> >>>> Actually, the two series are about the same topic: TI K3 SoC support (GP, HS, >>>> HS-FS) not only AM62x-SK HS-FS devices >>>> >>>> But due to the complexity of the BSP, the boot flow (4 way to boot!) and the >>>> switch from custom tool to binman... this series is really difficult to review >>>> without having a good understanding of TI K3 architecture peculiarity and having >>>> one of each TI evaluation boards 🙂 >>> >>> Although I helped conceive some of this and the associated tooling early >>> on, some of the what may look strange architectural decisions were driven >>> by different use cases and requirements for the different devices >>> (especially around automotive fast/early boot, but also security) in >>> combination with limited on-chip SRAM... So this where we are at now. A >>> future AM6x device variant will have yet another boot flow, but I can >>> already say it will be very much simplified over what we have today :) >> >> About existing boot flow, I found two recent commit in u-boot that state that >> the "Split binary" (that requires sysfw.itb) is already a legacy boot flow: > > It's called "legacy boot flow" because it was the boot flow used on the > first K3 devices that were released (AM65x, J721E). This boot flow was > not used on follow-on devices. The characteristics of this boot flow is > that the initial FW image that gets loaded (tiboot3.bin) doesn't contain > any device firmwares, but only a bootloader (such as U-Boot SPL). Then > this boot loader will load the System Firmware firmware + config data > blob (sysfw.itb) into the dedicated core (called "DMSC" = Device Manager > and Security Controller). And then addiitonal boot stages will be > loaded. These devices require this boot flow, and with this it is > required to be supported by U-Boot (and any Linux distribution or build > systems that build on that). > > TI is still making/selling those "legacy boot flow" devices, and will > continue to do so for a very long time. One promiment community > incarnation that you are probably aware of is the BeagleBone AI-64. Thank you for the detailed explanation! I previouly worked on a AM57xx SoC that is nowaday legacy SoC, the latest ti-kernel 6.1 doesn't support some of the driver that where available in ti-kernel 5.10 (prueth 100M, RPMsg Sockets over virtio-rpmsg transport (use for ARM-DSP IPC3.x), TI-RTOS (the csl-common package was also removed from meta-ti)). Also the TI SDK on this plateform doesn't seems very active [1]. So, I'm worried when I read "legacy" :) [1] https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1290197/processor-sdk-am57x-legacy-processor-s-linux-update-plan > >> arm: dts: k3-binman: Add support for FIT templates >> >> Add templates for FIT images used extensively across K3 boards with most >> of the code common. This includes the FIT portions of: >> - tispl.bin >> - u-boot.img >> - sysfw.itb (in case of legacy boot flow) >> >> https://gitlab.com/u-boot/u-boot/-/commit/b153bad0f14168d5fcc02ba6bf1a2cd98daba9b5 >> >> arm: dts: k3-*-binman: Move to using templated FITs >> >> Reduce redundancy in code by using templates to generate the A72 boot >> binaries (tispl.bin and u-boot.img) as well as R5 boot binary sysfw.itb >> (for legacy boot following devices J721E and AM65x). >> >> https://gitlab.com/u-boot/u-boot/-/commit/4509b9ff0b8cb26907f9e9c3571b43565c859275 >> >> Which one should be recommended or avoided for a new design? > > Those commits are just a simplification to reduce duplication. As per > earlier comment the "legacy boot flow" is something we continue needing > to support. It isn't supposed to imply that those devices are about to > disappear. > > Not sure if this answered your question; please let me know. Yes, thank you. Best regards, Romain > > -- > Andreas Dannenberg > Texas Instruments Inc > > >> >> Best regards, >> Romain >> >> >>> >>>> The series (based on Dario's work) about ti_j721e_sk suggested to remove TI >>>> custom tools replaced by binman along with other improvements. >>>> >>>> I'll way for v5 and rebase the ti_j721e_sk on top of it. >>> >>> Thank you Romain for your buy-in. Let's focus on getting Dario's series >>> in good shape and then move onto yours. I'd also like to re-introduce >>> graphics (I had that working before) but I need to wait for all the >>> "baseline" stuff to settle first. >>> >>> >>> -- >>> Andreas Dannenberg >>> Texas Instruments Inc >>> >>> >>> >>>> >>>> Best regards, >>>> Romain >>>> >>>> >>>>> >>>>> Michael >>>>> >>>>>> My main concern is to avoid adding a new package for a tool that is already >>>>>> deprecated ti-k3-image-gen (not sure if ti-k3-core-secdev is really deprecated) [1]. >>>>>> >>>>>> Also the topic is not only "AM62x-SK HS-FS devices" but "TI K3 HS-FS devices". >>>>>> >>>>>> [1] http://lists.busybox.net/pipermail/buildroot/2024-February/685820.html >>>>>> >>>>>> Best regards, >>>>>> Romain >>>>>> >>>>>>> >>
Hi Romain, On Tue, Feb 20, 2024 at 10:36:51PM +0100, Romain Naour wrote: <snip> > >> About existing boot flow, I found two recent commit in u-boot that state that > >> the "Split binary" (that requires sysfw.itb) is already a legacy boot flow: > > > > It's called "legacy boot flow" because it was the boot flow used on the > > first K3 devices that were released (AM65x, J721E). This boot flow was > > not used on follow-on devices. The characteristics of this boot flow is > > that the initial FW image that gets loaded (tiboot3.bin) doesn't contain > > any device firmwares, but only a bootloader (such as U-Boot SPL). Then > > this boot loader will load the System Firmware firmware + config data > > blob (sysfw.itb) into the dedicated core (called "DMSC" = Device Manager > > and Security Controller). And then addiitonal boot stages will be > > loaded. These devices require this boot flow, and with this it is > > required to be supported by U-Boot (and any Linux distribution or build > > systems that build on that). > > > > TI is still making/selling those "legacy boot flow" devices, and will > > continue to do so for a very long time. One promiment community > > incarnation that you are probably aware of is the BeagleBone AI-64. > > Thank you for the detailed explanation! > > I previouly worked on a AM57xx SoC that is nowaday legacy SoC, the latest > ti-kernel 6.1 doesn't support some of the driver that where available in > ti-kernel 5.10 (prueth 100M, RPMsg Sockets over virtio-rpmsg transport (use for > ARM-DSP IPC3.x), TI-RTOS (the csl-common package was also removed from meta-ti)). > > Also the TI SDK on this plateform doesn't seems very active [1]. since you brought this up I wanted to add some additional context here. Older devices like AM57xx (AM335x and AM437x fall into the same bucket) will get what we call "LTS refresh SDKs" every year, rather than multiple drops per year as we do for the more recent devices. As for AM57xx specifically that refresh is currently targeted for e/o March 2024 and will be known as "SDK 9.2". There shouldn't be any feature regressions, and the only "new" thing (in addition to an all-refreshed SW baseline with 6.1 kernel and 2023.04 U-Boot) will be some Y2K38 issue fix on Linux. TI will be making and selling those devices for a very long time to come, and the annual refresh is seen as a good compromise between keeping things refreshed periodically and up to date while limiting the amount of repeat work/effort. -- Andreas Dannenberg Texas Instruments Inc
Hi Andreas, Le 23/02/2024 à 20:31, Andreas Dannenberg a écrit : > Hi Romain, > > On Tue, Feb 20, 2024 at 10:36:51PM +0100, Romain Naour wrote: > > <snip> > >>>> About existing boot flow, I found two recent commit in u-boot that state that >>>> the "Split binary" (that requires sysfw.itb) is already a legacy boot flow: >>> >>> It's called "legacy boot flow" because it was the boot flow used on the >>> first K3 devices that were released (AM65x, J721E). This boot flow was >>> not used on follow-on devices. The characteristics of this boot flow is >>> that the initial FW image that gets loaded (tiboot3.bin) doesn't contain >>> any device firmwares, but only a bootloader (such as U-Boot SPL). Then >>> this boot loader will load the System Firmware firmware + config data >>> blob (sysfw.itb) into the dedicated core (called "DMSC" = Device Manager >>> and Security Controller). And then addiitonal boot stages will be >>> loaded. These devices require this boot flow, and with this it is >>> required to be supported by U-Boot (and any Linux distribution or build >>> systems that build on that). >>> >>> TI is still making/selling those "legacy boot flow" devices, and will >>> continue to do so for a very long time. One promiment community >>> incarnation that you are probably aware of is the BeagleBone AI-64. >> >> Thank you for the detailed explanation! >> >> I previouly worked on a AM57xx SoC that is nowaday legacy SoC, the latest >> ti-kernel 6.1 doesn't support some of the driver that where available in >> ti-kernel 5.10 (prueth 100M, RPMsg Sockets over virtio-rpmsg transport (use for >> ARM-DSP IPC3.x), TI-RTOS (the csl-common package was also removed from meta-ti)). >> >> Also the TI SDK on this plateform doesn't seems very active [1]. > > since you brought this up I wanted to add some additional context here. > Older devices like AM57xx (AM335x and AM437x fall into the same bucket) > will get what we call "LTS refresh SDKs" every year, rather than > multiple drops per year as we do for the more recent devices. As for > AM57xx specifically that refresh is currently targeted for e/o March > 2024 and will be known as "SDK 9.2". There shouldn't be any feature > regressions, and the only "new" thing (in addition to an all-refreshed > SW baseline with 6.1 kernel and 2023.04 U-Boot) will be some Y2K38 issue > fix on Linux. TI will be making and selling those devices for a very > long time to come, and the annual refresh is seen as a good compromise > between keeping things refreshed periodically and up to date while > limiting the amount of repeat work/effort. Ok, thanks for the information. I'm looking forward this new SDK release. Best regards, Romain > > -- > Andreas Dannenberg > Texas Instruments Inc >
The SK-AM62B-P1 is the newest version of SK-AM62 which includes high-security field-securable (HS-FS) silicon to optionally customize keys and encryption for security applications. This requires enabling the BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS option, which, however, was buggy. This series fixes the errors and bumps the Linux kernel and U-Boot required for such a new device. This series, which in my humble opinion, should have been immediately considered to correct the compilation errors in case of HS-FS devcies, has seen an increase in patches in version 4 to remove the ti-k3-image-gen package thanks to Binman. Additionally, it shares some modifications and views on how to implement certain changes with the series https://patchwork.ozlabs.org/project/buildroot/list/?series=394840. Therefore, I think it is necessary not to run them in parallel but to decide whether to merge one before the other or to consider a single series where the patches can be coherent with each other. I am available for both solutions. Let me know. Dario Binacchi (20): configs/ti_am62x_sk_defconfig: fix BR2_TARGET_OPTEE_OS_PLATFORM setting configs/ti_am64x_sk_defconfig: fix BR2_TARGET_OPTEE_OS_PLATFORM setting configs/ti_am62x_sk_defconfig: explicitly set the ti-k3-r5-loader version configs/ti_am64x_sk_defconfig: explicitly set the ti-k3-r5-loader version boot/ti-k3-r5-loader: bump to version 2024.01 boot/ti-k3-core-secdev: new package boot/ti-k3-image-gen: manage HS hardware package/python-jsonschema: add host variant package/python-attrs: add host variant package/python-referencing: add host variant package/python-rpds-py: add host variant package/python-jsonschema-specifications: add host variant boot/ti-k3-r5-loader: set binman environment boot/uboot: set BINMAN_INDIRS for TI K3 DM configs/ti_am62x_sk_defconfig: bump U-Boot version to 2024.01 configs/ti_am62x_sk_defconfig: bump Linux version to 6.6.1 boot: move ti-k3-* packages to 'ti-k3' directory boot/ti-k3: move TI_K3_{SECTYPE,SOC} out of the image-gen scope boot/ti-k3/ti-k3-r5-loader: install tiboot3.bin configs/ti_am62x_sk_defconfig: don't use ti-k3-image-gen anymore DEVELOPERS | 1 + board/ti/am62x-sk/genimage.cfg | 7 +- board/ti/am62x-sk/post-build.sh | 49 ++++++++++++ board/ti/am62x-sk/post-image.sh | 5 ++ boot/Config.in | 4 +- boot/ti-k3-image-gen/Config.in | 77 ------------------- boot/ti-k3/Config.in | 59 ++++++++++++++ boot/ti-k3/common.mk | 1 + .../{ => ti-k3}/ti-k3-boot-firmware/Config.in | 0 .../ti-k3-boot-firmware.hash | 0 .../ti-k3-boot-firmware.mk | 0 boot/ti-k3/ti-k3-core-secdev/Config.in | 9 +++ .../ti-k3-core-secdev/ti-k3-core-secdev.hash | 3 + .../ti-k3-core-secdev/ti-k3-core-secdev.mk | 22 ++++++ boot/ti-k3/ti-k3-image-gen/Config.in | 25 ++++++ .../ti-k3-image-gen/ti-k3-image-gen.hash | 0 .../ti-k3-image-gen/ti-k3-image-gen.mk | 20 ++++- boot/{ => ti-k3}/ti-k3-r5-loader/Config.in | 4 +- .../ti-k3-r5-loader/ti-k3-r5-loader.hash | 2 +- .../ti-k3-r5-loader/ti-k3-r5-loader.mk | 16 +++- boot/uboot/Config.in | 7 +- boot/uboot/uboot.mk | 3 +- configs/ti_am62x_sk_defconfig | 23 +++--- configs/ti_am64x_sk_defconfig | 8 +- package/python-attrs/python-attrs.mk | 6 ++ .../python-jsonschema-specifications.mk | 5 ++ .../python-jsonschema/python-jsonschema.mk | 6 ++ .../python-referencing/python-referencing.mk | 5 ++ package/python-rpds-py/python-rpds-py.mk | 1 + 29 files changed, 263 insertions(+), 105 deletions(-) create mode 100755 board/ti/am62x-sk/post-build.sh create mode 100755 board/ti/am62x-sk/post-image.sh delete mode 100644 boot/ti-k3-image-gen/Config.in create mode 100644 boot/ti-k3/Config.in create mode 100644 boot/ti-k3/common.mk rename boot/{ => ti-k3}/ti-k3-boot-firmware/Config.in (100%) rename boot/{ => ti-k3}/ti-k3-boot-firmware/ti-k3-boot-firmware.hash (100%) rename boot/{ => ti-k3}/ti-k3-boot-firmware/ti-k3-boot-firmware.mk (100%) create mode 100644 boot/ti-k3/ti-k3-core-secdev/Config.in create mode 100644 boot/ti-k3/ti-k3-core-secdev/ti-k3-core-secdev.hash create mode 100644 boot/ti-k3/ti-k3-core-secdev/ti-k3-core-secdev.mk create mode 100644 boot/ti-k3/ti-k3-image-gen/Config.in rename boot/{ => ti-k3}/ti-k3-image-gen/ti-k3-image-gen.hash (100%) rename boot/{ => ti-k3}/ti-k3-image-gen/ti-k3-image-gen.mk (67%) rename boot/{ => ti-k3}/ti-k3-r5-loader/Config.in (97%) rename boot/{ => ti-k3}/ti-k3-r5-loader/ti-k3-r5-loader.hash (54%) rename boot/{ => ti-k3}/ti-k3-r5-loader/ti-k3-r5-loader.mk (85%)