Overview¶

This page provides an overview of Welma's current and upcoming features, supported platforms, and design decisions.

Welma Features¶

• Platforming-ready environment
• Dedicated images for both production and development
• Filesystem partition scheme that facilitates security features and granular updates
• Software update with A/B mechanism (swupdate and mender.io support)
• Defaults to an unprivileged user with a dedicated user session
• Application service startup and watchdog
• Generate the software bill of material (SBOM) for all packages
• GPLv3 free for production images
• Based on Yocto, follows Yocto standards and best practices
• Secure boot
• Secure storage and keystore

Upcoming features:

• Access control on applications
• Container support
• Linux RT enablement
• Build reproducibility
• ... and more

Supported boards¶

Embedded Software stack overview¶

• Compatible with Yocto branches kirkstone (version 4.0), LTS (Apr. 2026) and scarthgap (version 5.0), LTS (Apr 2028).
• GCC 11 and 13
• Embedded software:
  • Linux kernel
  • GNU libc
  • Systemd
  • PAM
  • D-Bus
  • Dash, Busybox, and more...

Supported features¶

The following tables show how specific features are supported in Welma:

Yocto Layers¶

The Welma project provides and maintains the following Yocto layers:

• meta-welma: Welma core layer

• BSP adaptation layers:

  • meta-welma-boundary-mtk
  • meta-welma-congatec-imx
  • meta-welma-intel
  • meta-welma-maaxboard
  • meta-welma-qemuarm
  • meta-welma-raspberrypi
  • meta-welma-sm2s-imx8
  • meta-welma-sm2s-imx9
  • meta-welma-stm32mp15
  • meta-welma-stm32mp25

• Layers to demonstrate how to use meta-welma:

  • meta-demo-headless
  • meta-demo-graphics

Dependencies¶

Welma Yocto layers depend on:

• URI: git://git.yoctoproject.org/poky
• URI: git://git.openembedded.org/meta-openembedded
• For mechanism swupdate:
  • URI: https://github.com/sbabic/meta-swupdate.git
• For mechanism mender:
  • URI: https://github.com/mendersoftware/meta-mender.git
• Board-specific layers: see the related manifest in welma-manifest

Image flavors¶

Welma has the following definitions of image flavors:

• Production: An image that is as closely as possible to the production image. In a development environment, it will probably differ from the real production image in the following parts:

  • manufacturing parameters such as serial number, manufacturing date, calibration data, ...
  • keys and certificates
  • applicative software or data if supplied by third parties

• Development: one or several images for developers and testers. They run the same programs and features as the production image, and have tools to help developers and testers verify things:

  • interactive bootloader
  • login access (via SSH or console)
  • interactive tools such as text editor, pager, shell with history of commands, ...
  • debugging tools
  • simulators of third-party applicative software or data
  • modified parameters (eg: URL for the device to connect to a test server)

Unix Users¶

Welma defines the following users:

• root: superuser account

• user: unprivileged user account for handling a session and a seat (access rights to peripherals: screen, speaker, buttons, serial port,...). A user session is generally automatically started at boot and applications run in this session.

Other accounts may be used by processes and daemons to follow the principle of least privilege. These should be created by the Yocto recipes that provide the related daemons and programs.

Technical Choices¶

This paragraph gives the technical choices that we have made. They are default values that we recommend and for which we provide support, but you can modify these if needed.

IPK Packaging¶

The packaging format internally used is IPK:

• IPK conforms to BAD_RECOMMENDATIONS as stated in the Yocto's documentation (whereas RPM considers BAD_RECOMMENDATIONS as PACKAGE_EXCLUDE and DEB neither supports BAD_RECOMMENDATIONS nor PACKAGE_EXCLUDE)
• IPK keeps the PR information in the manifest file (whereas RPM does not)
• IPK needs less native dependencies than RPM

GPLv3¶

In production images, by default, Welma uses packages that are not licensed under GPLv3 because:

• Some manufacturers protect their products with secure boot, which means that embedded software is signed with a secret key and cannot be modified without this secret key.

• GPLv3 requires that final owners are free to modify embedded software, hence this would force the manufacturer to reveal the secret signing key to final owners.

Logging¶

The logging system is configured in accordance with the following principles:

• Enforce size limits on the journal files stored. Systemd's default: do not use more than 10% of the size of the file system and leave at least 15% free.
• Store journal files in persistent storage SYSRW.
• Be resilient to unreliable date and time (eg: do not rely on date and time when removing oldest archived journal files).
• Be resilient to unexpected power outage.

Default Shell¶

We have chosen dash as default shell because:

• dash is many times faster than bash;
• dash is much smaller than bash (takes less space and has a smaller attack surface);
• dash has a more permissive license than bash, which is licensed under GPLv3 (see above).

Miscellaneous¶

• Embedded packages

  • GNU Lib C: widely used in Linux systems
  • Systemd: widely used in Linux systems, enables fast boot by parallelizing tasks

• Unprivileged user with UID 2000, so that Yocto does not raise warnings about a possible host contamination (as users identifiers in Desktop Linux usually start from 1000).

• Welma uses useradd-staticids that is a Yocto mechanism for setting deterministic user and group identifiers. By default, the files files/passwd and files/group (searched in BBPATH) give the list of fixed identifiers.