add support for TI's AM64x and AM62x boards

The TI K3 R5 loader package essentially is a wrapper to build a special version of U-boot SPL used as part of a multi-stage boot flow on TI K3 devices, and as such needs full flexibility as to specifying the U-Boot sources used for the build. To accomodate this, add the same options as already available in the regular U-Boot package. For most use cases, the same source settings (repo URL, versions, etc.) should be used for both ti-k3-r5-loader and uboot packages.

Signed-off-by Andreas Dannenberg <[email protected]>

---
 boot/ti-k3-r5-loader/Config.in          | 65 +++++++++++++++++++++++--
 boot/ti-k3-r5-loader/ti-k3-r5-loader.mk | 32 +++++++++++-
 2 files changed, 93 insertions(+), 4 deletions(-)

boot/ti-k3-r5-loader/Config.in +0 -0

index 10602c8df3..2419babe70 100644

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +0 -0

index afa309aa98..341888623e 100644

Andreas, All,

On 2023-06-22 11:02 -0500, Andreas Dannenberg via buildroot spake thusly:

Quoted 7 lines

The TI K3 R5 loader package essentially is a wrapper to build a special version of U-boot SPL used as part of a multi-stage boot flow on TI K3 devices, and as such needs full flexibility as to specifying the U-Boot sources used for the build. To accomodate this, add the same options as already available in the regular U-Boot package. For most use cases, the same source settings (repo URL, versions, etc.) should be used for both ti-k3-r5-loader and uboot packages.

Currently, there is no dependency ("depends on" or "select") between uboot and ti-k3-r5-loader; yet, your phrasing seems to imply that it does not make sense to build ti-k3-r5-loader without building uboot.

Then, in the comment below, you add a note about "Falcon boot (which would skip the uboot package completely)".

So, I'm a bit curious here: what should the user do when uboot is not enabled, if we instruct it to use the same version?

Quoted 11 lines

Signed-off-by Andreas Dannenberg <[email protected]>

---
  boot/ti-k3-r5-loader/Config.in          | 65 +++++++++++++++++++++++--
  boot/ti-k3-r5-loader/ti-k3-r5-loader.mk | 32 +++++++++++-
  2 files changed, 93 insertions(+), 4 deletions(-)

boot/ti-k3-r5-loader/Config.in +0 -0

index 10602c8df3..2419babe70 100644

boot/ti-k3-r5-loader/Config.in line 2

Quoted 3 lines

boot/ti-k3-r5-loader/Config.in +1 -1

@@ -1,14 +1,73 @@
  config BR2_TARGET_TI_K3_R5_LOADER
-	bool "ti-k3-r5-loader"
+	bool "TI K3 R5 Loader"

Our prompts always match the package name in Buildroot, i.e. the directory name. In this case, ti-k3-r5-loader is exactly that and we want to keep that.

boot/ti-k3-r5-loader/Config.in line 11

Quoted 11 lines

boot/ti-k3-r5-loader/Config.in +2 -2

  	depends on BR2_aarch64
  	help
-	  Separate U-Boot build for R5 cores on TI's k3 boards.
+	  Separate U-Boot SPL build for R5 core on TI's K3 processors.
  	  Usually used to build tiboot3.bin with k3-image-gen.
 
  if BR2_TARGET_TI_K3_R5_LOADER
 
  choice
-	prompt "Configuration"
+	prompt "U-Boot Version"

It is a bit confusing tho see "U-Boot version" in the "ti-k3-r5-loader" package. I know it is really just a uboot being compiled, but still this is confusing. I'd keep ti-k3-r5-loader in the prompts. I could be convinced for the middle ground "ti-k3-r5-loader U-Boot version" if you really want to have U-Boot there.

Since you want the defaults to be the same as uboot, you can do that:

choice
bool "U-Boot version"
default BR2_TARGET_TI_K3_R5_LOADER_LATEST_VERSION if BR2_TARGET_UBOOT_LATEST_VERSION default BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION if BR2_TARGET_UBOOT_CUSTOM_VERSION default BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL if BR2_TARGET_UBOOT_CUSTOM_TARBALL default BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_GIT if BR2_TARGET_UBOOT_CUSTOM_GIT default BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_HG if BR2_TARGET_UBOOT_CUSTOM_HG default BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_SVN if BR2_TARGET_UBOOT_CUSTOM_SVN default BR2_TARGET_TI_K3_R5_LOADER_LATEST_VERSION # Fallback if uboot not enabled

...
endchoice

config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION_VALUE
string "U-Boot version"
default BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE depends on BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION

config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL_LOCATION
string "URL of custom U-Boot tarball" default BR2_TARGET_UBOOT_CUSTOM_TARBALL_LOCATION depends on BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL

... and so on, you get the gist.

[--SNIP--]

boot/ti-k3-r5-loader/Config.in line 70

Quoted 1 line

boot/ti-k3-r5-loader/Config.in +1 -0

+	prompt "U-Boot Configuration"

Same comment as for the version prompt.

[--SNIP--]

Quoted 5 lines

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +0 -0

index afa309aa98..341888623e 100644

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk line 10

Quoted 9 lines

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +6 -0

@@ -2,11 +2,41 @@
  #
  # ti-k3-r5-loader
  #
+# The ti-k3-r5 loader package should really be built from the same U-Boot
+# sources as the uboot package itself, so for most users so all LOADER_SITE /
+# LOADER_SOURCE type definitions should be set the same for both packages.
+# However it still makes sense to keep the ti-k3-r5-loader package somewhat
+# separated and independent from the uboot package to allow for special use
+# cases such as Falcon boot (which would skip the uboot package completely).

Do you mean that uboot would not be built at all, or that the uboot binary would not be loaded at runtime?

Regards,
Yann E. MORIN.

Quoted 9 lines

On 2023-06-22 11:02 -0500, Andreas Dannenberg via buildroot spake thusly:

Quoted 7 lines

The TI K3 R5 loader package essentially is a wrapper to build a special version of U-boot SPL used as part of a multi-stage boot flow on TI K3 devices, and as such needs full flexibility as to specifying the U-Boot sources used for the build. To accomodate this, add the same options as already available in the regular U-Boot package. For most use cases, the same source settings (repo URL, versions, etc.) should be used for both ti-k3-r5-loader and uboot packages.

Quoted 3 lines

Currently, there is no dependency ("depends on" or "select") between uboot and ti-k3-r5-loader; yet, your phrasing seems to imply that it does not make sense to build ti-k3-r5-loader without building uboot.

That's not what I read in that paragraph. I think it means that the same
source should be used as U-Boot. It's just a separate package because, AFAIU, it may use a different .config.

If that is true, and I'm not missing anything else, then the situation
actually looks quite similar to barebox-aux. With the difference that for Falcon boot you want to have only "u-boot-aux" and not the full u-boot. So, if what I'm saying is true, then perhaps it's better to approach it the same way as in barebox?

At the very minimum, I think there should be a "same version as U-Boot"
option, which is the default (if U-Boot is enabled). There's a bit the unfortunate aspect that this package becomes before U-Boot in the menu, but let's assume people typically start from a defconfig.

Regards,
Arnout

Quoted 96 lines

Then, in the comment below, you add a note about "Falcon boot (which would skip the uboot package completely)".

So, I'm a bit curious here: what should the user do when uboot is not enabled, if we instruct it to use the same version?

Quoted 11 lines

Signed-off-by Andreas Dannenberg <[email protected]>

---
 boot/ti-k3-r5-loader/Config.in          | 65 +++++++++++++++++++++++--
 boot/ti-k3-r5-loader/ti-k3-r5-loader.mk | 32 +++++++++++-
 2 files changed, 93 insertions(+), 4 deletions(-)

boot/ti-k3-r5-loader/Config.in +0 -0

index 10602c8df3..2419babe70 100644

boot/ti-k3-r5-loader/Config.in line 2

Quoted 3 lines

boot/ti-k3-r5-loader/Config.in +1 -1

@@ -1,14 +1,73 @@
 config BR2_TARGET_TI_K3_R5_LOADER
-	bool "ti-k3-r5-loader"
+	bool "TI K3 R5 Loader"

Our prompts always match the package name in Buildroot, i.e. the directory name. In this case, ti-k3-r5-loader is exactly that and we want to keep that.

boot/ti-k3-r5-loader/Config.in line 11

Quoted 9 lines

boot/ti-k3-r5-loader/Config.in +2 -2

 	depends on BR2_aarch64
 	help
-	  Separate U-Boot build for R5 cores on TI's k3 boards.
+	  Separate U-Boot SPL build for R5 core on TI's K3 processors.
 	  Usually used to build tiboot3.bin with k3-image-gen.
 if BR2_TARGET_TI_K3_R5_LOADER
 choice
-	prompt "Configuration"
+	prompt "U-Boot Version"

It is a bit confusing tho see "U-Boot version" in the "ti-k3-r5-loader" package. I know it is really just a uboot being compiled, but still this is confusing. I'd keep ti-k3-r5-loader in the prompts. I could be convinced for the middle ground "ti-k3-r5-loader U-Boot version" if you really want to have U-Boot there.

Since you want the defaults to be the same as uboot, you can do that:

choice
bool "U-Boot version"
default BR2_TARGET_TI_K3_R5_LOADER_LATEST_VERSION if BR2_TARGET_UBOOT_LATEST_VERSION default BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION if BR2_TARGET_UBOOT_CUSTOM_VERSION default BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL if BR2_TARGET_UBOOT_CUSTOM_TARBALL default BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_GIT if BR2_TARGET_UBOOT_CUSTOM_GIT default BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_HG if BR2_TARGET_UBOOT_CUSTOM_HG default BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_SVN if BR2_TARGET_UBOOT_CUSTOM_SVN default BR2_TARGET_TI_K3_R5_LOADER_LATEST_VERSION # Fallback if uboot not enabled

...
endchoice

config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION_VALUE
string "U-Boot version"
default BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE depends on BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION

config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL_LOCATION
string "URL of custom U-Boot tarball" default BR2_TARGET_UBOOT_CUSTOM_TARBALL_LOCATION depends on BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL

... and so on, you get the gist.

[--SNIP--]

boot/ti-k3-r5-loader/Config.in line 70

Quoted 1 line

boot/ti-k3-r5-loader/Config.in +1 -0

+	prompt "U-Boot Configuration"

Same comment as for the version prompt.

[--SNIP--]

Quoted 5 lines

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +0 -0

index afa309aa98..341888623e 100644

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk line 10

Quoted 9 lines

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +6 -0

@@ -2,11 +2,41 @@
 #
 # ti-k3-r5-loader
 #
+# The ti-k3-r5 loader package should really be built from the same U-Boot
+# sources as the uboot package itself, so for most users so all LOADER_SITE /
+# LOADER_SOURCE type definitions should be set the same for both packages.
+# However it still makes sense to keep the ti-k3-r5-loader package somewhat
+# separated and independent from the uboot package to allow for special use
+# cases such as Falcon boot (which would skip the uboot package completely).

Do you mean that uboot would not be built at all, or that the uboot binary would not be loaded at runtime?

Regards,
Yann E. MORIN.

The TI K3 R5 loader package essentially is a wrapper to build a special version of U-boot SPL used as part of a multi-stage boot flow on TI K3 devices, and as such needs full flexibility as to specifying the U-Boot sources used for the build. To accomodate this, add the same options as already available in the regular U-Boot package. For most use cases, the same source settings (repo URL, versions, etc.) should be used for both ti-k3-r5-loader and uboot packages.

Signed-off-by Andreas Dannenberg <[email protected]>

---
 boot/ti-k3-r5-loader/Config.in          | 65 +++++++++++++++++++++++--
 boot/ti-k3-r5-loader/ti-k3-r5-loader.mk | 32 +++++++++++-
 2 files changed, 93 insertions(+), 4 deletions(-)

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +1 -0

+# The ti-k3-r5 loader package should really be built from the same 

U-Boot
+# sources as the uboot package itself, so for most users so all LOADER_SITE /
+# LOADER_SOURCE type definitions should be set the same for both packages.
+# However it still makes sense to keep the ti-k3-r5-loader package somewhat
+# separated and independent from the uboot package to allow for special use
+# cases such as Falcon boot (which would skip the uboot package completely).
+#

################################################################################

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +1 -1

-TI_K3_R5_LOADER_VERSION = 2022.10
+TI_K3_R5_LOADER_VERSION = $(call 

qstrip,$(BR2_TARGET_TI_K3_R5_LOADER_VERSION))

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +4 -0

+
+ifeq ($(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL),y)
+# Handle custom U-Boot tarballs as specified by the configuration
+TI_K3_R5_LOADER_TARBALL = $(call 

qstrip,$(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL_LOCATION)) +TI_K3_R5_LOADER_SITE = $(patsubst %/,%,$(dir $(TI_K3_R5_LOADER_TARBALL)))

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +3 -0

+TI_K3_R5_LOADER_SOURCE = $(notdir $(TI_K3_R5_LOADER_TARBALL))
+else ifeq ($(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_GIT),y)
+TI_K3_R5_LOADER_SITE = $(call 

qstrip,$(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_REPO_URL))

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +3 -0

+TI_K3_R5_LOADER_SITE_METHOD = git
+else ifeq ($(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_HG),y)
+TI_K3_R5_LOADER_SITE = $(call 

qstrip,$(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_REPO_URL))

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +3 -0

