| Message ID | 20240213172817.2872849-22-romain.naour@smile.fr |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add ti_j721e_sk_defconfig | expand |
Hi Romain, On Tue, 2024-02-13 at 18:28 +0100, Romain Naour wrote: > ti-k3-image-gen tool is deprecated an replaced by binman [1]. > > All defconfig that was using it have been updated to use U-boot > binman tool instead. > > So, we can safely remove ti-k3-image-gen package. > > [1] https://git.yoctoproject.org/meta-ti/commit/?id=835811cf8586926cf78a961d090f4e6150432235 > > Cc: Anand Gadiyar <gadiyar@ti.com> > Cc: Xuanhao Shi <X15000177@gmail.com> > Signed-off-by: Romain Naour <romain.naour@smile.fr> > --- > Config.in.legacy | 7 ++ > DEVELOPERS | 2 - > boot/Config.in | 1 - > boot/ti-k3-image-gen/Config.in | 81 ----------------------- > boot/ti-k3-image-gen/ti-k3-image-gen.hash | 3 - > boot/ti-k3-image-gen/ti-k3-image-gen.mk | 54 --------------- > 6 files changed, 7 insertions(+), 141 deletions(-) > delete mode 100644 boot/ti-k3-image-gen/Config.in > delete mode 100644 boot/ti-k3-image-gen/ti-k3-image-gen.hash > delete mode 100644 boot/ti-k3-image-gen/ti-k3-image-gen.mk > > diff --git a/Config.in.legacy b/Config.in.legacy > index a869279af7..2b59a65f1c 100644 > --- a/Config.in.legacy > +++ b/Config.in.legacy > @@ -146,6 +146,13 @@ endif > > comment "Legacy options removed in 2024.02" > > +config BR2_TARGET_TI_K3_IMAGE_GEN > + bool "ti-k3-image-gen removed" > + select BR2_LEGACY > + help > + ti-k3-image-gen tool has been removed and replaced by > + U-Boot binman tool (requires U-boot >= 2024.01). Is commit 6d6228ab8fe5 "am62a: dts: binman: Package tiboot3.bin, tispl.bin, u-boot.img" in U-Boot repo not what is actually required (since v2023.10)? At least that's the version which works for me.
Hi Alexander, Le 13/02/2024 à 20:05, Alexander Sverdlin a écrit : > Hi Romain, > > On Tue, 2024-02-13 at 18:28 +0100, Romain Naour wrote: >> ti-k3-image-gen tool is deprecated an replaced by binman [1]. >> >> All defconfig that was using it have been updated to use U-boot >> binman tool instead. >> >> So, we can safely remove ti-k3-image-gen package. >> >> [1] https://git.yoctoproject.org/meta-ti/commit/?id=835811cf8586926cf78a961d090f4e6150432235 >> >> Cc: Anand Gadiyar <gadiyar@ti.com> >> Cc: Xuanhao Shi <X15000177@gmail.com> >> Signed-off-by: Romain Naour <romain.naour@smile.fr> >> --- >> Config.in.legacy | 7 ++ >> DEVELOPERS | 2 - >> boot/Config.in | 1 - >> boot/ti-k3-image-gen/Config.in | 81 ----------------------- >> boot/ti-k3-image-gen/ti-k3-image-gen.hash | 3 - >> boot/ti-k3-image-gen/ti-k3-image-gen.mk | 54 --------------- >> 6 files changed, 7 insertions(+), 141 deletions(-) >> delete mode 100644 boot/ti-k3-image-gen/Config.in >> delete mode 100644 boot/ti-k3-image-gen/ti-k3-image-gen.hash >> delete mode 100644 boot/ti-k3-image-gen/ti-k3-image-gen.mk >> >> diff --git a/Config.in.legacy b/Config.in.legacy >> index a869279af7..2b59a65f1c 100644 >> --- a/Config.in.legacy >> +++ b/Config.in.legacy >> @@ -146,6 +146,13 @@ endif >> >> comment "Legacy options removed in 2024.02" >> >> +config BR2_TARGET_TI_K3_IMAGE_GEN >> + bool "ti-k3-image-gen removed" >> + select BR2_LEGACY >> + help >> + ti-k3-image-gen tool has been removed and replaced by >> + U-Boot binman tool (requires U-boot >= 2024.01). > > Is commit 6d6228ab8fe5 "am62a: dts: binman: Package tiboot3.bin, tispl.bin, u-boot.img" > in U-Boot repo not what is actually required (since v2023.10)? > At least that's the version which works for me. > Thank you for the info, indeed v2023.10 should be good-enough. I was looking at meta-ti history [1] and I thought that v2024.01 was the minimum u-boot release for complete binman support for all TI K3 SoC variant. I'll fix! [1] https://git.yoctoproject.org/meta-ti/commit/?id=5b5b8b932561d76c5ed50a4210a726df86c649bf Best regards, Romain
Hi Romain, On Tue, 2024-02-13 at 18:28 +0100, Romain Naour wrote: > ti-k3-image-gen tool is deprecated an replaced by binman [1]. > > All defconfig that was using it have been updated to use U-boot > binman tool instead. > > So, we can safely remove ti-k3-image-gen package. > > [1] https://git.yoctoproject.org/meta-ti/commit/?id=835811cf8586926cf78a961d090f4e6150432235 > > Cc: Anand Gadiyar <gadiyar@ti.com> > Cc: Xuanhao Shi <X15000177@gmail.com> > Signed-off-by: Romain Naour <romain.naour@smile.fr> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> > --- > Config.in.legacy | 7 ++ > DEVELOPERS | 2 - > boot/Config.in | 1 - > boot/ti-k3-image-gen/Config.in | 81 ----------------------- > boot/ti-k3-image-gen/ti-k3-image-gen.hash | 3 - > boot/ti-k3-image-gen/ti-k3-image-gen.mk | 54 --------------- > 6 files changed, 7 insertions(+), 141 deletions(-) > delete mode 100644 boot/ti-k3-image-gen/Config.in > delete mode 100644 boot/ti-k3-image-gen/ti-k3-image-gen.hash > delete mode 100644 boot/ti-k3-image-gen/ti-k3-image-gen.mk
Hi Romain, On Tue, 2024-02-13 at 18:28 +0100, Romain Naour wrote: > -choice > - prompt "Security type" > - help > - The target SoC security type option for image gen. Valid > - options are "gp" for General Purpose devices, "hs-fs" for > - High Security - Field Securable devices, or "hs" for High > - Security - Security Enforcing devices. Note for all High > - Security device variants the TI_SECURE_DEV_PKG environmental > - variable must be defined at build time pointing to a valid > - core-secdev-k3 folder location, otherwise the build will > - fail, see > - https://git.ti.com/cgit/security-development-tools/core-secdev-k3 > - > -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP > - bool "gp" > - > -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS > - bool "hs-fs" > - > -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS > - bool "hs" > - > -endchoice another observation I made just now: previously BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP=y was the default, which didn't boot on my HS-FS SoC. You patchset started out-of-the-box, which, I conclude, means, HS-FS is now the default for AM62x. I'm not sure if this is a problem, though.
Hi Alexander, Le 15/02/2024 à 11:20, Alexander Sverdlin a écrit : > Hi Romain, > > On Tue, 2024-02-13 at 18:28 +0100, Romain Naour wrote: >> -choice >> - prompt "Security type" >> - help >> - The target SoC security type option for image gen. Valid >> - options are "gp" for General Purpose devices, "hs-fs" for >> - High Security - Field Securable devices, or "hs" for High >> - Security - Security Enforcing devices. Note for all High >> - Security device variants the TI_SECURE_DEV_PKG environmental >> - variable must be defined at build time pointing to a valid >> - core-secdev-k3 folder location, otherwise the build will >> - fail, see >> - https://git.ti.com/cgit/security-development-tools/core-secdev-k3 >> - >> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP >> - bool "gp" >> - >> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS >> - bool "hs-fs" >> - >> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS >> - bool "hs" >> - >> -endchoice > > another observation I made just now: previously BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP=y > was the default, which didn't boot on my HS-FS SoC. > > You patchset started out-of-the-box, which, I conclude, means, HS-FS is now the > default for AM62x. I'm not sure if this is a problem, though. > I don't think so, the am62x defconfig should still be for GP SoC by default. Ok, maybe there is something to improve in this series but I don't have any HS/HS-FS SoC for testing... Best regards, Romain
Hi Romain, On Thu, 2024-02-15 at 12:26 +0100, Romain Naour wrote: > > On Tue, 2024-02-13 at 18:28 +0100, Romain Naour wrote: > > > -choice > > > - prompt "Security type" > > > - help > > > - The target SoC security type option for image gen. Valid > > > - options are "gp" for General Purpose devices, "hs-fs" for > > > - High Security - Field Securable devices, or "hs" for High > > > - Security - Security Enforcing devices. Note for all High > > > - Security device variants the TI_SECURE_DEV_PKG environmental > > > - variable must be defined at build time pointing to a valid > > > - core-secdev-k3 folder location, otherwise the build will > > > - fail, see > > > - https://git.ti.com/cgit/security-development-tools/core-secdev-k3 > > > - > > > -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP > > > - bool "gp" > > > - > > > -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS > > > - bool "hs-fs" > > > - > > > -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS > > > - bool "hs" > > > - > > > -endchoice > > > > another observation I made just now: previously BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP=y > > was the default, which didn't boot on my HS-FS SoC. > > > > You patchset started out-of-the-box, which, I conclude, means, HS-FS is now the > > default for AM62x. I'm not sure if this is a problem, though. > > > > I don't think so, the am62x defconfig should still be for GP SoC by default. I'm pretty sure it's HS-FS by default, because GP (as of todays "master") >>> ti-k3-image-gen 08.06.00.007 Extracting gzip -d -c /home/alex/remote/buildroot/dl/ti-k3-image-gen/k3-image-gen-08.06.00.007.tar.gz | /home/alex/remote/buildroot/output/host/bin/tar --strip-components=1 -C /home/alex/remote/buildroot/output/build/ti-k3-image-gen-08.06.00.007 -xf - >>> ti-k3-image-gen 08.06.00.007 Patching >>> ti-k3-image-gen 08.06.00.007 Configuring cp /home/alex/remote/buildroot/output/images/ti-sysfw/ti-fs-firmware-am62x-hs-fs.bin /home/alex/remote/buildroot/output/build/ti-k3-image-gen-08.06.00.007 cp: cannot stat '/home/alex/remote/buildroot/output/images/ti-sysfw/ti-fs-firmware-am62x-hs-fs.bin': No such file or directory make: *** [package/pkg-generic.mk:273: /home/alex/remote/buildroot/output/build/ti-k3-image-gen-08.06.00.007/.stamp_configured] Error 1 So overall, for HS-FS it doesn't look as a regression with you patchset, but rather as improvement, even though it doesn't boot, but it builds at least... I can try to look what could be the problem with U-Boot environment...
Hi Alexander, Le 15/02/2024 à 19:50, Alexander Sverdlin a écrit : > Hi Romain, > > On Thu, 2024-02-15 at 12:26 +0100, Romain Naour wrote: >>> On Tue, 2024-02-13 at 18:28 +0100, Romain Naour wrote: >>>> -choice >>>> - prompt "Security type" >>>> - help >>>> - The target SoC security type option for image gen. Valid >>>> - options are "gp" for General Purpose devices, "hs-fs" for >>>> - High Security - Field Securable devices, or "hs" for High >>>> - Security - Security Enforcing devices. Note for all High >>>> - Security device variants the TI_SECURE_DEV_PKG environmental >>>> - variable must be defined at build time pointing to a valid >>>> - core-secdev-k3 folder location, otherwise the build will >>>> - fail, see >>>> - https://git.ti.com/cgit/security-development-tools/core-secdev-k3 >>>> - >>>> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP >>>> - bool "gp" >>>> - >>>> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS >>>> - bool "hs-fs" >>>> - >>>> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS >>>> - bool "hs" >>>> - >>>> -endchoice >>> >>> another observation I made just now: previously BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP=y >>> was the default, which didn't boot on my HS-FS SoC. >>> >>> You patchset started out-of-the-box, which, I conclude, means, HS-FS is now the >>> default for AM62x. I'm not sure if this is a problem, though. >>> >> >> I don't think so, the am62x defconfig should still be for GP SoC by default. > > I'm pretty sure it's HS-FS by default, because GP (as of todays "master") > >>>> ti-k3-image-gen 08.06.00.007 Extracting > gzip -d -c /home/alex/remote/buildroot/dl/ti-k3-image-gen/k3-image-gen-08.06.00.007.tar.gz | /home/alex/remote/buildroot/output/host/bin/tar --strip-components=1 -C > /home/alex/remote/buildroot/output/build/ti-k3-image-gen-08.06.00.007 -xf - >>>> ti-k3-image-gen 08.06.00.007 Patching >>>> ti-k3-image-gen 08.06.00.007 Configuring > cp /home/alex/remote/buildroot/output/images/ti-sysfw/ti-fs-firmware-am62x-hs-fs.bin /home/alex/remote/buildroot/output/build/ti-k3-image-gen-08.06.00.007 > cp: cannot stat '/home/alex/remote/buildroot/output/images/ti-sysfw/ti-fs-firmware-am62x-hs-fs.bin': No such file or directory > make: *** [package/pkg-generic.mk:273: /home/alex/remote/buildroot/output/build/ti-k3-image-gen-08.06.00.007/.stamp_configured] Error 1 Weird, the gitlab-ci build fine with : BR2_TARGET_TI_K3_BOOT_FIRMWARE=y BR2_TARGET_TI_K3_IMAGE_GEN=y # BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM62AX is not set # BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM62X is not set BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM64X=y # BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM65X is not set BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP=y # BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS is not set # BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS is not set BR2_TARGET_TI_K3_IMAGE_GEN_SOC="am64x" BR2_TARGET_TI_K3_IMAGE_GEN_FW_TYPE="ti-sci" BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE="gp" BR2_TARGET_TI_K3_R5_LOADER=y BR2_TARGET_TI_K3_R5_LOADER_LATEST_VERSION=y AM64x: https://gitlab.com/buildroot.org/buildroot/-/jobs/6134305650 Same for AM62x: https://gitlab.com/buildroot.org/buildroot/-/jobs/6134305619 > > So overall, for HS-FS it doesn't look as a regression with you patchset, > but rather as improvement, even though it doesn't boot, but it builds > at least... > > I can try to look what could be the problem with U-Boot environment... > Yes please. Best regards, Romain
Hi Romain, On Thu, 2024-02-15 at 23:32 +0100, Romain Naour wrote: > Weird, the gitlab-ci build fine with : > > BR2_TARGET_TI_K3_BOOT_FIRMWARE=y > BR2_TARGET_TI_K3_IMAGE_GEN=y > # BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM62AX is not set > # BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM62X is not set > BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM64X=y > # BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM65X is not set > BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP=y > # BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS is not set right, I had to change from BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP to BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS for my HW, so the latter seems to be broken in "master".
On Thu, Feb 15, 2024 at 11:20:50AM +0100, Alexander Sverdlin wrote: > Hi Romain, > > On Tue, 2024-02-13 at 18:28 +0100, Romain Naour wrote: > > -choice > > - prompt "Security type" > > - help > > - The target SoC security type option for image gen. Valid > > - options are "gp" for General Purpose devices, "hs-fs" for > > - High Security - Field Securable devices, or "hs" for High > > - Security - Security Enforcing devices. Note for all High > > - Security device variants the TI_SECURE_DEV_PKG environmental > > - variable must be defined at build time pointing to a valid > > - core-secdev-k3 folder location, otherwise the build will > > - fail, see > > - https://git.ti.com/cgit/security-development-tools/core-secdev-k3 > > - > > -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP > > - bool "gp" > > - > > -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS > > - bool "hs-fs" > > - > > -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS > > - bool "hs" > > - > > -endchoice > > another observation I made just now: previously BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP=y > was the default, which didn't boot on my HS-FS SoC. > > You patchset started out-of-the-box, which, I conclude, means, HS-FS is now the > default for AM62x. I'm not sure if this is a problem, though. HS-FS should be the default for all TI AM6x devices. This is our "production silicon" and what's used for (almost) all projects, especially new projects. This being said having support for GP device variants still is desirable for existing boards/projects, such as the current BeaglePlay boards (amongst earlier version of TI starter kit EVMs for AM6x). -- Andreas Dannenberg Texas Instruments Inc > > -- > Alexander Sverdlin. > > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
Hello Andreas, Le 16/02/2024 à 21:06, Andreas Dannenberg a écrit : > On Thu, Feb 15, 2024 at 11:20:50AM +0100, Alexander Sverdlin wrote: >> Hi Romain, >> >> On Tue, 2024-02-13 at 18:28 +0100, Romain Naour wrote: >>> -choice >>> - prompt "Security type" >>> - help >>> - The target SoC security type option for image gen. Valid >>> - options are "gp" for General Purpose devices, "hs-fs" for >>> - High Security - Field Securable devices, or "hs" for High >>> - Security - Security Enforcing devices. Note for all High >>> - Security device variants the TI_SECURE_DEV_PKG environmental >>> - variable must be defined at build time pointing to a valid >>> - core-secdev-k3 folder location, otherwise the build will >>> - fail, see >>> - https://git.ti.com/cgit/security-development-tools/core-secdev-k3 >>> - >>> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP >>> - bool "gp" >>> - >>> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS >>> - bool "hs-fs" >>> - >>> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS >>> - bool "hs" >>> - >>> -endchoice >> >> another observation I made just now: previously BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP=y >> was the default, which didn't boot on my HS-FS SoC. >> >> You patchset started out-of-the-box, which, I conclude, means, HS-FS is now the >> default for AM62x. I'm not sure if this is a problem, though. > > HS-FS should be the default for all TI AM6x devices. This is our > "production silicon" and what's used for (almost) all projects, > especially new projects. This being said having support for GP device > variants still is desirable for existing boards/projects, such as the > current BeaglePlay boards (amongst earlier version of TI starter kit > EVMs for AM6x). Thank you, I was not aware of this. I found your post in the TI forum about the recent switch from GP to HS-FS device in Yocto [1]. Currently existing am64/am62 defconfigs are still targeting GP devices but we should add additional commits to do the switch to HS-FS. What about other SoC of the K3 architecture? Is the DRA829/J721e device will also switch to HS-FS by default? From the u-boot k3 documentation, it's not clear witch device type is used by default across all k3 SoC. By default I was expecting the GP type for all the k3 family (I was wrong). [1] https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1210443/faq-am625-generating-sitara-am62x-am62ax-am64x-gp-device-bootable-mmc-sd-card-images-using-sdk-v8-6-and-yocto [2] https://source.denx.de/u-boot/u-boot/-/blob/master/doc/board/ti/k3.rst?ref_type=heads&plain=1#L108 Best regards, Romain > > -- > Andreas Dannenberg > Texas Instruments Inc > > >> >> -- >> Alexander Sverdlin. >> >> _______________________________________________ >> buildroot mailing list >> buildroot@buildroot.org >> https://lists.buildroot.org/mailman/listinfo/buildroot
Hi Romain, On Fri, Feb 16, 2024 at 10:38:42PM +0100, Romain Naour wrote: > Hello Andreas, > > Le 16/02/2024 à 21:06, Andreas Dannenberg a écrit : > > On Thu, Feb 15, 2024 at 11:20:50AM +0100, Alexander Sverdlin wrote: > >> Hi Romain, > >> > >> On Tue, 2024-02-13 at 18:28 +0100, Romain Naour wrote: > >>> -choice > >>> - prompt "Security type" > >>> - help > >>> - The target SoC security type option for image gen. Valid > >>> - options are "gp" for General Purpose devices, "hs-fs" for > >>> - High Security - Field Securable devices, or "hs" for High > >>> - Security - Security Enforcing devices. Note for all High > >>> - Security device variants the TI_SECURE_DEV_PKG environmental > >>> - variable must be defined at build time pointing to a valid > >>> - core-secdev-k3 folder location, otherwise the build will > >>> - fail, see > >>> - https://git.ti.com/cgit/security-development-tools/core-secdev-k3 > >>> - > >>> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP > >>> - bool "gp" > >>> - > >>> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS > >>> - bool "hs-fs" > >>> - > >>> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS > >>> - bool "hs" > >>> - > >>> -endchoice > >> > >> another observation I made just now: previously BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP=y > >> was the default, which didn't boot on my HS-FS SoC. > >> > >> You patchset started out-of-the-box, which, I conclude, means, HS-FS is now the > >> default for AM62x. I'm not sure if this is a problem, though. > > > > HS-FS should be the default for all TI AM6x devices. This is our > > "production silicon" and what's used for (almost) all projects, > > especially new projects. This being said having support for GP device > > variants still is desirable for existing boards/projects, such as the > > current BeaglePlay boards (amongst earlier version of TI starter kit > > EVMs for AM6x). > > Thank you, I was not aware of this. > > I found your post in the TI forum about the recent switch from GP to HS-FS > device in Yocto [1]. > > Currently existing am64/am62 defconfigs are still targeting GP devices but we > should add additional commits to do the switch to HS-FS. > > What about other SoC of the K3 architecture? > Is the DRA829/J721e device will also switch to HS-FS by default? I needed to double-check with the team, since I'm only intimately involved with AM62/AM64/AM65 type devices. All the others are managed by a different group in TI. So based on what I found out here's the full context accross TI's K3 platform of devices and their associated TI EVMs / Starter Kits: * All "Sitara"-brand SoCs (AM62x, AM64, AM65x) are HS-FS first * All "Jacinto"-brand industrial SoCs (AM68, AM69 and AM67) are also HS-FS first * All new "Jacinto"-brand automotive/other SoCs (J7AEN onwards) are HS-FS first * All existing "Jacinto"-brand SoCs (TDA4, J721E, J7200, J721S2 and J784S4) are GP by default So while there are still boards out there with GP silicon (last bullet) those are probably not the typical target platforms for Buildroot, being very complex and high-end multi-core SoCs, mostly used in automotive applications. The one exception here that has more weight in my oppinion is the current BeaglePlay board (AM62x-based), those also have GP devices on those boards. All this being being said, I stand by my previous comment that HS-FS should be the default. As for the BeaglePlay board (which is a very nice community board) and potentially selected Jacinto-based boards this could potentially be handled with a dedicated defconfig or some other Kconfig magic to enable a seamless and easy out of box experience. -- Andreas Dannenberg Texas Instruments Inc > > From the u-boot k3 documentation, it's not clear witch device type is used by > default across all k3 SoC. By default I was expecting the GP type for all the k3 > family (I was wrong). > > [1] > https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1210443/faq-am625-generating-sitara-am62x-am62ax-am64x-gp-device-bootable-mmc-sd-card-images-using-sdk-v8-6-and-yocto > > [2] > https://source.denx.de/u-boot/u-boot/-/blob/master/doc/board/ti/k3.rst?ref_type=heads&plain=1#L108 > > Best regards, > Romain > > > > > -- > > Andreas Dannenberg > > Texas Instruments Inc > > > > > >> > >> -- > >> Alexander Sverdlin. > >> > >> _______________________________________________ > >> buildroot mailing list > >> buildroot@buildroot.org > >> https://lists.buildroot.org/mailman/listinfo/buildroot >
Hi Andreas, Le 19/02/2024 à 20:42, Andreas Dannenberg a écrit : > Hi Romain, > > On Fri, Feb 16, 2024 at 10:38:42PM +0100, Romain Naour wrote: >> Hello Andreas, >> >> Le 16/02/2024 à 21:06, Andreas Dannenberg a écrit : >>> On Thu, Feb 15, 2024 at 11:20:50AM +0100, Alexander Sverdlin wrote: >>>> Hi Romain, >>>> >>>> On Tue, 2024-02-13 at 18:28 +0100, Romain Naour wrote: >>>>> -choice >>>>> - prompt "Security type" >>>>> - help >>>>> - The target SoC security type option for image gen. Valid >>>>> - options are "gp" for General Purpose devices, "hs-fs" for >>>>> - High Security - Field Securable devices, or "hs" for High >>>>> - Security - Security Enforcing devices. Note for all High >>>>> - Security device variants the TI_SECURE_DEV_PKG environmental >>>>> - variable must be defined at build time pointing to a valid >>>>> - core-secdev-k3 folder location, otherwise the build will >>>>> - fail, see >>>>> - https://git.ti.com/cgit/security-development-tools/core-secdev-k3 >>>>> - >>>>> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP >>>>> - bool "gp" >>>>> - >>>>> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS >>>>> - bool "hs-fs" >>>>> - >>>>> -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS >>>>> - bool "hs" >>>>> - >>>>> -endchoice >>>> >>>> another observation I made just now: previously BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP=y >>>> was the default, which didn't boot on my HS-FS SoC. >>>> >>>> You patchset started out-of-the-box, which, I conclude, means, HS-FS is now the >>>> default for AM62x. I'm not sure if this is a problem, though. >>> >>> HS-FS should be the default for all TI AM6x devices. This is our >>> "production silicon" and what's used for (almost) all projects, >>> especially new projects. This being said having support for GP device >>> variants still is desirable for existing boards/projects, such as the >>> current BeaglePlay boards (amongst earlier version of TI starter kit >>> EVMs for AM6x). >> >> Thank you, I was not aware of this. >> >> I found your post in the TI forum about the recent switch from GP to HS-FS >> device in Yocto [1]. >> >> Currently existing am64/am62 defconfigs are still targeting GP devices but we >> should add additional commits to do the switch to HS-FS. >> >> What about other SoC of the K3 architecture? >> Is the DRA829/J721e device will also switch to HS-FS by default? > > I needed to double-check with the team, since I'm only intimately > involved with AM62/AM64/AM65 type devices. All the others are managed by > a different group in TI. > > So based on what I found out here's the full context accross TI's K3 > platform of devices and their associated TI EVMs / Starter Kits: > > * All "Sitara"-brand SoCs (AM62x, AM64, AM65x) are HS-FS first > * All "Jacinto"-brand industrial SoCs (AM68, AM69 and AM67) are also HS-FS first > * All new "Jacinto"-brand automotive/other SoCs (J7AEN onwards) are HS-FS first > * All existing "Jacinto"-brand SoCs (TDA4, J721E, J7200, J721S2 and J784S4) are GP by default > > So while there are still boards out there with GP silicon (last bullet) > those are probably not the typical target platforms for Buildroot, being > very complex and high-end multi-core SoCs, mostly used in automotive > applications. The one exception here that has more weight in my oppinion > is the current BeaglePlay board (AM62x-based), those also have GP devices > on those boards. I'm curently working on a j721e SoC based custom board bringup involving IPC communication with one DSP (C66x). While it was possible to build the DSP firmware within Yocto (dunfell), it required to package the TI-PDK to provide headers and libraries for the DSP project. We endup by building the DSP firmware outside of Yocto (it would be the same with Buildroot). If the SoC is available and can run Linux, the the rootfs can be build by Buildroot. And what about the Beagleboard-AI64 (J721e) ? https://beagleboard.org/ai-64 > > All this being being said, I stand by my previous comment that HS-FS > should be the default. As for the BeaglePlay board (which is a very nice > community board) and potentially selected Jacinto-based boards this > could potentially be handled with a dedicated defconfig or some other > Kconfig magic to enable a seamless and easy out of box experience. Patch welcome then :) I don't have one but it would go hand in hand with my (old) beagleboard rev C2 (omap3530)! Best regards, Romain > > > -- > Andreas Dannenberg > Texas Instruments Inc > > > > > > > >> >> From the u-boot k3 documentation, it's not clear witch device type is used by >> default across all k3 SoC. By default I was expecting the GP type for all the k3 >> family (I was wrong). >> >> [1] >> https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1210443/faq-am625-generating-sitara-am62x-am62ax-am64x-gp-device-bootable-mmc-sd-card-images-using-sdk-v8-6-and-yocto >> >> [2] >> https://source.denx.de/u-boot/u-boot/-/blob/master/doc/board/ti/k3.rst?ref_type=heads&plain=1#L108 >> >> Best regards, >> Romain >> >>> >>> -- >>> Andreas Dannenberg >>> Texas Instruments Inc >>> >>> >>>> >>>> -- >>>> Alexander Sverdlin. >>>> >>>> _______________________________________________ >>>> buildroot mailing list >>>> buildroot@buildroot.org >>>> https://lists.buildroot.org/mailman/listinfo/buildroot >>
diff --git a/Config.in.legacy b/Config.in.legacy index a869279af7..2b59a65f1c 100644 --- a/Config.in.legacy +++ b/Config.in.legacy @@ -146,6 +146,13 @@ endif comment "Legacy options removed in 2024.02" +config BR2_TARGET_TI_K3_IMAGE_GEN + bool "ti-k3-image-gen removed" + select BR2_LEGACY + help + ti-k3-image-gen tool has been removed and replaced by + U-Boot binman tool (requires U-boot >= 2024.01). + config BR2_PACKAGE_TINYMEMBENCH bool "tinymembench removed" select BR2_LEGACY diff --git a/DEVELOPERS b/DEVELOPERS index e5f2dd2327..df6c60704c 100644 --- a/DEVELOPERS +++ b/DEVELOPERS @@ -151,7 +151,6 @@ N: Anand Gadiyar <gadiyar@ti.com> F: board/ti/am62x-sk/ F: board/ti/am64x-sk/ F: boot/ti-k3-boot-firmware/ -F: boot/ti-k3-image-gen/ F: boot/ti-k3-r5-loader/ F: configs/ti_am62x_sk_defconfig F: configs/ti_am64x_sk_defconfig @@ -3219,7 +3218,6 @@ N: Xuanhao Shi <X15000177@gmail.com> F: board/ti/am62x-sk/ F: board/ti/am64x-sk/ F: boot/ti-k3-boot-firmware/ -F: boot/ti-k3-image-gen/ F: boot/ti-k3-r5-loader/ F: configs/ti_am62x_sk_defconfig F: configs/ti_am64x_sk_defconfig diff --git a/boot/Config.in b/boot/Config.in index e5fdf7ad43..87e1b7c00e 100644 --- a/boot/Config.in +++ b/boot/Config.in @@ -20,7 +20,6 @@ source "boot/s500-bootloader/Config.in" source "boot/shim/Config.in" source "boot/syslinux/Config.in" source "boot/ti-k3-boot-firmware/Config.in" -source "boot/ti-k3-image-gen/Config.in" source "boot/ti-k3-r5-loader/Config.in" source "boot/uboot/Config.in" source "boot/vexpress-firmware/Config.in" diff --git a/boot/ti-k3-image-gen/Config.in b/boot/ti-k3-image-gen/Config.in deleted file mode 100644 index e54f5ec992..0000000000 --- a/boot/ti-k3-image-gen/Config.in +++ /dev/null @@ -1,81 +0,0 @@ -config BR2_TARGET_TI_K3_IMAGE_GEN - bool "ti-k3-image-gen" - depends on BR2_TARGET_TI_K3_R5_LOADER - select BR2_TARGET_TI_K3_BOOT_FIRMWARE - # We need FIT support in uboot-tools, which is why we select a - # host package - select BR2_PACKAGE_HOST_UBOOT_TOOLS - select BR2_PACKAGE_HOST_UBOOT_TOOLS_FIT_SUPPORT - help - Use TI's k3-image-gen to build a separate bare metal boot - binary from a separate SPL that is running on the R5 core. - - https://git.ti.com/cgit/k3-image-gen/k3-image-gen/ - -if BR2_TARGET_TI_K3_IMAGE_GEN -choice - prompt "SoC family" - -config BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM62AX - bool "am62ax" - select BR2_TARGET_TI_K3_BOOT_FIRMWARE_SOC_AM62AX - -config BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM62X - bool "am62x" - select BR2_TARGET_TI_K3_BOOT_FIRMWARE_SOC_AM62X - -config BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM64X - bool "am64x" - select BR2_TARGET_TI_K3_BOOT_FIRMWARE_SOC_AM64X - -config BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM65X - bool "am65x" - select BR2_TARGET_TI_K3_BOOT_FIRMWARE_SOC_AM65X - -endchoice - -choice - prompt "Security type" - help - The target SoC security type option for image gen. Valid - options are "gp" for General Purpose devices, "hs-fs" for - High Security - Field Securable devices, or "hs" for High - Security - Security Enforcing devices. Note for all High - Security device variants the TI_SECURE_DEV_PKG environmental - variable must be defined at build time pointing to a valid - core-secdev-k3 folder location, otherwise the build will - fail, see - https://git.ti.com/cgit/security-development-tools/core-secdev-k3 - -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP - bool "gp" - -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS - bool "hs-fs" - -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS - bool "hs" - -endchoice - -config BR2_TARGET_TI_K3_IMAGE_GEN_SOC - string - default "am62ax" if BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM62AX - default "am62x" if BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM62X - default "am64x" if BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM64X - default "am65x" if BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM65X - -config BR2_TARGET_TI_K3_IMAGE_GEN_FW_TYPE - string - default "ti-fs" if BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM62AX - default "ti-fs" if BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM62X - default "ti-sci" if BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM64X - default "ti-sci" if BR2_TARGET_TI_K3_IMAGE_GEN_SOC_AM65X - -config BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE - string - default "gp" if BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_GP - default "hs-fs" if BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS_FS - default "hs" if BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE_HS - -endif diff --git a/boot/ti-k3-image-gen/ti-k3-image-gen.hash b/boot/ti-k3-image-gen/ti-k3-image-gen.hash deleted file mode 100644 index c968c5648f..0000000000 --- a/boot/ti-k3-image-gen/ti-k3-image-gen.hash +++ /dev/null @@ -1,3 +0,0 @@ -# Locally calculated -sha256 f89ea4b1f5c992455b1a682fde48359221b53f3294135df4bf20feea6aea90e4 k3-image-gen-08.06.00.007.tar.gz -sha256 f012e8d000d711d0539e5b4c812fc1d3a59c10fc1e3d6ea155556f5b78286845 LICENSE diff --git a/boot/ti-k3-image-gen/ti-k3-image-gen.mk b/boot/ti-k3-image-gen/ti-k3-image-gen.mk deleted file mode 100644 index 64be9a18f2..0000000000 --- a/boot/ti-k3-image-gen/ti-k3-image-gen.mk +++ /dev/null @@ -1,54 +0,0 @@ -################################################################################ -# -# ti-k3-image-gen -# -################################################################################ - -TI_K3_IMAGE_GEN_VERSION = 08.06.00.007 -TI_K3_IMAGE_GEN_SITE = https://git.ti.com/cgit/k3-image-gen/k3-image-gen/snapshot -TI_K3_IMAGE_GEN_SOURCE = k3-image-gen-$(TI_K3_IMAGE_GEN_VERSION).tar.gz -TI_K3_IMAGE_GEN_LICENSE = BSD-3-Clause -TI_K3_IMAGE_GEN_LICENSE_FILES = LICENSE -TI_K3_IMAGE_GEN_INSTALL_IMAGES = YES - -# - ti-k3-image-gen is used to build tiboot3.bin, using the -# r5-u-boot-spl.bin file from the ti-k3-r5-loader package. Hence the -# dependency on ti-k3-r5-loader. -# - the ti-k3-image-gen makefiles seem to need some feature from Make -# v4.0, similar to u-boot. -TI_K3_IMAGE_GEN_DEPENDENCIES = \ - host-arm-gnu-toolchain \ - host-python3 \ - host-openssl \ - host-uboot-tools \ - ti-k3-r5-loader \ - ti-k3-boot-firmware \ - $(BR2_MAKE_HOST_DEPENDENCY) - -TI_K3_IMAGE_GEN_FW_TYPE = $(call qstrip,$(BR2_TARGET_TI_K3_IMAGE_GEN_FW_TYPE)) -TI_K3_IMAGE_GEN_SOC = $(call qstrip,$(BR2_TARGET_TI_K3_IMAGE_GEN_SOC)) -TI_K3_IMAGE_GEN_SECTYPE = $(call qstrip,$(BR2_TARGET_TI_K3_IMAGE_GEN_SECTYPE)) - -TI_K3_IMAGE_GEN_SYSFW = $(TI_K3_IMAGE_GEN_FW_TYPE)-firmware-$(TI_K3_IMAGE_GEN_SOC)-$(TI_K3_IMAGE_GEN_SECTYPE).bin - -define TI_K3_IMAGE_GEN_CONFIGURE_CMDS - cp $(BINARIES_DIR)/ti-sysfw/$(TI_K3_IMAGE_GEN_SYSFW) $(@D) -endef - -define TI_K3_IMAGE_GEN_BUILD_CMDS - $(TARGET_MAKE_ENV) \ - $(BR2_MAKE) -C $(@D) \ - SOC=$(TI_K3_IMAGE_GEN_SOC) \ - SOC_TYPE=$(TI_K3_IMAGE_GEN_SECTYPE) \ - CONFIG=evm \ - CROSS_COMPILE=$(HOST_DIR)/bin/arm-none-eabi- \ - SBL=$(BINARIES_DIR)/r5-u-boot-spl.bin \ - O=$(@D)/tmp \ - BIN_DIR=$(@D) -endef - -define TI_K3_IMAGE_GEN_INSTALL_IMAGES_CMDS - cp $(@D)/tiboot3.bin $(BINARIES_DIR) -endef - -$(eval $(generic-package))
ti-k3-image-gen tool is deprecated an replaced by binman [1]. All defconfig that was using it have been updated to use U-boot binman tool instead. So, we can safely remove ti-k3-image-gen package. [1] https://git.yoctoproject.org/meta-ti/commit/?id=835811cf8586926cf78a961d090f4e6150432235 Cc: Anand Gadiyar <gadiyar@ti.com> Cc: Xuanhao Shi <X15000177@gmail.com> Signed-off-by: Romain Naour <romain.naour@smile.fr> --- Config.in.legacy | 7 ++ DEVELOPERS | 2 - boot/Config.in | 1 - boot/ti-k3-image-gen/Config.in | 81 ----------------------- boot/ti-k3-image-gen/ti-k3-image-gen.hash | 3 - boot/ti-k3-image-gen/ti-k3-image-gen.mk | 54 --------------- 6 files changed, 7 insertions(+), 141 deletions(-) delete mode 100644 boot/ti-k3-image-gen/Config.in delete mode 100644 boot/ti-k3-image-gen/ti-k3-image-gen.hash delete mode 100644 boot/ti-k3-image-gen/ti-k3-image-gen.mk