Fixes commit b143804dbb, since in nativesdk
context MACHINE_FEATURES is reset to SDK_MACHINE_FEATURES, causing OP-TEE
building tools to be missing from the generated SDK.
https://onedigi.atlassian.net/browse/DEL-9663
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
This commit removes the default integration of the Flutter framework from the
SDK due to its significant impact on toolchain size, build time, and reliability.
Including Flutter increases the build complexity exponentially, often resulting
in timeouts or failures caused by the large number of recipes involved.
Customers who require Flutter can still enable it manually if needed.
https://onedigi.atlassian.net/browse/DEL-9380
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Flutter is an open source framework for building multi-platform applications
without a graphical backend running. This commit adds support to create a new
DEY image type based on Flutter ready to use for the users.
https://onedigi.atlassian.net/browse/DEL-9380
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Both python3-cryptography and python3-pyelftools are needed to compile optee-os
with a Yocto-generated SDK, but we were adding these packages to all i.MX SDKs,
even for platforms that don't use optee. This wouldn't be a problem if it
weren't for the fact that python3-cryptography is implemented in rust, and its
inclusion in the SDKs forces bitbake to generate the rust compiler just for
that package.
Only include these python packages for platforms that use optee.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
The appropriate way to add STM signtools to the SDK is via RDEPENDS on
nativesdk-packagegroup-sdk-host, not through the parent recipe of STM
signtools recipe itself.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://onedigi.atlassian.net/browse/DEL-8720
The name of the variable was not very intuitive of what
it contains. This variable expands to the SoC vendor
(NXP or STM).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Building a toolchain/SDK fails for ccmp15-dvk, because the NXP-based
trustfence tools (for example the cst) are not available. Fix the build
by filtering out those tools when the build platform is not NXP based.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
In order to perform the standalone signature process, it was required
to rebuild the Toolchain with Trustfence support enabled.
CST source code is now available for downloading in the Digi FTP, so add
Trustfence sign scripts and cst/srktool to the default toolchain for it
to be used for standalone signature without rebuilding.
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
(cherry picked from commit 2c9b721fb9ce38dcd0034e22d95db6e0ee068955)
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
imx-mkimage is a host recipe to provide the mkimage_imx8 binaries, required
for the trustfence support with platform based on AHAB (ccimx8x). Since
these binaries are required to the sign process we need to export it in the
SDK to allow the standalone sign mode, and with that we can simplify the
mechanism to share these binaries with another recipes (u-boot, linux).
Also the do_deploy() from imx-mkimage recipe was removed to avoid overriding
the implementation from the native class and allow populating the mkimage
binaries.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Generate and include the host tools in the SDK when Trustfence is enabled.
This makes it easier to use the standalone signing and encrypting scripts.
Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
Add a recipe to include all signing and encryption tools for U-Boot and
kernel images to the SDK. Move existing trustfence kernel scripts to this
new recipe.
This allows to use these scripts not only from the Yocto build system but
also as standalone tools for image signing and encryption.
https://jira.digi.com/browse/DEL-2688
Signed-off-by: Diaz de Grenu, Jose <Jose.DiazdeGrenu@digi.com>