+TI_K3_R5_LOADER_SITE_METHOD = hg
+else ifeq ($(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_SVN),y)
+TI_K3_R5_LOADER_SITE = $(call 

qstrip,$(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_REPO_URL))

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +6 -0

+TI_K3_R5_LOADER_SITE_METHOD = svn
+else
+# Handle stable official U-Boot versions
 TI_K3_R5_LOADER_SITE = https://ftp.denx.de/pub/u-boot
 TI_K3_R5_LOADER_SOURCE = u-boot-$(TI_K3_R5_LOADER_VERSION).tar.bz2
+endif
+
+ifeq 

($(BR2_TARGET_TI_K3_R5_LOADER)$(BR2_TARGET_TI_K3_R5_LOADER_LATEST_VERSION),y)

The TI K3 R5 loader package essentially is a wrapper to build a special version of U-boot SPL used as part of a multi-stage boot flow on TI K3 devices, and as such needs full flexibility as to specifying the U-Boot sources used for the build. To accomodate this, add the same options as already available in the regular U-Boot package. For most use cases, the same source settings (repo URL, versions, etc.) should be used for both ti-k3-r5-loader and uboot packages.

Signed-off-by Andreas Dannenberg <[email protected]>

---
 boot/ti-k3-r5-loader/Config.in          | 65 +++++++++++++++++++++++--
 boot/ti-k3-r5-loader/ti-k3-r5-loader.mk | 32 +++++++++++-
 2 files changed, 93 insertions(+), 4 deletions(-)

boot/ti-k3-r5-loader/Config.in +2 -2

index 10602c8df3..2419babe70 100644
@@ -1,14 +1,73 @@
 config BR2_TARGET_TI_K3_R5_LOADER
-	bool "ti-k3-r5-loader"
+	bool "TI K3 R5 Loader"
 	depends on BR2_aarch64
 	help
-	  Separate U-Boot build for R5 cores on TI's k3 boards.
+	  Separate U-Boot SPL build for R5 core on TI's K3 processors.
 	  Usually used to build tiboot3.bin with k3-image-gen.
 

boot/ti-k3-r5-loader/Config.in +32 -0

+
+config BR2_TARGET_TI_K3_R5_LOADER_LATEST_VERSION
+	bool "2022.10"
+
+config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION
+	bool "Custom version"
+	help
+	  This option allows to use a specific official versions
+
+config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL
+	bool "Custom tarball"
+
+config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_GIT
+	bool "Custom Git repository"
+
+config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_HG
+	bool "Custom Mercurial repository"
+
+config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_SVN
+	bool "Custom Subversion repository"
+
+endchoice
+
+config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION_VALUE
+	string "U-Boot version"
+	depends on BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION
+
+config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL_LOCATION
+	string "URL of custom U-Boot tarball"
+	depends on BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL
+
+if BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_GIT || 

BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_HG || BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_SVN

boot/ti-k3-r5-loader/Config.in +20 -0

+
+config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_REPO_URL
+	string "URL of custom repository"
+
+config BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_REPO_VERSION
+	string "Custom repository version"
+	help
+	  Revision to use in the typical format used by
+	  Git/Mercurial/Subversion E.G. a sha id, a tag, branch, ..
+
+endif
+
+config BR2_TARGET_TI_K3_R5_LOADER_VERSION
+	string
+	default "2022.10"	if BR2_TARGET_TI_K3_R5_LOADER_LATEST_VERSION
+	default BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION_VALUE \
+		if BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_VERSION
+	default "custom"	if BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL
+	default BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_REPO_VERSION \
+		if BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_GIT || 

BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_HG || BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_SVN

From: Xuanhao Shi <[email protected]>

This is the image generator that builds the initial boot binary, tiboot3.bin, for the R5 core on TI's K3 family of devices. This requires the R5 SPL output from the ti-k3-r5-loader package.

https://git.ti.com/cgit/k3-image-gen/k3-image-gen

Signed-off-by Xuanhao Shi <[email protected]>

Signed-off-by Anand Gadiyar <[email protected]>

Signed-off-by Andreas Dannenberg <[email protected]>

Reviewed-by Giulio Benetti <[email protected]>

Acked-by Andrew Davis <[email protected]>

Tested-by Bryan Brattlof <[email protected]>

Cc Romain Naour <[email protected]>

Reviewed-by Francois Perrad <[email protected]>

Reviewed-by Julien Olivain <[email protected]>

---

boot/ti-k3-image-gen/Config.in new file +0 -0

new file mode 100644
index 0000000000..910e1b99bc

boot/ti-k3-image-gen/Config.in new file +16 -0

+	  https://git.ti.com/cgit/k3-image-gen/k3-image-gen/
+
+if BR2_TARGET_TI_K3_IMAGE_GEN
+choice
+	prompt "Firmware type"
+	default BR2_TARGET_TI_K3_IMAGE_GEN_FW_TYPE_TIFS
+
+config BR2_TARGET_TI_K3_IMAGE_GEN_FW_TYPE_TIFS
+	bool "TIFS"
+	help
+	  Use firmware type TIFS for SoCs like AM62x and
+	  AM62Ax.
+
+config BR2_TARGET_TI_K3_IMAGE_GEN_FW_TYPE_TISCI
+	bool "TISCI"
+	help

boot/ti-k3-image-gen/Config.in new file +4 -0

+choice
+	prompt "SoC Security type"
+	default BR2_TARGET_TI_K3_IMAGE_GEN_SOC_TYPE_HS_FS
+

boot/ti-k3-image-gen/ti-k3-image-gen.hash new file +17 -0

new file mode 100644
index 0000000000..2c73927e0b
@@ -0,0 +1,17 @@ 
+# Locally calculated
+sha256 f89ea4b1f5c992455b1a682fde48359221b53f3294135df4bf20feea6aea90e4 k3-image-gen-08.06.00.007.tar.gz
+sha256 f012e8d000d711d0539e5b4c812fc1d3a59c10fc1e3d6ea155556f5b78286845 LICENSE
+
+sha256 eca3d0dca65ceabdf17c7efa6b0eb651d365c6056730aa1c67700b7fea2e8bd2 ti-fs-firmware-am62x-gp.bin
+sha256 9ed6089ca7d59e9e5919b0da92effe788138edef41682e0bf7eaea25a896a4f1 ti-fs-firmware-am62x-hs-cert.bin
+sha256 655b5ded62b63f26c17b3ae2f23ac3565ae91fbd7fba1b7b0a4cb7807467523b ti-fs-firmware-am62x-hs-enc.bin
+sha256 5efa229acd122685fa928170a3f2e39597cce0231fca10b03d9b4d519db2259f ti-fs-firmware-am62x-hs-fs-cert.bin
+sha256 0f49da5e616a95dc8573531799d20fa7697a000f88084d09f3f6f5a665d85680 ti-fs-firmware-am62x-hs-fs-enc.bin
+
+sha256 958fdb0613a1dc3a5cb90edf35b84981b94bd70de6255cdf5f220bce2a4b10ef ti-sci-firmware-am64x-gp.bin
+sha256 cfee8679183577392b513b317a4d9a6af47cde9a59ecbad758704e4bec38196c ti-sci-firmware-am64x-hs-cert.bin
+sha256 8760b70cc18cd5921d634ce226122aed5a28d64857d90f6ede40f2383dabd169 ti-sci-firmware-am64x-hs-enc.bin
+sha256 1e78b106a8c7acd1641863ef86946e0d7272ad9b2d0e7ce451936d36a14e70e7 ti-sci-firmware-am64x_sr2-hs-cert.bin
+sha256 c626bacd4abfbe4de1133b72568394a2e20dbe9a1623a3e77bae9f000e743bb4 ti-sci-firmware-am64x_sr2-hs-enc.bin
+sha256 1d48d758d9ed940fe4072bd5b024ec502c72782ce2ca1c085f043f104a62ca70 ti-sci-firmware-am64x_sr2-hs-fs-cert.bin
+sha256 1b22ba9ab5b94a9942e1f9c203b81733030c8bf4543a0aefffd200876a0c66eb ti-sci-firmware-am64x_sr2-hs-fs-enc.bin

boot/ti-k3-image-gen/ti-k3-image-gen.mk new file +6 -0

new file mode 100644
index 0000000000..b624f93771
@@ -0,0 +1,81 @@
+################################################################################
+#
+# ti-k3-image-gen
+#
+################################################################################
+

From: Xuanhao Shi <[email protected]>

This is the image generator that builds the initial boot binary, tiboot3.bin, for the R5 core on TI's K3 family of devices. This requires the R5 SPL output from the ti-k3-r5-loader package.

https://git.ti.com/cgit/k3-image-gen/k3-image-gen

Quoted 1 line

Quoted 1 line

ti-k3-image-gen 08.06.00.007 Installing to images directory

Hi Andreas and all,

Quoted 8 lines · Andreas Dannenberg via buildroot

From: Xuanhao Shi <[email protected]>

This is the image generator that builds the initial boot binary, tiboot3.bin, for the R5 core on TI's K3 family of devices. This requires the R5 SPL output from the ti-k3-r5-loader package.

https://git.ti.com/cgit/k3-image-gen/k3-image-gen

I was able to build with your patchset for am62x_sk_defconfig as included. I attempted to do a reproducible and per_package parallel build and ran into an error. We tend to use that for builds because it is significantly faster build times especially on a dedicated server.

Adding to the defconfig:
BR2_REPRODUCIBLE=y
BR2_PER_PACKAGE_DIRECTORIES=y

and I was running in to the below error:

Quoted 1 line

Quoted 1 line

Quoted 1 line

ti-k3-image-gen 08.06.00.007 Installing to images directory

cp /build_data/johnsonb/buildroot_ti/output/build/ti-k3-image-gen-08.06.00.007/tiboot3.bin /build_data/johnsonb/buildroot_ti/output/images
[19/30] Compiling C object
src/libwayland-server.so.0.21.0.p/wayland-shm.c.omake[5]: Leaving
directory '/build_data/johnsonb/buildroot_ti/output/build/util-linux-libs-2.38'
make[4]: Leaving directory '/build_data/johnsonb/buildroot_ti/output/build/util-linux-libs-2.38'
make[3]: Leaving directory '/build_data/johnsonb/buildroot_ti/output/build/util-linux-libs-2.38'
make[2]: Leaving directory '/build_data/johnsonb/buildroot_ti/output/build/util-linux-libs-2.38'
make[1]: Leaving directory '/build_data/johnsonb/buildroot_ti/output/build/util-linux-libs-2.38'
cp: cannot stat '/build_data/johnsonb/buildroot_ti/output/build/ti-k3-image-gen-08.06.00.007/tiboot3.bin':
No such file or directory
package/pkg-generic.mk:371: recipe for target '/build_data/johnsonb/buildroot_ti/output/build/ti-k3-image-gen-08.06.00.007/.stamp_images_installed' failed
make: *** [/build_data/johnsonb/buildroot_ti/output/build/ti-k3-image-gen-08.06.00.007/.stamp_images_installed] Error 1
make: *** Waiting for unfinished jobs....

I can see that file located there:
ls -al /build_data/johnsonb/buildroot_ti/output/build/ti-k3-image-gen-08.06.00.007/tiboot3.bin lrwxrwxrwx 1 johnsonb users 103 Aug 8 18:18 /build_data/johnsonb/buildroot_ti/output/build/ti-k3-image-gen-08.06.00.007/tiboot3.bin -> /build_data/johnsonb/buildroot_ti/output/build/ti-k3-image-gen-08.06.00.007/tiboot3-am62x-hs-fs-evm.bin

Might be something out of order or a missing dependency. I didn't dig into it too far, but I thought I would let you know.

Bryce

Hi Bryce, All,
first I wanted to say my apologies from the lack of progress on updating this series, the v9 rework got caught up in my summer break, and then TI has since released new U-Boot 2023.04 and Kernel 6.1-based SDKs for the

AM62x/AM64 devices which should now be the updated goal for this upstream effort. In addition to newer components this should actually help/simplify some of the boot image creation and secure boot related "TI quirks", for example we'll no longer need the ti-k3-image-gen and ti-core-secdev-k3 packages (yeey!) as those items will be taken care of by U-Boot (via binman). I'm planning on making time to pick this back up over the next few weeks and work on a v10 series with those changes plus applicable feedback that was provided on v9.

Certain TI K3 devices such as AM62x and AM62Ax require a Device Manager (DM) firmnware to be made available to the U-Boot build, which will get packaged into the "tispl.bin" image tree blob during A53 SPL build. Without that DM firmware U-Boot will not be functional. To support this, add a config option called BR2_TARGET_UBOOT_NEEDS_TI_K3_DM to enable this feature, and another option BR2_TARGET_UBOOT_TI_K3_DM_SOC to allow setting the name of the SOC which needs to match the corresponding folder name in the ti-linux-firmware Git repository.

Signed-off-by Andreas Dannenberg <[email protected]>

---
 boot/uboot/Config.in | 17 +++++++++++++++++
 boot/uboot/uboot.mk  | 16 ++++++++++++++++
 2 files changed, 33 insertions(+)

boot/uboot/Config.in +17 -0

index 085397d03d..7e1dd44196 100644
@@ -240,6 +240,23 @@ config BR2_TARGET_UBOOT_NEEDS_OPTEE_TEE
 	  U-Boot, and that the TEE variable pointing to OPTEE's
 	  tee.elf, is passed during the Buildroot build.
 
