On 8/10/22 11:25 AM, Andrew Davis wrote:
Denys, Ryan,
I'm not really happy with this patch to be honest. Nor with how we handle
TI_SECURE_DEV_PKG in general.
So a little history (Denys correct me if my memory has faded any here). We
use TI_SECURE_DEV_PKG for legacy platforms as the SECDEV tools are NDA-only,
so they *had* to be feed into the SDK from an external location. This
carried over to the K3 machines.
But with K3 we don't have this NDA-only restriction. The K3 TI_SECURE_DEV_PKG
tools are fully open source and publicly available on git.ti.com. Now that
we are bringing HS to the board market with AM64x, it is time we fix things.
My idea is to treat TI_SECURE_DEV_PKG like the other toolchains. If we define
it in our environment then we use that version. If it is not defined then we
fetch it for the user. I've got a simple recipe to build a tik3secdev-native
package, and am working to use that everywhere we use TI_SECURE_DEV_PKG in
recipes today. Then we can use preferred providers to pick which SECDEV
to use, the legacy ones, or the K3 one.
The legacy tisecdev-native will require TI_SECURE_DEV_PKG_CAT/AUTO set
as required today, but the tik3secdev-native will download it for you
if not set.
So my questions are, does this sound like a reasonable approach, and if so
do you have any guidance on this? This will require me to dig down into
the deeper parts of the build system and I've not done that before. Any
pointers welcome.
I'm also thinking on making a dummy secdev package, that just copies
the images instead of signing them. That should be the default preferred
provider for the non-HS machines, then we can drop the various checks we
have based -hs-evm vs -evm. All machines take the same path, then based
on the secdev package provider they do the right thing.
Thanks,
Andrew
Okay, gave this a quick attempt, see
https://lore.kernel.org/yocto-meta-ti/[email protected]/
and for its use
https://lore.kernel.org/yocto-meta-ti/[email protected]/
If we like it, we can start to add for the non-K3 machines and drop
a bunch of machine specific checks. Move them all to a single preferred
provider set in the top level machine configs, instead of out in the
recipes.
Andrew
On 8/10/22 9:47 AM, Andrew Davis wrote:
If we do not have TI_SECURE_DEV_PKG set then SYSFW generation will fail
if we are building for the HS platform. When TI_SECURE_DEV_PKG is not
set we assume the builder is only interested in the GP boards, so fake
generating the HS SYSFW images. These will be non-functional on HS
boards, but they would have been just as non-functional if built
without TI_SECURE_DEV_PKG set.
Signed-off-by: Andrew Davis <[email protected]>
---
recipes-bsp/ti-sci-fw/ti-sci-fw_git.bb | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/recipes-bsp/ti-sci-fw/ti-sci-fw_git.bb
b/recipes-bsp/ti-sci-fw/ti-sci-fw_git.bb
index 18652dd4..287e5a40 100644
--- a/recipes-bsp/ti-sci-fw/ti-sci-fw_git.bb
+++ b/recipes-bsp/ti-sci-fw/ti-sci-fw_git.bb
@@ -66,6 +66,11 @@ EXTRA_OEMAKE_remove_j7-hs-evm-k3r5 = "
SBL="${STAGING_DIR_HOST}/boot/u-boot-spl.
EXTRA_OEMAKE_remove_j7-hs-evm-k3r5-sr1-1 = "
SBL="${STAGING_DIR_HOST}/boot/u-boot-spl.bin""
do_compile() {
+ if [ ! "${SYSFW_SUFFIX}" = "gp" ] && [ ! -f
${TI_SECURE_DEV_PKG}/scripts/secure-binary-image.sh ]; then
+ echo "Warning: TI_SECURE_DEV_PKG not set, skipping HS SYSFW
generation."
+ touch ${WORKDIR}/imggen/${SYSFW_TIBOOT3}
+ exit 0
+ fi
cd ${WORKDIR}/imggen/
oe_runmake
}
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#14957):
https://lists.yoctoproject.org/g/meta-ti/message/14957
Mute This Topic: https://lists.yoctoproject.org/mt/92938028/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
