This commit integrates a custom .bbappend to fix a deployment issue of the
final FIP artifact, where the SoC name does not match with the FIP device tree
name.
https://onedigi.atlassian.net/browse/DEL-9381
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit removes kernel headers from the SDK package list to prevent
overwriting the default ones, as there are currently no ST-specific headers
required.
https://onedigi.atlassian.net/browse/DEL-9381
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit updates the default FIP generation variables to align with the
common stm32mp2 configuration files from the latest meta-st-stm32mp layer,
based on the openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06 tag for Yocto 5.0
(Scarthgap).
https://onedigi.atlassian.net/browse/DEL-9381
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit removes all outdated weston recipes and synchronizes it with the
latest v13.0.1 from the meta-st-openstlinux layer, based on the
openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06 tag for Yocto 5.0 (scarthgap).
https://onedigi.atlassian.net/browse/DEL-9381
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit removes all unnecessary files after the integration of the latest
ST BSP, based on the openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06 tag for
Yocto 5.0 (Scarthgap).
https://onedigi.atlassian.net/browse/DEL-9381
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Update ccmp2 platform to use the latest U-Boot v2023.10 based on the
openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06 tag for Yocto 5.0 (scarthgap).
https://onedigi.atlassian.net/browse/DEL-9381
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Update ccmp2 platform to use the latest Linux kernel v6.6.48 based on the
openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06 tag for Yocto 5.0 (scarthgap).
https://onedigi.atlassian.net/browse/DEL-9381
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit removes the outdated wayland-protocols recipe and synchronizes it
with the latest v1.33 from the meta-st-openstlinux layer, based on the
openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06 tag for Yocto 5.0 (scarthgap).
https://onedigi.atlassian.net/browse/DEL-9381
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit removes all outdated gstreamer recipes and synchronizes it with the
latest v1.22.12 from the meta-st-openstlinux layer, based on the
openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06 tag for Yocto 5.0 (scarthgap).
https://onedigi.atlassian.net/browse/DEL-9381
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit removes the gcnano recipes integrated into meta-digi, as a new
version (v6.4.19) has been released in the latest ST BSP, based on the
openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06 tag for Yocto 5.0 (Scarthgap).
https://onedigi.atlassian.net/browse/DEL-9381
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit removes the scp-firmware recipe, as it has been integrated into the
optee-os recipe with the latest v4.0.0 from the ST BSP release. This update is
based on the openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06 tag for Yocto 5.0
(Scarthgap).
https://onedigi.atlassian.net/browse/DEL-9381
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit removes all outdated OPTEE-OS recipes and synchronizes the Digi custom
.bbappend with the latest v4.0.0 from the ST BSP release, based on the
openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06 tag for Yocto 5.0 (scarthgap).
https://onedigi.atlassian.net/browse/DEL-9381
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit removes all outdated TF-A recipes and synchronizes the Digi custom
.bbappend with the latest v2.10 from the ST BSP release, based on the
openstlinux-6.6-yocto-scarthgap-mpu-v24.11.06 tag for Yocto 5.0 (scarthgap).
https://onedigi.atlassian.net/browse/DEL-9381
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This patch includes code that only gets compiled for platforms that use a NAND
as the internal storage. Recent changes in swupdate's "copyfile" API caused
this code to stop building.
Using the normal rdiff handler code as reference, update our custom handler to
fix the build errors. While at it, include another change to prevent a warning.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
In this version, Config.in files have been renamed to Kconfig, which prevented
one of our patches from applying correctly. Rework the patch to account for
this name change and while at it, update its context.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Do not take any action such as removing the btnxpuart module When
the system is being restarted (poweroff or reboot), as the driver
tries to restore the UART baudrate when removing the module, and if
the system is being off, some of the entries might be dissapeared in the
middle of the process, leading to a NULL pointer and preventing the
system of being rebooted.
The btnxpuart can be removed on suspend/resume safely, so add the logic
to detect if the system is being rebooted.
https://onedigi.atlassian.net/browse/DEL-9290
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
This slightly increases the SDK's size, but it adds packages that are required
for common use cases such as integration with weston/x11.
https://onedigi.atlassian.net/browse/DEL-9297
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Our new dey-toolchain recipe was missing the logic needed to create the
"dey-version" file in the SDK's installation path. Move this logic from the
dey-image bbclass to a new bbclass meant exclusively for SDK logic, and inherit
it where needed. While at it, move other common SDK modifications to this
class.
https://onedigi.atlassian.net/browse/DEL-9297
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This variable is used to determine the types of complementary packages included
in the SDK: dbg-pkgs, dev-pkgs, doc-pkgs, src-pkgs...
We added staticdev-pkgs to this variable back in Yocto 2.0 (45de4d6943), but
instead of appending it to the original list, we redefined it with its original
value ("dev-pkgs dbg-pkgs") plus "staticdev-pkgs".
However, the default value of SDKIMAGE_FEATURES in poky has changed over time:
* Starting in Yocto 2.3 (eb345ca720e5), doc-pkgs is included if
"api-documentation" is in DISTRO_FEATURES. We don't include this feature
by default, but if a customer were to include it manually, the doc
packages wouldn't get included in their custom SDKs.
* Starting in Yocto 2.7 (ba3aa5311291), bitbake changed the default
PACKAGE_DEBUG_SPLIT_STYLE value so debug packages get split in two: one
for binaries with debug symbols and another for the source code. In turn,
src-pkgs was added to the default SDKIMAGE_FEATURES so that SDKs wouldn't
change behavior, but since we overwrite the default value, we aren't
including src-pkgs in our SDKs, only dbg-pkgs.
* Any future changes would be ignored as well, which could potentially lead
to unexpected behavior.
Make sure we don't overwrite the default SDKIMAGE_FEATURES value to include
src-pkgs in our SDKs, as well as the optional doc-pkgs logic. Also, include
staticdev-pkgs in our recently created dey-toolchain recipe.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Instead of having one toolchain per image, we now provide one per platform.
https://onedigi.atlassian.net/browse/DEL-9297
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
For many DEY releases, we've been providing one SDK per image type, per
platform. In the case of graphical images, this was redundant for a few
reasons:
* Most of the SDK's contents were identical, save for the specific packages
in each image (qt, webkit, lvgl...) and their dependencies. With each SDK
occupying over 1.5 GiB, this results in a lot of storage space overhead
in our servers.
* For some images, namely webkit and lvgl images, their respective SDK
packages aren't necessary for the expected development use cases, so it's
perfectly possible to use the qt SDK instead.
Create a separate recipe for a general-use SDK. Said toolchain includes qt5/qt6
packages by default, except for headless platforms. The advantages of this are:
* We only provide one prebuilt SDK per platform, all with the same base
name. The SDK should cover most if not all of the expected development
use cases, and customers are still able to create their own custom SDKs
if needed.
* Having a separate recipe for the toolchain, not tied to a specific image
type, allows us to fine tune its contents without affecting images and
their recipes. With time, we can incorporate new packages as needed.
https://onedigi.atlassian.net/browse/DEL-9297
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
If the power domain is kept on in suspend, do not disable the Bluetooth as
no new initialization is needed.
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
After poky commit 4705dd264681d908f144dd4d9bf1f6175f68d8b9, soft dependencies
for complementary packages no longer get included by bitbake's internal package
managers. Make weston's dependency with wayland-protocols a hard one to include
wayland-protocols in our SDKs, which is how it used to be in older DEY
releases.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
The ccmx91 uses the same AHAB-containerizing command as the ccimx93,
so fix the code to remove the hardcoding check for the ccimx93.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
This commit in Poky:
https://git.yoctoproject.org/poky/commit/?id=fbace4111441d36026c3b5cd2ef690250ca8c448
changed the naming/symlinking of the different dtb files installed in
the deploy directory. In Yocto 4.0 we had:
146432 nov 19 14:37 ccimx8x-sbc-pro--5.15-r0.6-ccimx8x-sbc-pro-20241119124717.dtb
61 nov 19 14:37 ccimx8x-sbc-pro-ccimx8x-sbc-pro.dtb -> ccimx8x-sbc-pro--5.15-r0.6-ccimx8x-sbc-pro-20241119124717.dtb
61 nov 19 14:37 ccimx8x-sbc-pro.dtb -> ccimx8x-sbc-pro--5.15-r0.6-ccimx8x-sbc-pro-20241119124717.dtb
while in Yocto 5.0:
19 nov 19 17:57 ccimx8x-sbc-pro--6.6-r0.0-ccimx8x-sbc-pro-20241119164948.dtb -> ccimx8x-sbc-pro.dtb
19 nov 19 17:57 ccimx8x-sbc-pro-ccimx8x-sbc-pro.dtb -> ccimx8x-sbc-pro.dtb
151552 nov 19 17:57 ccimx8x-sbc-pro.dtb
Now, the regular file does not have timestamps or platform name suffixes,
so adjust the signing code to reflect this change.
https://onedigi.atlassian.net/browse/DEL-9325
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
In single boot layout the ccmp1 platforms have two UBI devices:
ubi0: Contains uboot_config_r, linux, and recovery.
ubi1: Contains rootfs, data, and update.
The regular expression used for the update partition needs
to be updated to include the ubi1 device, ensuring proper
handling of the update partition.
https://onedigi.atlassian.net/browse/DEL-9387
Signed-off-by: Francisco Gil francisco.gilmartinez@digi.com
Optee client library updated its major version due to a ABI breaking
change:
3eac340a78
This update provides a new build of the trustfence-fscrypt app, linking
to the new version of libteec.
https://onedigi.atlassian.net/browse/DEL-9341
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Upon a p2p link, an auxiliar iface "p2p-iface-[0-9]" is created. If
it is not specified to the wpa_cli command, a different interface may
be used (eg, wlan0), leading to a failure.
Make the script more robust by detecting the new interface.
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
Commit 998598415a moved this logic to the
trustfence.bbclass file, but in doing so, it removed the TRUSTFENCE_SIGN check
it used to have. The check is needed for two reasons:
* The signing of SWU packages only occurs when TRUSTFENCE_SIGN is enabled, so
there's no need to copy the key if it's disabled
* When building a project from scratch that has Trustfence enabled but
TRUSTFENCE_SIGN disabled, a PKI is never generated and the key doesn't exist.
Because of this, the key won't be found and an error will occur. Note that
if your project is already pointing to a populated PKI, the error won't
happen, only if there's no PKI to begin with.
Although the PKI is guaranteed to exist by the time the rootfs is populated,
make sure to check that it has been properly generated and create it if it
doesn't exist. This logic depends on the trustfence-gen-pki.sh from
trustfence-sign-tools-native, so add it as a dependency for
dey-image-recovery-initramfs. The dependency is already there for another
feature in the dey-image recipes, so simply reflect this new dependency in a
comment.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
(cherry picked from commit 8e52c27d5a8e8071c3a17754e91c1819bcceee15)
Poky updated orc to version 0.4.40. This patch is no longer needed.
This reverts commit bee97587cb.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
When it comes to inheriting this qt bbclass, we used to do so for every image
inheriting the "dey-image" bbclass that had "dey-qt" in its IMAGE_FEATURES. In
theory, only dey-image-qt follows these requirements.
However, starting in DEY 3.0, we added support for multiple graphical images,
all of them sharing the same characteristics save for a defining IMAGE_FEATURE.
To implement this, all images have the IMAGE_FEATURE "dey-${GRAPHICAL_CORE}",
with GRAPHICAL_CORE having a default value of "qt" and being overwritten in
each image recipe with its respective value: "qt", "webkit", "crank" or "lvgl".
The problem is that, when checking whether to inherit populate_sdk_qt[5/6] or
not, it's still very early in the recipe parsing process and GRAPHICAL_CORE
still has its default value of "qt", meaning the "dey-qt" IMAGE_FEATURE is
considered present for all graphical images. In turn, this results in qt
packages being included in all graphical image SDKs.
Move the inherit clause to the dey-image-qt recipe and remove the check so
that the qt packages only get installed in the dey-image-qt SDK.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
(cherry picked from commit 593ff866578e6d341ec4d8a09581922c6390e2a4)
Commit 99f1425340 ("image-buildinfo: Improve and extend to SDK coverage too")
in the Poky layer changes the name of the default build information file from
"build" to "buildinfo", so this commit reflects this change by adapting the
sysinfo script.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Remove any content that has been upstreamed to meta-freescale and update the
recipes with the latest changes in meta-imx, while keeping our customizations.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Sporadically, the BT FW is uploaded but the interface is not functional
as it is not up and its entries are not populated. Validate the FW
was correctly set, if not, rely on the retry mechanism.
https://onedigi.atlassian.net/browse/DEL-9006
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
This commit changes the audio card name for the
asound configuration and state of the following
platforms:
* CCiMX8X
* CCiMX8M
* CCiMX6UL
https://onedigi.atlassian.net/browse/DEL-9005
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
Now that the tool supports OpenSSL 3.2.3, the same version provided by Yocto
5.0 poky, we can simply use the regular Yocto version of the package and link
to it dynamically instead of building a separate version specific for the tool.
Reflect this change in the recipe and include the new binary "mac_dump" in the
package.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
An internal build of openssl is compiled as part of the cst build process,
which is later linked statically to the tool. When building the nativesdk
version of cst, openssl's internal "Configure" tool chooses Yocto's nativesdk
compiler for its compilation (x86_64-deysdk-linux-gcc). However, cst's Makefile
uses host tools by default, meaning it will compile its C files with the host's
gcc and link the final binary with the host's ld. This can lead to errors due
to the Yocto nativesdk compiler including symbols in the openssl libraries that
are unknown to the host's linker.
For example, when attempting to build nativesdk-trustfence-cst in Yocto 5.0 on
Ubuntu 2020.04, the following linker error appears multiple times:
undefined reference to `__isoc23_strtol'
Fix this by making sure cst uses the same toolchain as the one used when
building the internal openssl libraries (and ultimately, when the final binary
is linked together). This doesn't affect the native version of cst, which uses
the host's toolchain.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This was always the case until commit 498e94c9132e90fc1c406b8422e4554c6801918e
in meta-qt6, which was meant to reorganize some packages depending on the
target architecture, but removed the check for this package in the process
(while maintaining the check for other related packages). We haven't tried
building qtpdf until now, and since it's causing build errors out of the box,
we might as well remove it for now because it's only meant to be an addon
exclusive to the SDK.
Since the new package qtdoc has a dependency with qtpdf, remove it as well.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Arturo Buzarra
Gabriel Valcazar
Isaac Hermida
Javier Viguera
Francisco Gil
Gonzalo Ruiz
Mike Engel