+config BR2_TARGET_UBOOT_NEEDS_TI_K3_DM
+	bool "U-Boot needs TI K3 Device Manager (DM)"
+	help
+	  Some TI K3 devices need the Device Manager (DM) firmware
+	  to be available for the U-Boot build. Currently supports FW
+	  from Git tag 08.06.00.006 by default.
+
+	  https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/tree/ti-dm?h=ti-linux-firmware
+
+config BR2_TARGET_UBOOT_TI_K3_DM_SOC
+	string "TI K3 Device Manager (DM) SOC Type"
+	depends on BR2_TARGET_UBOOT_NEEDS_TI_K3_DM
+	help
+	  Name of the TI K3 Device Manager (DM) SOC. This needs to
+	  match one of the SOC-specific folders in within the ti-dm
+	  folder of the ti-linux-firmware Git repository.
+
 config BR2_TARGET_UBOOT_NEEDS_OPENSBI
 	bool "U-Boot needs OpenSBI"
 	depends on BR2_TARGET_OPENSBI

boot/uboot/uboot.mk +5 -0

index 4eae8e95c3..48af69bd26 100644
@@ -184,6 +184,22 @@ UBOOT_DEPENDENCIES += optee-os
 UBOOT_MAKE_OPTS += TEE=$(BINARIES_DIR)/tee.elf
 endif
 
+ifeq ($(BR2_TARGET_UBOOT_NEEDS_TI_K3_DM),y)
+# Currently supports the FW from Git tag 08.06.00.006 by default
+TI_K3_DM_VERSION = 340194800a581baf976360386dfc7b5acab8d948
+TI_K3_DM_SITE = https://git.ti.com/processor-firmware/ti-linux-firmware/blobs/raw/$(TI_K3_DM_VERSION)/ti-dm/$(BR2_TARGET_UBOOT_TI_K3_DM_SOC)
+TI_K3_DM_SOURCE = ipc_echo_testb_mcu1_0_release_strip.xer5f

boot/uboot/uboot.mk +0 -0

 ifeq ($(BR2_TARGET_UBOOT_NEEDS_OPENSBI),y)
 UBOOT_DEPENDENCIES += opensbi
 UBOOT_MAKE_OPTS += OPENSBI=$(BINARIES_DIR)/fw_dynamic.bin

Signature · 6 lines

2.34.1

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

On 2023-06-22 11:02 -0500, Andreas Dannenberg via buildroot spake thusly:

Quoted 5 lines

boot/uboot/uboot.mk +5 -0

+ifeq ($(BR2_TARGET_UBOOT_NEEDS_TI_K3_DM),y)
+# Currently supports the FW from Git tag 08.06.00.006 by default
+TI_K3_DM_VERSION = 340194800a581baf976360386dfc7b5acab8d948
+TI_K3_DM_SITE = https://git.ti.com/processor-firmware/ti-linux-firmware/blobs/raw/$(TI_K3_DM_VERSION)/ti-dm/$(BR2_TARGET_UBOOT_TI_K3_DM_SOC)
+TI_K3_DM_SOURCE = ipc_echo_testb_mcu1_0_release_strip.xer5f

boot/uboot/uboot.mk UBOOT_DEPENDENCIES += optee-os · line 201

Quoted 10 lines

boot/uboot/uboot.mk +10 -0

+# This is not really nice but disable the hash check for the DM FW file. Main
+# reason is all those DM FW files for different SoCs have the same(!) name in
+# the Git repository they reside in, so it would be more difficult to distinguish
+# between them for hash checking purposes. To work around this let's just
+# rely and trust the official Git repo at ti.com is known-good which is also
+# accessed through a secure transport.
+BR_NO_CHECK_HASH_FOR += $(TI_K3_DM_SOURCE)
+UBOOT_EXTRA_DOWNLOADS = $(TI_K3_DM_SITE)/$(TI_K3_DM_SOURCE)
+UBOOT_MAKE_OPTS += DM=$(UBOOT_DL_DIR)/$(TI_K3_DM_SOURCE)
+endif

I again am not very fond of this injecting extra downloads n uboot. I'd rather we have a separate package, ti-linux-firmware. That way, it can be used by both uboot and ti-k3-image-gen.

The ti-linux-firmware repository is not small (git clone reports 750MiB today) but the repository exposes snapshots, so that is a bit more easy on the networks connection (althoiugh we should take the .gz, not the .xz, as the on-the-fly compression is much slower for xz than gz).

Then it is again just a matter of ti-linux-firmware copying the appropriate blobs into $(BINARIES_DIR) and then uboot grabbing what's necessary.

Regards,
Yann E. MORIN.

Quoted 10 lines

ifeq ($(BR2_TARGET_UBOOT_NEEDS_OPENSBI),y) UBOOT_DEPENDENCIES += opensbi
UBOOT_MAKE_OPTS += OPENSBI=$(BINARIES_DIR)/fw_dynamic.bin

Signature · 6 lines

2.34.1

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

Signature · 10 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

From: Xuanhao Shi <[email protected]>

Adds support for TI's SK-AM64 board by introducing the am64x_sk_defconfig file and related support files.

More information about the board can be found at:
https://www.ti.com/tool/SK-AM64

Signed-off-by Xuanhao Shi <[email protected]>

Signed-off-by Anand Gadiyar <[email protected]>

Signed-off-by Andreas Dannenberg <[email protected]>

Reviewed-by Giulio Benetti <[email protected]>

Acked-by Andrew Davis <[email protected]>

Tested-by Bryan Brattlof <[email protected]>

Cc Romain Naour <[email protected]>

Reviewed-by Francois Perrad <[email protected]>

Reviewed-by Julien Olivain <[email protected]>

---
 DEVELOPERS                     |  4 ++++
 board/ti/am64x_sk/genimage.cfg | 27 +++++++++++++++++++++
 board/ti/am64x_sk/readme.txt   | 26 ++++++++++++++++++++
 configs/am64x_sk_defconfig     | 44 ++++++++++++++++++++++++++++++++++
 4 files changed, 101 insertions(+)
 create mode 100644 board/ti/am64x_sk/genimage.cfg
 create mode 100644 board/ti/am64x_sk/readme.txt
 create mode 100644 configs/am64x_sk_defconfig

DEVELOPERS +4 -0

index 7ed9f040cc..a4d729983b 100644
@@ -129,8 +129,10 @@ F: package/libxmlrpc/
 F:     package/python-docopt/
 
 N:     Anand Gadiyar <[email protected]>
+F:     board/ti/am64x_sk/
 F:     boot/ti-k3-image-gen/
 F:     boot/ti-k3-r5-loader/
+F:     configs/am64x_sk_defconfig
 
 N:     André Zwing <[email protected]>
 F:     package/libkrb5/

@@ -3021,8 +3023,10 @@ N:       Wojciech Niziński <[email protected]>
 F:     package/fwup/
 
 N:     Xuanhao Shi <[email protected]>
+F:     board/ti/am64x_sk/
 F:     boot/ti-k3-image-gen/
 F:     boot/ti-k3-r5-loader/
+F:     configs/am64x_sk_defconfig
 
 N:     Yair Ben Avraham <[email protected]>
 F:     package/casync/

board/ti/am64x_sk/genimage.cfg new file +27 -0

new file mode 100644
index 0000000000..26304fe98f
@@ -0,0 +1,27 @@
+image boot.vfat {
+       vfat {
+               files = {
+                       "tiboot3.bin",
+                       "tispl.bin",
+                       "u-boot.img",
+               }
+       }
+
+       size = 16M
+}
+
+image sdcard.img {
+       hdimage {
+       }
+
+       partition u-boot {
+               partition-type = 0xC
+               bootable = "true"
+               image = "boot.vfat"
+       }
+
+       partition rootfs {
+               partition-type = 0x83
+               image = "rootfs.ext4"
+       }
+}

board/ti/am64x_sk/readme.txt new file +26 -0

new file mode 100644
index 0000000000..fe83c675f5
@@ -0,0 +1,26 @@
+Texas Instuments SK-AM64 Test and Development Board
+
+Description
+===========
+This configuration will build a complete image for the TI SK-AM64 board.
+
+How to Build
+============
+Select the default configuration for the target:
+$ make am64x_sk_defconfig
+
+Optional: modify the configuration:
+$ make menuconfig
+
+Build:
+$ make
+
+To copy the resultimg output image file to an SD card use dd:
+$ dd if=output/images/sdcard.img of=/dev/sdX bs=1M
+
+How to Run
+==========
+Insert the SD card into the SK-AM62 board, and power it up through
+the USB Type-C connector. The system should come up. You can use
+a micro-USB cable to connect to the connector labeled DEBUG CONSOLE
+to communicate with the board.

configs/am64x_sk_defconfig new file +0 -0

new file mode 100644
index 0000000000..411b3d5b0f

configs/am64x_sk_defconfig new file +16 -0

+BR2_PACKAGE_LINUX_FIRMWARE=y
+BR2_PACKAGE_LINUX_FIRMWARE_TI_WL18XX=y
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION_VALUE="v2.7.0"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="k3"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_TARGET_BOARD="lite"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL32_OPTEE=y
+BR2_TARGET_OPTEE_OS=y
+BR2_TARGET_OPTEE_OS_PLATFORM="k3"
+BR2_TARGET_TI_K3_IMAGE_GEN=y
+BR2_TARGET_TI_K3_IMAGE_GEN_FW_TYPE_TISCI=y
+BR2_TARGET_TI_K3_IMAGE_GEN_SOC="am64x"

configs/am64x_sk_defconfig new file +10 -1

+BR2_TARGET_UBOOT_NEEDS_OPENSSL=y
+BR2_TARGET_UBOOT_NEEDS_ATF_BL31=y
+# BR2_TARGET_UBOOT_FORMAT_BIN is not set
+BR2_TARGET_UBOOT_FORMAT_IMG=y
+BR2_TARGET_UBOOT_SPL=y
+BR2_TARGET_UBOOT_SPL_NAME="tispl.bin"
+BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="TEE=$(BINARIES_DIR)/tee-pager_v2.bin"
+BR2_PACKAGE_HOST_DOSFSTOOLS=y
+BR2_PACKAGE_HOST_GENIMAGE=y
+BR2_PACKAGE_HOST_MTOOLS=y
--

2.34.1

From: Xuanhao Shi <[email protected]>

Adds support for TI's SK-AM64 board by introducing the am64x_sk_defconfig file and related support files.

More information about the board can be found at:
https://www.ti.com/tool/SK-AM64

Signed-off-by Xuanhao Shi <[email protected]>

Signed-off-by Anand Gadiyar <[email protected]>

Signed-off-by Andreas Dannenberg <[email protected]>

Reviewed-by Giulio Benetti <[email protected]>

Acked-by Andrew Davis <[email protected]>

Tested-by Bryan Brattlof <[email protected]>

Cc Romain Naour <[email protected]>

Reviewed-by Francois Perrad <[email protected]>

Reviewed-by Julien Olivain <[email protected]>

---

configs/am64x_sk_defconfig new file +40 -0

+BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
+BR2_LINUX_KERNEL_DTS_SUPPORT=y
+BR2_LINUX_KERNEL_INTREE_DTS_NAME="ti/k3-am642-sk"
+BR2_LINUX_KERNEL_INSTALL_TARGET=y
+BR2_PACKAGE_LINUX_FIRMWARE=y
+BR2_PACKAGE_LINUX_FIRMWARE_TI_WL18XX=y
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION_VALUE="v2.7.0"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="k3"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_TARGET_BOARD="lite"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL32_OPTEE=y
+BR2_TARGET_OPTEE_OS=y
+BR2_TARGET_OPTEE_OS_PLATFORM="k3"
+BR2_TARGET_TI_K3_IMAGE_GEN=y
+BR2_TARGET_TI_K3_IMAGE_GEN_FW_TYPE_TISCI=y
+BR2_TARGET_TI_K3_IMAGE_GEN_SOC="am64x"
+BR2_TARGET_TI_K3_IMAGE_GEN_SOC_TYPE_GP=y
+BR2_TARGET_TI_K3_IMAGE_GEN_CONFIG="evm"
+BR2_TARGET_TI_K3_R5_LOADER=y
+BR2_TARGET_TI_K3_R5_LOADER_BOARD_DEFCONFIG="am64x_evm_r5"
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2022.10"
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="am64x_evm_a53"
+BR2_TARGET_UBOOT_NEEDS_DTC=y
+BR2_TARGET_UBOOT_NEEDS_OPENSSL=y
+BR2_TARGET_UBOOT_NEEDS_ATF_BL31=y
+# BR2_TARGET_UBOOT_FORMAT_BIN is not set
+BR2_TARGET_UBOOT_FORMAT_IMG=y
+BR2_TARGET_UBOOT_SPL=y
+BR2_TARGET_UBOOT_SPL_NAME="tispl.bin"
+BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="TEE=$(BINARIES_DIR)/tee-pager_v2.bin"
+BR2_PACKAGE_HOST_DOSFSTOOLS=y
+BR2_PACKAGE_HOST_GENIMAGE=y
+BR2_PACKAGE_HOST_MTOOLS=y

Signature · 6 lines

2.34.1

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

From: Xuanhao Shi <[email protected]>

Adds support for TI's SK-AM62 board by introducing the am62x_sk_defconfig file and related support files.

More information about the board can be found at:
https://www.ti.com/tool/SK-AM62

Signed-off-by Xuanhao Shi <[email protected]>

