| Message ID | 20220810144708.14171-1-afd@ti.com |
|---|---|
| State | Superseded |
| Delegated to: | Ryan Eatmon |
| Headers | show |
| Series | [meta-ti,dunfell,1/2] ti-sci-fw: Allow build to continue without TI_SECURE_DEV_PKG set | expand |
On 8/10/2022 9:47, 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. Have you tested what happens if they do not have it set and build the "dummy" files, and then realize their mistake, set the variable and build again? Do the files then build correctly, or does the sstate cache prevent them from getting the correct thing without clearing the cache and rebuilding everything?
On 8/10/22 10:58 AM, Ryan Eatmon wrote: > > > On 8/10/2022 9:47, 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. > > > Have you tested what happens if they do not have it set and build the "dummy" files, and then realize their mistake, set the variable and build again? Do the files then build correctly, or does the sstate cache prevent them from getting the correct thing without clearing the cache and rebuilding everything? > > Yes, changing the value of the TI_SECURE_DEV_PKG causes all packages that use it to get rebuilt. I was surprised bitbake was smart enough to do that but seems like it is. Andrew
On 8/10/2022 11:00, Andrew Davis wrote: > On 8/10/22 10:58 AM, Ryan Eatmon wrote: >> >> >> On 8/10/2022 9:47, 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. >> >> >> Have you tested what happens if they do not have it set and build the >> "dummy" files, and then realize their mistake, set the variable and >> build again? Do the files then build correctly, or does the sstate >> cache prevent them from getting the correct thing without clearing the >> cache and rebuilding everything? >> >> > > Yes, changing the value of the TI_SECURE_DEV_PKG causes all packages > that use > it to get rebuilt. I was surprised bitbake was smart enough to do that > but seems > like it is. Nice!
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 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 <afd@ti.com> > --- > 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 > }
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/20220812014128.1185-1-afd@ti.com/ and for its use https://lore.kernel.org/yocto-meta-ti/20220812014128.1185-2-afd@ti.com/ 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 <afd@ti.com> >> --- >> 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 >> }
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 }
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 <afd@ti.com> --- recipes-bsp/ti-sci-fw/ti-sci-fw_git.bb | 5 +++++ 1 file changed, 5 insertions(+)