Signed-off-by Andreas Dannenberg <[email protected]>

---
 DEVELOPERS                     |  4 +++
 board/ti/am62x_sk/genimage.cfg | 27 ++++++++++++++++++++
 board/ti/am62x_sk/readme.txt   | 26 ++++++++++++++++++++
 configs/am62x_sk_defconfig     | 45 ++++++++++++++++++++++++++++++++++
 4 files changed, 102 insertions(+)
 create mode 100644 board/ti/am62x_sk/genimage.cfg
 create mode 100644 board/ti/am62x_sk/readme.txt
 create mode 100644 configs/am62x_sk_defconfig

DEVELOPERS +4 -0

index a4d729983b..8ce903b294 100644
@@ -129,9 +129,11 @@ F: package/libxmlrpc/
 F:     package/python-docopt/
 
 N:     Anand Gadiyar <[email protected]>
+F:     board/ti/am62x_sk/
 F:     board/ti/am64x_sk/
 F:     boot/ti-k3-image-gen/
 F:     boot/ti-k3-r5-loader/
+F:     configs/am62x_sk_defconfig
 F:     configs/am64x_sk_defconfig
 
 N:     André Zwing <[email protected]>

@@ -3023,9 +3025,11 @@ N:       Wojciech Niziński <[email protected]>
 F:     package/fwup/
 
 N:     Xuanhao Shi <[email protected]>
+F:     board/ti/am62x_sk/
 F:     board/ti/am64x_sk/
 F:     boot/ti-k3-image-gen/
 F:     boot/ti-k3-r5-loader/
+F:     configs/am62x_sk_defconfig
 F:     configs/am64x_sk_defconfig
 
 N:     Yair Ben Avraham <[email protected]>

board/ti/am62x_sk/genimage.cfg new file +27 -0

new file mode 100644
index 0000000000..26304fe98f
@@ -0,0 +1,27 @@
+image boot.vfat {
+       vfat {
+               files = {
+                       "tiboot3.bin",
+                       "tispl.bin",
+                       "u-boot.img",
+               }
+       }
+
+       size = 16M
+}
+
+image sdcard.img {
+       hdimage {
+       }
+
+       partition u-boot {
+               partition-type = 0xC
+               bootable = "true"
+               image = "boot.vfat"
+       }
+
+       partition rootfs {
+               partition-type = 0x83
+               image = "rootfs.ext4"
+       }
+}

board/ti/am62x_sk/readme.txt new file +26 -0

new file mode 100644
index 0000000000..ccbb24896b
@@ -0,0 +1,26 @@
+Texas Instuments SK-AM62 Test and Development Board
+
+Description
+===========
+This configuration will build a complete image for the TI SK-AM62 board.
+
+How to Build
+============
+Select the default configuration for the target:
+$ make am62x_sk_defconfig
+
+Optional: modify the configuration:
+$ make menuconfig
+
+Build:
+$ make
+
+To copy the resultimg output image file to an SD card use dd:
+$ dd if=output/images/sdcard.img of=/dev/sdX bs=1M
+
+How to Run
+==========
+Insert the SD card into the SK-AM62 board, and power it up through
+the USB Type-C connector. The system should come up. You can use
+a micro-USB cable to connect to the connector labeled UART to
+communicate with the board.

configs/am62x_sk_defconfig new file +0 -0

new file mode 100644
index 0000000000..083720f512

configs/am62x_sk_defconfig new file +37 -1

+BR2_PACKAGE_LINUX_FIRMWARE=y
+BR2_PACKAGE_LINUX_FIRMWARE_TI_WL18XX=y
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_TARGET_ROOTFS_EXT2_SIZE="256M"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION_VALUE="v2.7.0"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="k3"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_TARGET_BOARD="lite"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL32_OPTEE=y
+BR2_TARGET_OPTEE_OS=y
+BR2_TARGET_OPTEE_OS_PLATFORM="k3"
+BR2_TARGET_TI_K3_IMAGE_GEN=y
+BR2_TARGET_TI_K3_IMAGE_GEN_SOC="am62x"
+BR2_TARGET_TI_K3_IMAGE_GEN_SOC_TYPE_GP=y
+BR2_TARGET_TI_K3_IMAGE_GEN_CONFIG="evm"
+BR2_TARGET_TI_K3_R5_LOADER=y
+BR2_TARGET_TI_K3_R5_LOADER_BOARD_DEFCONFIG="am62x_evm_r5"
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2022.10"
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="am62x_evm_a53"
+BR2_TARGET_UBOOT_NEEDS_DTC=y
+BR2_TARGET_UBOOT_NEEDS_OPENSSL=y
+BR2_TARGET_UBOOT_NEEDS_ATF_BL31=y
+BR2_TARGET_UBOOT_NEEDS_TI_K3_DM=y
+BR2_TARGET_UBOOT_TI_K3_DM_SOC="am62xx"
+# BR2_TARGET_UBOOT_FORMAT_BIN is not set
+BR2_TARGET_UBOOT_FORMAT_IMG=y
+BR2_TARGET_UBOOT_SPL=y
+BR2_TARGET_UBOOT_SPL_NAME="tispl.bin"
+BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="TEE=$(BINARIES_DIR)/tee-pager_v2.bin"
+BR2_PACKAGE_HOST_DOSFSTOOLS=y
+BR2_PACKAGE_HOST_GENIMAGE=y
+BR2_PACKAGE_HOST_MTOOLS=y
--

2.34.1

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

Quoted 124 lines · Andreas Dannenberg via buildroot

From: Xuanhao Shi <[email protected]>

Adds support for TI's SK-AM62 board by introducing the am62x_sk_defconfig file and related support files.

More information about the board can be found at:
https://www.ti.com/tool/SK-AM62

Signed-off-by Xuanhao Shi <[email protected]>

Signed-off-by Andreas Dannenberg <[email protected]>

---
 DEVELOPERS                     |  4 +++
 board/ti/am62x_sk/genimage.cfg | 27 ++++++++++++++++++++
 board/ti/am62x_sk/readme.txt   | 26 ++++++++++++++++++++
 configs/am62x_sk_defconfig     | 45 ++++++++++++++++++++++++++++++++++
 4 files changed, 102 insertions(+)
 create mode 100644 board/ti/am62x_sk/genimage.cfg
 create mode 100644 board/ti/am62x_sk/readme.txt
 create mode 100644 configs/am62x_sk_defconfig

DEVELOPERS +4 -0

index a4d729983b..8ce903b294 100644
@@ -129,9 +129,11 @@ F: package/libxmlrpc/
 F:     package/python-docopt/
 
 N:     Anand Gadiyar <[email protected]>
+F:     board/ti/am62x_sk/
 F:     board/ti/am64x_sk/
 F:     boot/ti-k3-image-gen/
 F:     boot/ti-k3-r5-loader/
+F:     configs/am62x_sk_defconfig
 F:     configs/am64x_sk_defconfig
 
 N:     André Zwing <[email protected]>

@@ -3023,9 +3025,11 @@ N:       Wojciech Niziński <[email protected]>
 F:     package/fwup/
 
 N:     Xuanhao Shi <[email protected]>
+F:     board/ti/am62x_sk/
 F:     board/ti/am64x_sk/
 F:     boot/ti-k3-image-gen/
 F:     boot/ti-k3-r5-loader/
+F:     configs/am62x_sk_defconfig
 F:     configs/am64x_sk_defconfig
 
 N:     Yair Ben Avraham <[email protected]>

board/ti/am62x_sk/genimage.cfg new file +27 -0

new file mode 100644
index 0000000000..26304fe98f
@@ -0,0 +1,27 @@
+image boot.vfat {
+       vfat {
+               files = {
+                       "tiboot3.bin",
+                       "tispl.bin",
+                       "u-boot.img",
+               }
+       }
+
+       size = 16M
+}
+
+image sdcard.img {
+       hdimage {
+       }
+
+       partition u-boot {
+               partition-type = 0xC
+               bootable = "true"
+               image = "boot.vfat"
+       }
+
+       partition rootfs {
+               partition-type = 0x83
+               image = "rootfs.ext4"
+       }
+}

board/ti/am62x_sk/readme.txt new file +26 -0

new file mode 100644
index 0000000000..ccbb24896b
@@ -0,0 +1,26 @@
+Texas Instuments SK-AM62 Test and Development Board
+
+Description
+===========
+This configuration will build a complete image for the TI SK-AM62 board.
+
+How to Build
+============
+Select the default configuration for the target:
+$ make am62x_sk_defconfig
+
+Optional: modify the configuration:
+$ make menuconfig
+
+Build:
+$ make
+
+To copy the resultimg output image file to an SD card use dd:
+$ dd if=output/images/sdcard.img of=/dev/sdX bs=1M
+
+How to Run
+==========
+Insert the SD card into the SK-AM62 board, and power it up through
+the USB Type-C connector. The system should come up. You can use
+a micro-USB cable to connect to the connector labeled UART to
+communicate with the board.

configs/am62x_sk_defconfig new file +4 -0

new file mode 100644
index 0000000000..083720f512
@@ -0,0 +1,45 @@
+BR2_aarch64=y
+BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh"
+BR2_ROOTFS_POST_SCRIPT_ARGS="-c board/ti/am62x_sk/genimage.cfg"
+BR2_LINUX_KERNEL=y

configs/am62x_sk_defconfig line 8

Quoted 5 lines

configs/am62x_sk_defconfig new file +4 -0

+BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG=y
+BR2_LINUX_KERNEL_DTS_SUPPORT=y
+BR2_LINUX_KERNEL_INTREE_DTS_NAME="ti/k3-am625-sk"
+BR2_LINUX_KERNEL_INSTALL_TARGET=y

BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y is missing at least at the end of the serie.

François

Quoted 40 lines

configs/am62x_sk_defconfig new file +37 -1

+BR2_PACKAGE_LINUX_FIRMWARE=y
+BR2_PACKAGE_LINUX_FIRMWARE_TI_WL18XX=y
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_TARGET_ROOTFS_EXT2_SIZE="256M"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION=y
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_CUSTOM_VERSION_VALUE="v2.7.0"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_PLATFORM="k3"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_TARGET_BOARD="lite"
+BR2_TARGET_ARM_TRUSTED_FIRMWARE_BL32_OPTEE=y
+BR2_TARGET_OPTEE_OS=y
+BR2_TARGET_OPTEE_OS_PLATFORM="k3"
+BR2_TARGET_TI_K3_IMAGE_GEN=y
+BR2_TARGET_TI_K3_IMAGE_GEN_SOC="am62x"
+BR2_TARGET_TI_K3_IMAGE_GEN_SOC_TYPE_GP=y
+BR2_TARGET_TI_K3_IMAGE_GEN_CONFIG="evm"
+BR2_TARGET_TI_K3_R5_LOADER=y
+BR2_TARGET_TI_K3_R5_LOADER_BOARD_DEFCONFIG="am62x_evm_r5"
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION=y
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2022.10"
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="am62x_evm_a53"
+BR2_TARGET_UBOOT_NEEDS_DTC=y
+BR2_TARGET_UBOOT_NEEDS_OPENSSL=y
+BR2_TARGET_UBOOT_NEEDS_ATF_BL31=y
+BR2_TARGET_UBOOT_NEEDS_TI_K3_DM=y
+BR2_TARGET_UBOOT_TI_K3_DM_SOC="am62xx"
+# BR2_TARGET_UBOOT_FORMAT_BIN is not set
+BR2_TARGET_UBOOT_FORMAT_IMG=y
+BR2_TARGET_UBOOT_SPL=y
+BR2_TARGET_UBOOT_SPL_NAME="tispl.bin"
+BR2_TARGET_UBOOT_CUSTOM_MAKEOPTS="TEE=$(BINARIES_DIR)/tee-pager_v2.bin"
+BR2_PACKAGE_HOST_DOSFSTOOLS=y
+BR2_PACKAGE_HOST_GENIMAGE=y
+BR2_PACKAGE_HOST_MTOOLS=y
--

2.34.1

Quoted 5 lines

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

Switch the following projects to using the same Git source repos and commit IDs that are used to build the TI SDK v8.6 for AM62x and AM64x devices to establish a baseline for comparable functionality:

* TI Linux Kernel v5.10

* TI U-Boot v2021.01
* ARM Trusted Firmware
* OP-TEE

For the Linux Kernel this also includes switching the defconfig to a new one that is generated with the ti_config_fragments/defconfig_builder.sh tool that is part of the respective ti-linux-5.10.y repository.

Signed-off-by Andreas Dannenberg <[email protected]>

---
 .../ti/am62x_sk/ti_sdk_arm64_debug_defconfig  | 1991 +++++++++++++++++
 .../am62x_sk/ti_sdk_arm64_release_defconfig   | 1894 ++++++++++++++++
 .../ti/am64x_sk/ti_sdk_arm64_debug_defconfig  | 1991 +++++++++++++++++
 .../am64x_sk/ti_sdk_arm64_release_defconfig   | 1894 ++++++++++++++++

Andreas, All,

On 2023-06-22 11:02 -0500, Andreas Dannenberg via buildroot spake thusly:

Quoted 4 lines

Switch the following projects to using the same Git source repos and commit IDs that are used to build the TI SDK v8.6 for AM62x and AM64x devices to establish a baseline for comparable functionality:

Quoted 1 line

* TI Linux Kernel v5.10

So this means going from a 6.3 kernel back to a 5.10 (the current latest if 6.3, which is what is used in the defconfigs from the two previous patches). That's a bit unfortunate.

Do you have plans to update to a more recent kernel in the (near) future? Can't we keep using 6.3 anyway?

Quoted 9 lines

* TI U-Boot v2021.01
* ARM Trusted Firmware
* OP-TEE

For the Linux Kernel this also includes switching the defconfig to a new one that is generated with the ti_config_fragments/defconfig_builder.sh tool that is part of the respective ti-linux-5.10.y repository.

Quoted 6 lines

Signed-off-by Andreas Dannenberg <[email protected]>

---
  .../ti/am62x_sk/ti_sdk_arm64_debug_defconfig  | 1991 +++++++++++++++++
  .../am62x_sk/ti_sdk_arm64_release_defconfig   | 1894 ++++++++++++++++
  .../ti/am64x_sk/ti_sdk_arm64_debug_defconfig  | 1991 +++++++++++++++++
  .../am64x_sk/ti_sdk_arm64_release_defconfig   | 1894 ++++++++++++++++

Those are really big defconfigs... Why can't we use the defconfig anymore?

Also, for each board, you are providing two defconfigs, one release and one debug, but only one is used. We don;t want to carry files that are unused, because they are going to bitrot sooner than later.

Just add the two defconfigs that are needed, one for each board.

Also, I think it would be preferrable that the files be named linux.config (.config even though it is a defconfig, yes), like we do for the other boards (there are slight deviations, like adding the lernel version, or a 'nommu', but only one is named after the board).

Regards,
Yann E. MORIN.

[--SNIP--]

configs/am62x_sk_defconfig line 2

Quoted 7 lines

configs/am62x_sk_defconfig +1 -0

index 083720f512..0b196f4cce 100644
@@ -1,8 +1,12 @@
  BR2_aarch64=y
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_10=y

This is out-of-order.

Either you have manually-edited defconfigs, and then you should provide comments in there, like (see existing defconfigs for exampleS):

# Linux headers same as kernel, a 5.10 series BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_5_10=y

or you have a defconfig that is fully auto-gemnerated with save-defconfig.

I prefer the latter, but other maintainers may prefer the former..

Regards,
Yann E. MORIN.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Arnout" == Arnout Vandecappelle <[email protected]> writes:

Quoted 7 lines

Quoted 1 line

* TI Linux Kernel v5.10

So this means going from a 6.3 kernel back to a 5.10 (the current latest
if 6.3, which is what is used in the defconfigs from the two previous patches). That's a bit unfortunate.
Do you have plans to update to a more recent kernel in the (near) future? Can't we keep using 6.3 anyway?

We don't actually have a clear policy on whether to use upstream or vendor kernels for the defconfigs. We have a few boards with both,
but IMHO that's not a great approach either.

Personally, I think it makes sense to focus on vendor kernels for the defconfigs. Using upstream is generally easy, you just have to find
the appropriate device tree. But for the vendor kernel, you have to find the repository, which branch is "current", and often also make sure you sync up with U-Boot and OP-TEE etc. versions. @Andreas don't take this as law, though, it's just personal opinion.

That said, I think for each board we should look at what the vendor kernel really brings. If everything, including GPU, is working with
the upstream kernel, it doesn't make sense to use the vendor kernel. I don't know if that's the case in this specific situation.

Yann, Peter, Romain, Thomas, what do you think?

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Arnout" == Arnout Vandecappelle <[email protected]> writes:

Hi,

Quoted 12 lines

Quoted 7 lines

Quoted 1 line

* TI Linux Kernel v5.10

So this means going from a 6.3 kernel back to a 5.10 (the current latest
if 6.3, which is what is used in the defconfigs from the two previous patches). That's a bit unfortunate.
Do you have plans to update to a more recent kernel in the (near) future? Can't we keep using 6.3 anyway?

We don't actually have a clear policy on whether to use upstream or vendor kernels for the defconfigs. We have a few boards with both,
but IMHO that's not a great approach either.

Quoted 6 lines

Personally, I think it makes sense to focus on vendor kernels for the defconfigs. Using upstream is generally easy, you just have to find
the appropriate device tree. But for the vendor kernel, you have to find the repository, which branch is "current", and often also make sure you sync up with U-Boot and OP-TEE etc. versions. @Andreas don't take this as law, though, it's just personal opinion.

Correct, but given the poor quality of most vendor kernels, using a board with mainline is typically a lot nicer (if the IP blocks you care about are supported naturally).

Same about the support, E.G. we had issues with various vendor kernels/bootloaders breaking with newer toolchain versions.

Quoted 4 lines

That said, I think for each board we should look at what the vendor kernel really brings. If everything, including GPU, is working with
the upstream kernel, it doesn't make sense to use the vendor kernel. I don't know if that's the case in this specific situation.

Quoted 1 line

Yann, Peter, Romain, Thomas, what do you think?

Agreed. I would in general say go for mainline, unless there is no decent support in mainline. I would not necessarily think that GPU support is a requirement, but at least the things used by the defconfig (E.G. storage, serial, network).

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Arnout" == Arnout Vandecappelle <[email protected]> writes:

Quoted 3 lines

Correct, but given the poor quality of most vendor kernels, using a board with mainline is typically a lot nicer (if the IP blocks you care about are supported naturally).

I'm not sure that you can claim most vendor kernels are poor quality. At least NXP and Microchip have decent vendor
kernels. Conversely, when vendor kernels are horrible, mainline is often not super usable either (because, of course, those vendors don't invest in upstreaming either).

Quoted 8 lines

Same about the support, E.G. we had issues with various vendor kernels/bootloaders breaking with newer toolchain versions.

Quoted 5 lines

That said, I think for each board we should look at what the vendor kernel really brings. If everything, including GPU, is working with
the upstream kernel, it doesn't make sense to use the vendor kernel. I don't know if that's the case in this specific situation.
Yann, Peter, Romain, Thomas, what do you think?

Quoted 4 lines

Agreed. I would in general say go for mainline, unless there is no decent support in mainline. I would not necessarily think that GPU support is a requirement, but at least the things used by the defconfig (E.G. storage, serial, network).

That's exactly the opposite of what I was saying, so not agreed I guess :-)

Quoted 7 lines

Andreas, All,

On 2023-06-22 11:02 -0500, Andreas Dannenberg via buildroot spake thusly:

Quoted 4 lines

Switch the following projects to using the same Git source repos and commit IDs that are used to build the TI SDK v8.6 for AM62x and AM64x devices to establish a baseline for comparable functionality:

Quoted 8 lines

Quoted 1 line

* TI Linux Kernel v5.10

So this means going from a 6.3 kernel back to a 5.10 (the current latest if 6.3, which is what is used in the defconfigs from the two previous patches). That's a bit unfortunate.

Do you have plans to update to a more recent kernel in the (near) future? Can't we keep using 6.3 anyway?

We don't actually have a clear policy on whether to use upstream or vendor
kernels for the defconfigs. We have a few boards with both, but IMHO that's not a great approach either.

Personally, I think it makes sense to focus on vendor kernels for the
defconfigs. Using upstream is generally easy, you just have to find the appropriate device tree. But for the vendor kernel, you have to find the repository, which branch is "current", and often also make sure you sync up with U-Boot and OP-TEE etc. versions. @Andreas don't take this as law, though, it's just personal opinion.

That said, I think for each board we should look at what the vendor kernel
really brings. If everything, including GPU, is working with the upstream kernel, it doesn't make sense to use the vendor kernel. I don't know if that's the case in this specific situation.

Yann, Peter, Romain, Thomas, what do you think?

The ti-core-secdev-k3 package is used to provide binary image signing tools and keys to the build process needed to build boot artifacts for the secure boot flow on TI K3 platform "High Security" SoCs (device variants "HS-FS" and "HS-SE"). This package is not needed building for "General Purpose" ("GP") SoC variants.

This commit also updates the ti-k3-image-gen, ti-k3-r5-loader, and uboot packages which are all used as part of the boot flow of TI K3 platform devices to make use of the ti-core-secdev-k3 package if enabled.

Note that although the use of the underlying 'core-secdev-k3' tool provided by TI is required to generate bootable images for HS-FS and HS-SE device variants, the use of this Buildroot package itself should remain optional, hence no hard dependencies are being established. The reason is that a user often wants to provide their own signing tool through the use of the TI_SECURE_DEV_PKG environmental variable set outside Buildroot on their specific build machine, especially for HS-SE device variants where the signing tool would contain the user's private keys.

https://git.ti.com/cgit/security-development-tools/core-secdev-k3

Signed-off-by Andreas Dannenberg <[email protected]>

---
 boot/ti-k3-image-gen/ti-k3-image-gen.mk       | 10 ++++++
 boot/ti-k3-r5-loader/ti-k3-r5-loader.mk       | 10 ++++++
 boot/uboot/uboot.mk                           | 10 ++++++
 package/Config.in.host                        |  1 +
 package/ti-core-secdev-k3/Config.in.host      | 11 +++++++
 .../ti-core-secdev-k3/ti-core-secdev-k3.hash  |  3 ++
 .../ti-core-secdev-k3/ti-core-secdev-k3.mk    | 31 +++++++++++++++++++
 7 files changed, 76 insertions(+)
 create mode 100644 package/ti-core-secdev-k3/Config.in.host
 create mode 100644 package/ti-core-secdev-k3/ti-core-secdev-k3.hash
 create mode 100644 package/ti-core-secdev-k3/ti-core-secdev-k3.mk

boot/ti-k3-image-gen/ti-k3-image-gen.mk +10 -0

index b624f93771..57202d6918 100644
@@ -70,6 +70,16 @@ TI_K3_IMAGE_GEN_MAKE_OPTS = \
        O=$(@D)/tmp \
        BIN_DIR=$(@D)
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+TI_K3_IMAGE_GEN_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 define TI_K3_IMAGE_GEN_BUILD_CMDS
        $(TI_K3_IMAGE_GEN_MAKE) -C $(@D) $(TI_K3_IMAGE_GEN_MAKE_OPTS)
 endef

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +10 -0

index 341888623e..8311e1b401 100644
@@ -67,6 +67,16 @@ TI_K3_R5_LOADER_MAKE_OPTS = \
        HOSTCC="$(HOSTCC) $(subst -I/,-isystem /,$(subst -I /,-isystem /,$(HOST_CFLAGS)))" \
        HOSTLDFLAGS="$(HOST_LDFLAGS)"
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+TI_K3_R5_LOADER_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 define TI_K3_R5_LOADER_BUILD_CMDS
        $(TARGET_CONFIGURE_OPTS) $(TI_K3_R5_LOADER_MAKE) -C $(@D) $(TI_K3_R5_LOADER_MAKE_OPTS)
 endef

boot/uboot/uboot.mk +10 -0

index 48af69bd26..472fec8619 100644
@@ -184,6 +184,16 @@ UBOOT_DEPENDENCIES += optee-os
 UBOOT_MAKE_OPTS += TEE=$(BINARIES_DIR)/tee.elf
 endif
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+UBOOT_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 ifeq ($(BR2_TARGET_UBOOT_NEEDS_TI_K3_DM),y)
 # Currently supports the FW from Git tag 08.06.00.006 by default
 TI_K3_DM_VERSION = 340194800a581baf976360386dfc7b5acab8d948

package/Config.in.host +1 -0

index dcadbfdfc1..eed39a4102 100644
@@ -103,6 +103,7 @@ menu "Host utilities"
        source "package/systemd/Config.in.host"
        source "package/tegrarcm/Config.in.host"
        source "package/ti-cgt-pru/Config.in.host"
+       source "package/ti-core-secdev-k3/Config.in.host"
        source "package/uboot-tools/Config.in.host"
        source "package/util-linux/Config.in.host"
        source "package/utp_com/Config.in.host"

package/ti-core-secdev-k3/Config.in.host new file +11 -0

new file mode 100644
index 0000000000..364619d824
@@ -0,0 +1,11 @@
+config BR2_PACKAGE_HOST_TI_CORE_SECDEV_K3
+       bool "host ti-core-secdev-k3"
+       help
+         ti-core-secdev-k3 is used to provide binary image signing
+         tools and keys to the build process needed to build boot
+         artifacts for the secure boot flow on TI K3 platform
+         "High Security" SoCs (device variants "HS-FS" and "HS-SE").
+         This package is not needed building for "General Purpose"
+         ("GP") SoC variants.
+
+         https://git.ti.com/cgit/security-development-tools/core-secdev-k3

package/ti-core-secdev-k3/ti-core-secdev-k3.hash new file +3 -0

new file mode 100644
index 0000000000..526ed29514
@@ -0,0 +1,3 @@
+# Locally calculated
+sha256  eb637ed54204b64e98ae07070e0f2ebd36eed228ecc108dae0e7be6e38edde74  core-secdev-k3-08.06.00.007.tar.gz
+sha256  3e5cf4f5ab9f0333f46cd68fabede3f21e55de1a9e3c6ad673f241f4514d8369  manifest/k3-secdev-0.2-manifest.html

package/ti-core-secdev-k3/ti-core-secdev-k3.mk new file +1 -0

new file mode 100644
index 0000000000..c388af2865
@@ -0,0 +1,31 @@
+################################################################################

package/ti-core-secdev-k3/ti-core-secdev-k3.mk new file +19 -1

+# To allow the image signing process for various firmware artifacts to work the
+# build process for TI K3 platform HS-FS and HS-SE device variants is using the
+# 'core-secdev-k3' tool provided by TI. Its location must be made available to
+# the build process of dependent packages by exporting it through the use of an
+# environmental variable. In order to not pollute the global Buildroot
+# environment let's record the package's location and then define the actual
+# environmental variable needed for the build only in the packages that need it.
+TI_CORE_SECDEV_K3_INSTALL_DIR = $(HOST_DIR)/opt/ti-core-secdev-k3
+
+define HOST_TI_CORE_SECDEV_K3_INSTALL_CMDS
+       mkdir -p $(TI_CORE_SECDEV_K3_INSTALL_DIR)/keys
+       cp -dpfr $(@D)/keys/* $(TI_CORE_SECDEV_K3_INSTALL_DIR)/keys
+       mkdir -p $(TI_CORE_SECDEV_K3_INSTALL_DIR)/scripts
+       cp -dpfr $(@D)/scripts/* $(TI_CORE_SECDEV_K3_INSTALL_DIR)/scripts
+       mkdir -p $(TI_CORE_SECDEV_K3_INSTALL_DIR)/templates
+       cp -dpfr $(@D)/scripts/* $(TI_CORE_SECDEV_K3_INSTALL_DIR)/templates
+endef
+
+$(eval $(host-generic-package))
--

2.34.1

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

Quoted 145 lines · Andreas Dannenberg via buildroot

The ti-core-secdev-k3 package is used to provide binary image signing tools and keys to the build process needed to build boot artifacts for the secure boot flow on TI K3 platform "High Security" SoCs (device variants "HS-FS" and "HS-SE"). This package is not needed building for "General Purpose" ("GP") SoC variants.

This commit also updates the ti-k3-image-gen, ti-k3-r5-loader, and uboot packages which are all used as part of the boot flow of TI K3 platform devices to make use of the ti-core-secdev-k3 package if enabled.

Note that although the use of the underlying 'core-secdev-k3' tool provided by TI is required to generate bootable images for HS-FS and HS-SE device variants, the use of this Buildroot package itself should remain optional, hence no hard dependencies are being established. The reason is that a user often wants to provide their own signing tool through the use of the TI_SECURE_DEV_PKG environmental variable set outside Buildroot on their specific build machine, especially for HS-SE device variants where the signing tool would contain the user's private keys.

https://git.ti.com/cgit/security-development-tools/core-secdev-k3

Signed-off-by Andreas Dannenberg <[email protected]>

---
 boot/ti-k3-image-gen/ti-k3-image-gen.mk       | 10 ++++++
 boot/ti-k3-r5-loader/ti-k3-r5-loader.mk       | 10 ++++++
 boot/uboot/uboot.mk                           | 10 ++++++
 package/Config.in.host                        |  1 +
 package/ti-core-secdev-k3/Config.in.host      | 11 +++++++
 .../ti-core-secdev-k3/ti-core-secdev-k3.hash  |  3 ++
 .../ti-core-secdev-k3/ti-core-secdev-k3.mk    | 31 +++++++++++++++++++
 7 files changed, 76 insertions(+)
 create mode 100644 package/ti-core-secdev-k3/Config.in.host
 create mode 100644 package/ti-core-secdev-k3/ti-core-secdev-k3.hash
 create mode 100644 package/ti-core-secdev-k3/ti-core-secdev-k3.mk

boot/ti-k3-image-gen/ti-k3-image-gen.mk +10 -0

index b624f93771..57202d6918 100644
@@ -70,6 +70,16 @@ TI_K3_IMAGE_GEN_MAKE_OPTS = \
        O=$(@D)/tmp \
        BIN_DIR=$(@D)
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+TI_K3_IMAGE_GEN_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 define TI_K3_IMAGE_GEN_BUILD_CMDS
        $(TI_K3_IMAGE_GEN_MAKE) -C $(@D) $(TI_K3_IMAGE_GEN_MAKE_OPTS)
 endef

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +10 -0

index 341888623e..8311e1b401 100644
@@ -67,6 +67,16 @@ TI_K3_R5_LOADER_MAKE_OPTS = \
        HOSTCC="$(HOSTCC) $(subst -I/,-isystem /,$(subst -I /,-isystem /,$(HOST_CFLAGS)))" \
        HOSTLDFLAGS="$(HOST_LDFLAGS)"
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+TI_K3_R5_LOADER_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 define TI_K3_R5_LOADER_BUILD_CMDS
        $(TARGET_CONFIGURE_OPTS) $(TI_K3_R5_LOADER_MAKE) -C $(@D) $(TI_K3_R5_LOADER_MAKE_OPTS)
 endef

boot/uboot/uboot.mk +10 -0

index 48af69bd26..472fec8619 100644
@@ -184,6 +184,16 @@ UBOOT_DEPENDENCIES += optee-os
 UBOOT_MAKE_OPTS += TEE=$(BINARIES_DIR)/tee.elf
 endif
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+UBOOT_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 ifeq ($(BR2_TARGET_UBOOT_NEEDS_TI_K3_DM),y)
 # Currently supports the FW from Git tag 08.06.00.006 by default
 TI_K3_DM_VERSION = 340194800a581baf976360386dfc7b5acab8d948

package/Config.in.host +1 -0

index dcadbfdfc1..eed39a4102 100644
@@ -103,6 +103,7 @@ menu "Host utilities"
        source "package/systemd/Config.in.host"
        source "package/tegrarcm/Config.in.host"
        source "package/ti-cgt-pru/Config.in.host"
+       source "package/ti-core-secdev-k3/Config.in.host"
        source "package/uboot-tools/Config.in.host"
        source "package/util-linux/Config.in.host"
        source "package/utp_com/Config.in.host"

package/ti-core-secdev-k3/Config.in.host new file +11 -0

new file mode 100644
index 0000000000..364619d824
@@ -0,0 +1,11 @@
+config BR2_PACKAGE_HOST_TI_CORE_SECDEV_K3
+       bool "host ti-core-secdev-k3"
+       help
+         ti-core-secdev-k3 is used to provide binary image signing
+         tools and keys to the build process needed to build boot
+         artifacts for the secure boot flow on TI K3 platform
+         "High Security" SoCs (device variants "HS-FS" and "HS-SE").
+         This package is not needed building for "General Purpose"
+         ("GP") SoC variants.
+
+         https://git.ti.com/cgit/security-development-tools/core-secdev-k3

package/ti-core-secdev-k3/ti-core-secdev-k3.hash new file +3 -0

new file mode 100644
index 0000000000..526ed29514
@@ -0,0 +1,3 @@
+# Locally calculated
+sha256  eb637ed54204b64e98ae07070e0f2ebd36eed228ecc108dae0e7be6e38edde74  core-secdev-k3-08.06.00.007.tar.gz
+sha256  3e5cf4f5ab9f0333f46cd68fabede3f21e55de1a9e3c6ad673f241f4514d8369  manifest/k3-secdev-0.2-manifest.html

package/ti-core-secdev-k3/ti-core-secdev-k3.mk new file +1 -0

new file mode 100644
index 0000000000..c388af2865
@@ -0,0 +1,31 @@
+################################################################################

package/ti-core-secdev-k3/ti-core-secdev-k3.mk line 11

Quoted 10 lines

package/ti-core-secdev-k3/ti-core-secdev-k3.mk new file +10 -0

+#
+# ti-core-secdev-k3
+#
+################################################################################
+
+TI_CORE_SECDEV_K3_VERSION = 08.06.00.007
+TI_CORE_SECDEV_K3_SITE = https://git.ti.com/cgit/security-development-tools/core-secdev-k3/snapshot
+TI_CORE_SECDEV_K3_LICENSE = TI TSPA License
+TI_CORE_SECDEV_K3_LICENSE_FILES = manifest/k3-secdev-0.2-manifest.html
+TI_CORE_SECDEV_K3_SOURCE = core-secdev-k3-$(TI_CORE_SECDEV_K3_VERSION).tar.gz

Hi Andreas,

Would it make sense to support user customisation of this via Kconfig instead of using the magic TI_SECURE_DEV_PKG environment variable?

I'm slightly confused about how this is intended to work. core-secdev-k3 contains both infrastructure (scripts) and data (keys) to secure the image. It looks like someone tried to split these concerns by supporting customisation of the key location. secure-binary-image.sh expects TI_SECURE_DEV_PKG to point to something containing keys/custMpk.pem, but the rest of the process expects TI_SECURE_DEV_PKG to point to something containing scripts to secure the binary blobs.

It would make more sense to me to support overriding just the key, rather than having to duplicate all the scripts too.

Could we support configuring the location of the custMpk.pem key and have the build process replace the default key in build/host-ti-core-secdev-k3-08.06.00.007/keys?

Is there a reason why a customer is expected to replace (or, more likely, duplicate) the scripts rather than just supply a key?

Patrick

Quoted 22 lines

package/ti-core-secdev-k3/ti-core-secdev-k3.mk new file +19 -1

+# To allow the image signing process for various firmware artifacts to work the
+# build process for TI K3 platform HS-FS and HS-SE device variants is using the
+# 'core-secdev-k3' tool provided by TI. Its location must be made available to
+# the build process of dependent packages by exporting it through the use of an
+# environmental variable. In order to not pollute the global Buildroot
+# environment let's record the package's location and then define the actual
+# environmental variable needed for the build only in the packages that need it.
+TI_CORE_SECDEV_K3_INSTALL_DIR = $(HOST_DIR)/opt/ti-core-secdev-k3
+
+define HOST_TI_CORE_SECDEV_K3_INSTALL_CMDS
+       mkdir -p $(TI_CORE_SECDEV_K3_INSTALL_DIR)/keys
+       cp -dpfr $(@D)/keys/* $(TI_CORE_SECDEV_K3_INSTALL_DIR)/keys
+       mkdir -p $(TI_CORE_SECDEV_K3_INSTALL_DIR)/scripts
+       cp -dpfr $(@D)/scripts/* $(TI_CORE_SECDEV_K3_INSTALL_DIR)/scripts
+       mkdir -p $(TI_CORE_SECDEV_K3_INSTALL_DIR)/templates
+       cp -dpfr $(@D)/scripts/* $(TI_CORE_SECDEV_K3_INSTALL_DIR)/templates
+endef
+
+$(eval $(host-generic-package))
--

2.34.1

Quoted 4 lines

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

Hi Patrick,
thanks for the feedback. Comments inlined...

Quoted 172 lines · Patrick Oppenlander

Quoted 145 lines · Andreas Dannenberg via buildroot

The ti-core-secdev-k3 package is used to provide binary image signing tools and keys to the build process needed to build boot artifacts for the secure boot flow on TI K3 platform "High Security" SoCs (device variants "HS-FS" and "HS-SE"). This package is not needed building for "General Purpose" ("GP") SoC variants.

This commit also updates the ti-k3-image-gen, ti-k3-r5-loader, and uboot packages which are all used as part of the boot flow of TI K3 platform devices to make use of the ti-core-secdev-k3 package if enabled.

Note that although the use of the underlying 'core-secdev-k3' tool provided by TI is required to generate bootable images for HS-FS and HS-SE device variants, the use of this Buildroot package itself should remain optional, hence no hard dependencies are being established. The reason is that a user often wants to provide their own signing tool through the use of the TI_SECURE_DEV_PKG environmental variable set outside Buildroot on their specific build machine, especially for HS-SE device variants where the signing tool would contain the user's private keys.

https://git.ti.com/cgit/security-development-tools/core-secdev-k3

Signed-off-by Andreas Dannenberg <[email protected]>

---
 boot/ti-k3-image-gen/ti-k3-image-gen.mk       | 10 ++++++
 boot/ti-k3-r5-loader/ti-k3-r5-loader.mk       | 10 ++++++
 boot/uboot/uboot.mk                           | 10 ++++++
 package/Config.in.host                        |  1 +
 package/ti-core-secdev-k3/Config.in.host      | 11 +++++++
 .../ti-core-secdev-k3/ti-core-secdev-k3.hash  |  3 ++
 .../ti-core-secdev-k3/ti-core-secdev-k3.mk    | 31 +++++++++++++++++++
 7 files changed, 76 insertions(+)
 create mode 100644 package/ti-core-secdev-k3/Config.in.host
 create mode 100644 package/ti-core-secdev-k3/ti-core-secdev-k3.hash
 create mode 100644 package/ti-core-secdev-k3/ti-core-secdev-k3.mk

boot/ti-k3-image-gen/ti-k3-image-gen.mk +10 -0

index b624f93771..57202d6918 100644
@@ -70,6 +70,16 @@ TI_K3_IMAGE_GEN_MAKE_OPTS = \
        O=$(@D)/tmp \
        BIN_DIR=$(@D)
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+TI_K3_IMAGE_GEN_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 define TI_K3_IMAGE_GEN_BUILD_CMDS
        $(TI_K3_IMAGE_GEN_MAKE) -C $(@D) $(TI_K3_IMAGE_GEN_MAKE_OPTS)
 endef

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +10 -0

index 341888623e..8311e1b401 100644
@@ -67,6 +67,16 @@ TI_K3_R5_LOADER_MAKE_OPTS = \
        HOSTCC="$(HOSTCC) $(subst -I/,-isystem /,$(subst -I /,-isystem /,$(HOST_CFLAGS)))" \
        HOSTLDFLAGS="$(HOST_LDFLAGS)"
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+TI_K3_R5_LOADER_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 define TI_K3_R5_LOADER_BUILD_CMDS
        $(TARGET_CONFIGURE_OPTS) $(TI_K3_R5_LOADER_MAKE) -C $(@D) $(TI_K3_R5_LOADER_MAKE_OPTS)
 endef

boot/uboot/uboot.mk +10 -0

index 48af69bd26..472fec8619 100644
@@ -184,6 +184,16 @@ UBOOT_DEPENDENCIES += optee-os
 UBOOT_MAKE_OPTS += TEE=$(BINARIES_DIR)/tee.elf
 endif
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+UBOOT_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 ifeq ($(BR2_TARGET_UBOOT_NEEDS_TI_K3_DM),y)
 # Currently supports the FW from Git tag 08.06.00.006 by default
 TI_K3_DM_VERSION = 340194800a581baf976360386dfc7b5acab8d948

package/Config.in.host +1 -0

index dcadbfdfc1..eed39a4102 100644
@@ -103,6 +103,7 @@ menu "Host utilities"
        source "package/systemd/Config.in.host"
        source "package/tegrarcm/Config.in.host"
        source "package/ti-cgt-pru/Config.in.host"
+       source "package/ti-core-secdev-k3/Config.in.host"
        source "package/uboot-tools/Config.in.host"
        source "package/util-linux/Config.in.host"
        source "package/utp_com/Config.in.host"

package/ti-core-secdev-k3/Config.in.host new file +11 -0

new file mode 100644
index 0000000000..364619d824
@@ -0,0 +1,11 @@
+config BR2_PACKAGE_HOST_TI_CORE_SECDEV_K3
+       bool "host ti-core-secdev-k3"
+       help
+         ti-core-secdev-k3 is used to provide binary image signing
+         tools and keys to the build process needed to build boot
+         artifacts for the secure boot flow on TI K3 platform
+         "High Security" SoCs (device variants "HS-FS" and "HS-SE").
+         This package is not needed building for "General Purpose"
+         ("GP") SoC variants.
+
+         https://git.ti.com/cgit/security-development-tools/core-secdev-k3

package/ti-core-secdev-k3/ti-core-secdev-k3.hash new file +3 -0

new file mode 100644
index 0000000000..526ed29514
@@ -0,0 +1,3 @@
+# Locally calculated
+sha256  eb637ed54204b64e98ae07070e0f2ebd36eed228ecc108dae0e7be6e38edde74  core-secdev-k3-08.06.00.007.tar.gz
+sha256  3e5cf4f5ab9f0333f46cd68fabede3f21e55de1a9e3c6ad673f241f4514d8369  manifest/k3-secdev-0.2-manifest.html

package/ti-core-secdev-k3/ti-core-secdev-k3.mk new file +1 -0

new file mode 100644
index 0000000000..c388af2865
@@ -0,0 +1,31 @@
+################################################################################

package/ti-core-secdev-k3/ti-core-secdev-k3.mk line 11

Quoted 10 lines

package/ti-core-secdev-k3/ti-core-secdev-k3.mk new file +10 -0

+#
+# ti-core-secdev-k3
+#
+################################################################################
+
+TI_CORE_SECDEV_K3_VERSION = 08.06.00.007
+TI_CORE_SECDEV_K3_SITE = https://git.ti.com/cgit/security-development-tools/core-secdev-k3/snapshot
+TI_CORE_SECDEV_K3_LICENSE = TI TSPA License
+TI_CORE_SECDEV_K3_LICENSE_FILES = manifest/k3-secdev-0.2-manifest.html
+TI_CORE_SECDEV_K3_SOURCE = core-secdev-k3-$(TI_CORE_SECDEV_K3_VERSION).tar.gz

Hi Andreas,

Would it make sense to support user customisation of this via Kconfig instead of using the magic TI_SECURE_DEV_PKG environment variable?

I'm slightly confused about how this is intended to work. core-secdev-k3 contains both infrastructure (scripts) and data (keys) to secure the image. It looks like someone tried to split these concerns by supporting customisation of the key location. secure-binary-image.sh expects TI_SECURE_DEV_PKG to point to something containing keys/custMpk.pem, but the rest of the process expects TI_SECURE_DEV_PKG to point to something containing scripts to secure the binary blobs.

Quoted 6 lines

It would make more sense to me to support overriding just the key, rather than having to duplicate all the scripts too.

Could we support configuring the location of the custMpk.pem key and have the build process replace the default key in build/host-ti-core-secdev-k3-08.06.00.007/keys?

Well, this is how the "TI secure dev package" has been for the last 10+ years, and that's how it's being used by 100% of our customers today doing Linux image builds. It's hard-wired into Yocto builds, even the official U-Boot tree...

https://source.denx.de/u-boot/u-boot/-/blob/master/doc/README.ti-secure

I agree improvements could be made for example to point to just a private key via Kconfig but this would also create an inconsistency with all solutions currently in production, and with what folks are used to, and go against enabling an easier and more seamless "switch" from Yocto for example, which is what I'd like people to do.

This doesn't say it should not or never be improved, but I think such changes could be managed more smoothly by establishing a known baseline first (which is what this entire series intends to do, based on a comparable variant of the official TI production SDK), and then over time improve things, also as Yocto, U-Boot, and other projects evolve (there's constant development on those including on the security front, so what we have here will not be the "forever solution).

Quoted 2 lines

Is there a reason why a customer is expected to replace (or, more likely, duplicate) the scripts rather than just supply a key?

The key is the most obvious thing, but often customers also want to customize the certificate to add additional items for example to control certain device features such as whether JTAG should be locked or unlocked, etc., all things not readily controllable through some knobs but needing to be done through customization of sripts / templates.

--
Andreas Dannenberg
Texas Instruments Inc

Quoted 25 lines

Patrick

Quoted 22 lines

package/ti-core-secdev-k3/ti-core-secdev-k3.mk new file +19 -1

+# To allow the image signing process for various firmware artifacts to work the
+# build process for TI K3 platform HS-FS and HS-SE device variants is using the
+# 'core-secdev-k3' tool provided by TI. Its location must be made available to
+# the build process of dependent packages by exporting it through the use of an
+# environmental variable. In order to not pollute the global Buildroot
+# environment let's record the package's location and then define the actual
+# environmental variable needed for the build only in the packages that need it.
+TI_CORE_SECDEV_K3_INSTALL_DIR = $(HOST_DIR)/opt/ti-core-secdev-k3
+
+define HOST_TI_CORE_SECDEV_K3_INSTALL_CMDS
+       mkdir -p $(TI_CORE_SECDEV_K3_INSTALL_DIR)/keys
+       cp -dpfr $(@D)/keys/* $(TI_CORE_SECDEV_K3_INSTALL_DIR)/keys
+       mkdir -p $(TI_CORE_SECDEV_K3_INSTALL_DIR)/scripts
+       cp -dpfr $(@D)/scripts/* $(TI_CORE_SECDEV_K3_INSTALL_DIR)/scripts
+       mkdir -p $(TI_CORE_SECDEV_K3_INSTALL_DIR)/templates
+       cp -dpfr $(@D)/scripts/* $(TI_CORE_SECDEV_K3_INSTALL_DIR)/templates
+endef
+
+$(eval $(host-generic-package))
--

2.34.1

Quoted 4 lines

Quoted 4 lines

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

Quoted 184 lines · Andreas Dannenberg

Hi Patrick,
thanks for the feedback. Comments inlined...

Quoted 172 lines · Patrick Oppenlander

Quoted 145 lines · Andreas Dannenberg via buildroot

The ti-core-secdev-k3 package is used to provide binary image signing tools and keys to the build process needed to build boot artifacts for the secure boot flow on TI K3 platform "High Security" SoCs (device variants "HS-FS" and "HS-SE"). This package is not needed building for "General Purpose" ("GP") SoC variants.

This commit also updates the ti-k3-image-gen, ti-k3-r5-loader, and uboot packages which are all used as part of the boot flow of TI K3 platform devices to make use of the ti-core-secdev-k3 package if enabled.

Note that although the use of the underlying 'core-secdev-k3' tool provided by TI is required to generate bootable images for HS-FS and HS-SE device variants, the use of this Buildroot package itself should remain optional, hence no hard dependencies are being established. The reason is that a user often wants to provide their own signing tool through the use of the TI_SECURE_DEV_PKG environmental variable set outside Buildroot on their specific build machine, especially for HS-SE device variants where the signing tool would contain the user's private keys.

https://git.ti.com/cgit/security-development-tools/core-secdev-k3

Signed-off-by Andreas Dannenberg <[email protected]>

---
 boot/ti-k3-image-gen/ti-k3-image-gen.mk       | 10 ++++++
 boot/ti-k3-r5-loader/ti-k3-r5-loader.mk       | 10 ++++++
 boot/uboot/uboot.mk                           | 10 ++++++
 package/Config.in.host                        |  1 +
 package/ti-core-secdev-k3/Config.in.host      | 11 +++++++
 .../ti-core-secdev-k3/ti-core-secdev-k3.hash  |  3 ++
 .../ti-core-secdev-k3/ti-core-secdev-k3.mk    | 31 +++++++++++++++++++
 7 files changed, 76 insertions(+)
 create mode 100644 package/ti-core-secdev-k3/Config.in.host
 create mode 100644 package/ti-core-secdev-k3/ti-core-secdev-k3.hash
 create mode 100644 package/ti-core-secdev-k3/ti-core-secdev-k3.mk

boot/ti-k3-image-gen/ti-k3-image-gen.mk +10 -0

index b624f93771..57202d6918 100644
@@ -70,6 +70,16 @@ TI_K3_IMAGE_GEN_MAKE_OPTS = \
        O=$(@D)/tmp \
        BIN_DIR=$(@D)
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+TI_K3_IMAGE_GEN_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 define TI_K3_IMAGE_GEN_BUILD_CMDS
        $(TI_K3_IMAGE_GEN_MAKE) -C $(@D) $(TI_K3_IMAGE_GEN_MAKE_OPTS)
 endef

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +10 -0

index 341888623e..8311e1b401 100644
@@ -67,6 +67,16 @@ TI_K3_R5_LOADER_MAKE_OPTS = \
        HOSTCC="$(HOSTCC) $(subst -I/,-isystem /,$(subst -I /,-isystem /,$(HOST_CFLAGS)))" \
        HOSTLDFLAGS="$(HOST_LDFLAGS)"
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+TI_K3_R5_LOADER_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 define TI_K3_R5_LOADER_BUILD_CMDS
        $(TARGET_CONFIGURE_OPTS) $(TI_K3_R5_LOADER_MAKE) -C $(@D) $(TI_K3_R5_LOADER_MAKE_OPTS)
 endef

boot/uboot/uboot.mk +10 -0

index 48af69bd26..472fec8619 100644
@@ -184,6 +184,16 @@ UBOOT_DEPENDENCIES += optee-os
 UBOOT_MAKE_OPTS += TEE=$(BINARIES_DIR)/tee.elf
 endif
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+UBOOT_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 ifeq ($(BR2_TARGET_UBOOT_NEEDS_TI_K3_DM),y)
 # Currently supports the FW from Git tag 08.06.00.006 by default
 TI_K3_DM_VERSION = 340194800a581baf976360386dfc7b5acab8d948

package/Config.in.host +1 -0

index dcadbfdfc1..eed39a4102 100644
@@ -103,6 +103,7 @@ menu "Host utilities"
        source "package/systemd/Config.in.host"
        source "package/tegrarcm/Config.in.host"
        source "package/ti-cgt-pru/Config.in.host"
+       source "package/ti-core-secdev-k3/Config.in.host"
        source "package/uboot-tools/Config.in.host"
        source "package/util-linux/Config.in.host"
        source "package/utp_com/Config.in.host"

package/ti-core-secdev-k3/Config.in.host new file +11 -0

new file mode 100644
index 0000000000..364619d824
@@ -0,0 +1,11 @@
+config BR2_PACKAGE_HOST_TI_CORE_SECDEV_K3
+       bool "host ti-core-secdev-k3"
+       help
+         ti-core-secdev-k3 is used to provide binary image signing
+         tools and keys to the build process needed to build boot
+         artifacts for the secure boot flow on TI K3 platform
+         "High Security" SoCs (device variants "HS-FS" and "HS-SE").
+         This package is not needed building for "General Purpose"
+         ("GP") SoC variants.
+
+         https://git.ti.com/cgit/security-development-tools/core-secdev-k3

package/ti-core-secdev-k3/ti-core-secdev-k3.hash new file +3 -0

new file mode 100644
index 0000000000..526ed29514
@@ -0,0 +1,3 @@
+# Locally calculated
+sha256  eb637ed54204b64e98ae07070e0f2ebd36eed228ecc108dae0e7be6e38edde74  core-secdev-k3-08.06.00.007.tar.gz
+sha256  3e5cf4f5ab9f0333f46cd68fabede3f21e55de1a9e3c6ad673f241f4514d8369  manifest/k3-secdev-0.2-manifest.html

package/ti-core-secdev-k3/ti-core-secdev-k3.mk new file +1 -0

new file mode 100644
index 0000000000..c388af2865
@@ -0,0 +1,31 @@
+################################################################################

package/ti-core-secdev-k3/ti-core-secdev-k3.mk line 11

Quoted 10 lines

package/ti-core-secdev-k3/ti-core-secdev-k3.mk new file +10 -0

+#
+# ti-core-secdev-k3
+#
+################################################################################
+
+TI_CORE_SECDEV_K3_VERSION = 08.06.00.007
+TI_CORE_SECDEV_K3_SITE = https://git.ti.com/cgit/security-development-tools/core-secdev-k3/snapshot
+TI_CORE_SECDEV_K3_LICENSE = TI TSPA License
+TI_CORE_SECDEV_K3_LICENSE_FILES = manifest/k3-secdev-0.2-manifest.html
+TI_CORE_SECDEV_K3_SOURCE = core-secdev-k3-$(TI_CORE_SECDEV_K3_VERSION).tar.gz

Hi Andreas,

Would it make sense to support user customisation of this via Kconfig instead of using the magic TI_SECURE_DEV_PKG environment variable?

I'm slightly confused about how this is intended to work. core-secdev-k3 contains both infrastructure (scripts) and data (keys) to secure the image. It looks like someone tried to split these concerns by supporting customisation of the key location. secure-binary-image.sh expects TI_SECURE_DEV_PKG to point to something containing keys/custMpk.pem, but the rest of the process expects TI_SECURE_DEV_PKG to point to something containing scripts to secure the binary blobs.

Quoted 6 lines

It would make more sense to me to support overriding just the key, rather than having to duplicate all the scripts too.

Could we support configuring the location of the custMpk.pem key and have the build process replace the default key in build/host-ti-core-secdev-k3-08.06.00.007/keys?

Quoted 6 lines

Well, this is how the "TI secure dev package" has been for the last 10+ years, and that's how it's being used by 100% of our customers today doing Linux image builds. It's hard-wired into Yocto builds, even the official U-Boot tree...

https://source.denx.de/u-boot/u-boot/-/blob/master/doc/README.ti-secure

Thanks for the reference!

Quoted 5 lines

I agree improvements could be made for example to point to just a private key via Kconfig but this would also create an inconsistency with all solutions currently in production, and with what folks are used to, and go against enabling an easier and more seamless "switch" from Yocto for example, which is what I'd like people to do.

If you look in the section in README.ti-secure about K3 secure devices it supports setting the key with the Kconfig option "K3_KEY", so it looks like we can support key customisation using the u-boot config and don't need to support this in the buildroot config.

Patrick

Quoted 48 lines

This doesn't say it should not or never be improved, but I think such changes could be managed more smoothly by establishing a known baseline first (which is what this entire series intends to do, based on a comparable variant of the official TI production SDK), and then over time improve things, also as Yocto, U-Boot, and other projects evolve (there's constant development on those including on the security front, so what we have here will not be the "forever solution).

Quoted 2 lines

Is there a reason why a customer is expected to replace (or, more likely, duplicate) the scripts rather than just supply a key?

The key is the most obvious thing, but often customers also want to customize the certificate to add additional items for example to control certain device features such as whether JTAG should be locked or unlocked, etc., all things not readily controllable through some knobs but needing to be done through customization of sripts / templates.

--
Andreas Dannenberg
Texas Instruments Inc

Quoted 25 lines

Patrick

Quoted 22 lines

package/ti-core-secdev-k3/ti-core-secdev-k3.mk new file +19 -1

+# To allow the image signing process for various firmware artifacts to work the
+# build process for TI K3 platform HS-FS and HS-SE device variants is using the
+# 'core-secdev-k3' tool provided by TI. Its location must be made available to
+# the build process of dependent packages by exporting it through the use of an
+# environmental variable. In order to not pollute the global Buildroot
+# environment let's record the package's location and then define the actual
+# environmental variable needed for the build only in the packages that need it.
+TI_CORE_SECDEV_K3_INSTALL_DIR = $(HOST_DIR)/opt/ti-core-secdev-k3
+
+define HOST_TI_CORE_SECDEV_K3_INSTALL_CMDS
+       mkdir -p $(TI_CORE_SECDEV_K3_INSTALL_DIR)/keys
+       cp -dpfr $(@D)/keys/* $(TI_CORE_SECDEV_K3_INSTALL_DIR)/keys
+       mkdir -p $(TI_CORE_SECDEV_K3_INSTALL_DIR)/scripts
+       cp -dpfr $(@D)/scripts/* $(TI_CORE_SECDEV_K3_INSTALL_DIR)/scripts
+       mkdir -p $(TI_CORE_SECDEV_K3_INSTALL_DIR)/templates
+       cp -dpfr $(@D)/scripts/* $(TI_CORE_SECDEV_K3_INSTALL_DIR)/templates
+endef
+
+$(eval $(host-generic-package))
--

2.34.1

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot

Hi Patrick,

Quoted 200 lines · Patrick Oppenlander

Quoted 184 lines · Andreas Dannenberg

Hi Patrick,
thanks for the feedback. Comments inlined...

Quoted 172 lines · Patrick Oppenlander

Quoted 145 lines · Andreas Dannenberg via buildroot

The ti-core-secdev-k3 package is used to provide binary image signing tools and keys to the build process needed to build boot artifacts for the secure boot flow on TI K3 platform "High Security" SoCs (device variants "HS-FS" and "HS-SE"). This package is not needed building for "General Purpose" ("GP") SoC variants.

This commit also updates the ti-k3-image-gen, ti-k3-r5-loader, and uboot packages which are all used as part of the boot flow of TI K3 platform devices to make use of the ti-core-secdev-k3 package if enabled.

Note that although the use of the underlying 'core-secdev-k3' tool provided by TI is required to generate bootable images for HS-FS and HS-SE device variants, the use of this Buildroot package itself should remain optional, hence no hard dependencies are being established. The reason is that a user often wants to provide their own signing tool through the use of the TI_SECURE_DEV_PKG environmental variable set outside Buildroot on their specific build machine, especially for HS-SE device variants where the signing tool would contain the user's private keys.

https://git.ti.com/cgit/security-development-tools/core-secdev-k3

Signed-off-by Andreas Dannenberg <[email protected]>

---
 boot/ti-k3-image-gen/ti-k3-image-gen.mk       | 10 ++++++
 boot/ti-k3-r5-loader/ti-k3-r5-loader.mk       | 10 ++++++
 boot/uboot/uboot.mk                           | 10 ++++++
 package/Config.in.host                        |  1 +
 package/ti-core-secdev-k3/Config.in.host      | 11 +++++++
 .../ti-core-secdev-k3/ti-core-secdev-k3.hash  |  3 ++
 .../ti-core-secdev-k3/ti-core-secdev-k3.mk    | 31 +++++++++++++++++++
 7 files changed, 76 insertions(+)
 create mode 100644 package/ti-core-secdev-k3/Config.in.host
 create mode 100644 package/ti-core-secdev-k3/ti-core-secdev-k3.hash
 create mode 100644 package/ti-core-secdev-k3/ti-core-secdev-k3.mk

boot/ti-k3-image-gen/ti-k3-image-gen.mk +10 -0

index b624f93771..57202d6918 100644
@@ -70,6 +70,16 @@ TI_K3_IMAGE_GEN_MAKE_OPTS = \
        O=$(@D)/tmp \
        BIN_DIR=$(@D)
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+TI_K3_IMAGE_GEN_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 define TI_K3_IMAGE_GEN_BUILD_CMDS
        $(TI_K3_IMAGE_GEN_MAKE) -C $(@D) $(TI_K3_IMAGE_GEN_MAKE_OPTS)
 endef

boot/ti-k3-r5-loader/ti-k3-r5-loader.mk +10 -0

index 341888623e..8311e1b401 100644
@@ -67,6 +67,16 @@ TI_K3_R5_LOADER_MAKE_OPTS = \
        HOSTCC="$(HOSTCC) $(subst -I/,-isystem /,$(subst -I /,-isystem /,$(HOST_CFLAGS)))" \
        HOSTLDFLAGS="$(HOST_LDFLAGS)"
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+TI_K3_R5_LOADER_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 define TI_K3_R5_LOADER_BUILD_CMDS
        $(TARGET_CONFIGURE_OPTS) $(TI_K3_R5_LOADER_MAKE) -C $(@D) $(TI_K3_R5_LOADER_MAKE_OPTS)
 endef

boot/uboot/uboot.mk +10 -0

index 48af69bd26..472fec8619 100644
@@ -184,6 +184,16 @@ UBOOT_DEPENDENCIES += optee-os
 UBOOT_MAKE_OPTS += TEE=$(BINARIES_DIR)/tee.elf
 endif
 
+ifneq ($(TI_CORE_SECDEV_K3_INSTALL_DIR),)
+# Only set TI_SECURE_DEV_PKG make option if not already defined in the
+# environment, thus allowing the user to unconditionally override this
+# setting with a custom location on their build machine containing their
+# private keys, etc.
+ifeq ($(TI_SECURE_DEV_PKG),)
+UBOOT_MAKE_OPTS += TI_SECURE_DEV_PKG=$(TI_CORE_SECDEV_K3_INSTALL_DIR)
+endif
+endif
+
 ifeq ($(BR2_TARGET_UBOOT_NEEDS_TI_K3_DM),y)
 # Currently supports the FW from Git tag 08.06.00.006 by default
 TI_K3_DM_VERSION = 340194800a581baf976360386dfc7b5acab8d948

package/Config.in.host +1 -0

index dcadbfdfc1..eed39a4102 100644
@@ -103,6 +103,7 @@ menu "Host utilities"
        source "package/systemd/Config.in.host"
        source "package/tegrarcm/Config.in.host"
        source "package/ti-cgt-pru/Config.in.host"
+       source "package/ti-core-secdev-k3/Config.in.host"
        source "package/uboot-tools/Config.in.host"
        source "package/util-linux/Config.in.host"
        source "package/utp_com/Config.in.host"

package/ti-core-secdev-k3/Config.in.host new file +11 -0

new file mode 100644
index 0000000000..364619d824
@@ -0,0 +1,11 @@
+config BR2_PACKAGE_HOST_TI_CORE_SECDEV_K3
+       bool "host ti-core-secdev-k3"
+       help
+         ti-core-secdev-k3 is used to provide binary image signing
+         tools and keys to the build process needed to build boot
+         artifacts for the secure boot flow on TI K3 platform
+         "High Security" SoCs (device variants "HS-FS" and "HS-SE").
+         This package is not needed building for "General Purpose"
+         ("GP") SoC variants.
+
+         https://git.ti.com/cgit/security-development-tools/core-secdev-k3

package/ti-core-secdev-k3/ti-core-secdev-k3.hash new file +3 -0

new file mode 100644
index 0000000000..526ed29514
@@ -0,0 +1,3 @@
+# Locally calculated
+sha256  eb637ed54204b64e98ae07070e0f2ebd36eed228ecc108dae0e7be6e38edde74  core-secdev-k3-08.06.00.007.tar.gz
+sha256  3e5cf4f5ab9f0333f46cd68fabede3f21e55de1a9e3c6ad673f241f4514d8369  manifest/k3-secdev-0.2-manifest.html

package/ti-core-secdev-k3/ti-core-secdev-k3.mk new file +1 -0

new file mode 100644
index 0000000000..c388af2865
@@ -0,0 +1,31 @@
+################################################################################

package/ti-core-secdev-k3/ti-core-secdev-k3.mk line 11

Quoted 10 lines

package/ti-core-secdev-k3/ti-core-secdev-k3.mk new file +10 -0

+#
+# ti-core-secdev-k3
+#
+################################################################################
+
+TI_CORE_SECDEV_K3_VERSION = 08.06.00.007
+TI_CORE_SECDEV_K3_SITE = https://git.ti.com/cgit/security-development-tools/core-secdev-k3/snapshot
+TI_CORE_SECDEV_K3_LICENSE = TI TSPA License
+TI_CORE_SECDEV_K3_LICENSE_FILES = manifest/k3-secdev-0.2-manifest.html
+TI_CORE_SECDEV_K3_SOURCE = core-secdev-k3-$(TI_CORE_SECDEV_K3_VERSION).tar.gz

Hi Andreas,

Would it make sense to support user customisation of this via Kconfig instead of using the magic TI_SECURE_DEV_PKG environment variable?

I'm slightly confused about how this is intended to work. core-secdev-k3 contains both infrastructure (scripts) and data (keys) to secure the image. It looks like someone tried to split these concerns by supporting customisation of the key location. secure-binary-image.sh expects TI_SECURE_DEV_PKG to point to something containing keys/custMpk.pem, but the rest of the process expects TI_SECURE_DEV_PKG to point to something containing scripts to secure the binary blobs.

Quoted 6 lines

It would make more sense to me to support overriding just the key, rather than having to duplicate all the scripts too.

Could we support configuring the location of the custMpk.pem key and have the build process replace the default key in build/host-ti-core-secdev-k3-08.06.00.007/keys?

Quoted 6 lines

Well, this is how the "TI secure dev package" has been for the last 10+ years, and that's how it's being used by 100% of our customers today doing Linux image builds. It's hard-wired into Yocto builds, even the official U-Boot tree...

https://source.denx.de/u-boot/u-boot/-/blob/master/doc/README.ti-secure

Thanks for the reference!

Quoted 5 lines

I agree improvements could be made for example to point to just a private key via Kconfig but this would also create an inconsistency with all solutions currently in production, and with what folks are used to, and go against enabling an easier and more seamless "switch" from Yocto for example, which is what I'd like people to do.

Quoted 4 lines

If you look in the section in README.ti-secure about K3 secure devices it supports setting the key with the Kconfig option "K3_KEY", so it looks like we can support key customisation using the u-boot config and don't need to support this in the buildroot config.