MSC-LDK vs TRIA BSP for Linux:
A new foundation for embedded software
For many years, the MSC Linux Development Kit (MSC-LDK) provided the foundation for Linux development on Tria modules.
As software lifecycles become longer, and regulatory requirements such as the Cyber Resilience Act (CRA) introduce new maintenance expectations, the limitations of traditional Board Support Packages (BSP) structures become more apparent.
Tria’s new BSP architecture addresses these challenges with a more modular, maintainable, and reproducible approach to embedded Linux development
Why this new BSP architecture?
TRIA new software strategy was driven by several objectives:
- Modular and continuously maintained BSPs
- A unified software offering
- Easier software access
- Improved documentation
- Better support and service delivery
- CRA alignment and long-term software maintenance readiness
The result is a next-generation Linux BSP architecture built around three core principles:
- Simplicity
- Modularity
- Reproducibility
Simplifying build management with KAS
One of the most visible changes is how build workflows are defined and maintained.
From manifest-based software stacks…
MSC-LDK relied on manifests to define and assemble the collection of Yocto layers required for a given platform.
This approach provided a centralized development environment and helped ensure that developers worked with consistent software configurations across projects.
Over time, however, the software stack expanded to include numerous proprietary layers with dependencies between them. While this architecture effectively supports platform development and internal validation workflows, managing updates and migrations across software releases became more complex as the ecosystem grew.
… to reproducible KAS-based build environments
The new TRIA BSP uses KAS as its primary build entry point.
KAS is an open-source tool that simplifies Yocto builds by describing the entire build environment in a set of YAML configuration files.
Rather than manually managing multiple repositories and layer revisions, developers can define a complete build environment in a single file, including:
- Repository locations
- Branches and revisions
- Yocto layers
- Build settings
- Target hardware
- Optional software components
A typical Yocto build can be started with a single command like this one:
kas build machines/nxp/sm2s-imx8mp.yaml
To which you will need to add releases/tria-bsps-X.0.Y.yaml to lock the version.
The YAML file acts as a blueprint for the complete build environment. Any developer using the same configuration automatically builds the same software stack.
This approach removes a common challenge in Yocto-based development where build instructions exist in documentation rather than in version-controlled configuration files.
From monolithic BSPs to modular software stacks
From managing multiple dependencies manually…
Historically in the MSC-LDK, many layers had dependencies on each other.
As projects evolved, functionality such as hardware abstraction, application support, testing utilities, or platform-specific enhancements became closely integrated within the BSP structure. This increased complexity when upgrading or reusing individual components.
… to minimal interdependencies
The new Tria BSP architecture adopts a “LEGO-block” approach with minimal interdependencies between layers.
The BSP is divided into distinct functional building blocks:
- Vendor BSP layers
- Hardware abstraction
- Connectivity
- Distribution layers
- Security layers
- Device management
- Hardware testing
- Additional tooling and validation layers
Each layer has a clearly defined responsibility, making maintenance and upgrades significantly easier.
A typical stack now looks like:
(sm2s-imx8plus.yaml, tria-linux.yaml, …)
(distribution)
(abstraction)
(i.MX8, …)
(X86, …)
(Snapdragon)
Usable standalone with any Yocto distro
SM2S-IMX8MP, SM2S-ALN, …
Engineering teams only include only the functionality they need to stay in control while accelerating development.
BSP organization: from module-centric to CPU-centric
Another major architectural change is how BSPs are organized.
From a product-centric approach
The older architecture was largely organized around individual products (a specific COM module) and product-specific meta-layers. This could lead to duplicated effort across modules sharing the same processor family.
… to a consistent approach across processor families
The new BSP groups modules by silicon vendor and processor family.
Examples include:
- NXP: meta-tria-nxp
- Intel: meta-tria-intel
- Qualcomm: meta-tria-qualcomm
These layers provide only the essential hardware enablement required to support a given silicon platform.
This approach offers several advantages:
- Improved reuse across products
- Cleaner maintenance
- Easier platform updates
- Reduced duplication of functionality
Importantly, these silicon vendor BSP layers can be used independently of Tria-specific software components if desired.
From all-in-one BSPs to selectable software components
From a set of pre-integrated features
Features such as:
- OTA update frameworks
- Security capabilities
- Demo applications
- Additional services
were often integrated directly into the old board support package, making it difficult to keep the base platform minimal.
… to a minimalist base with optional add-ons to integrate later on
Optional functionality is now enabled through additional YAML files and meta-layers.
For instance:
- tria-os.yaml (our production-ready Yocto Linux distribution)
- tria-studio.yaml (our application development studio)
Firmware engineers can start with a minimal image and selectively add functionality as required.
For example:
kas build machines/nxp/sm2s-imx8mp.yaml:tria-linux.yaml
or
kas build machines/nxp/sm2s-imx8mp.yaml:tria-linux-systemd-wayland.yaml
This keeps the base BSP lean while providing flexibility for different project requirements.
Reproducibility: Building the same software, every time
From manual revisions…
Embedded software developers often had to manually select compatible repository revisions. Different engineers could end up building slightly different software stacks.
… to manifests to ensure reproducibility
The new workflow combines:
- Git manifests
- KAS configuration files
- Container-based build environments
to ensure all developers build from the exact same software revisions.
Additional capabilities include:
- KAS lockfiles
- Shared download caches
- Docker-based build environments
- Automated CI/CD integration
This greatly improves consistency across teams and simplifies long-term maintenance.
Modern software delivery with GitLab
The repository infrastructure has also evolved.
From Gitolite…
Source code was managed through Gitolite in Tria MSC-LDK. While effective as a Git server, it primarily focused on repository access control.
… to Gitlab DevOps platform
The new TRIA BSP platform is built around GitLab, providing:
- Source control
- Merge requests
- Issue tracking
- CI/CD pipelines
- Release management
- Packaging infrastructure
- Collaboration workflows
This creates a more complete software development ecosystem for both Tria engineering teams and customers.
Stronger maintenance and security commitments to meet the Cyber Resilience Act requirements
Perhaps the most important change is not technical but operational.
The new TRIA BSP architecture integrates strong security commitments for CRA compliance as well as additional, optional, capabilities:
- Maintenance of current and previous Yocto LTS releases
- Quarterly security updates
- Long-term software support
- Security hardening
- Device management capabilities
- OTA update frameworks
- And more…
Some of those functionalities are intentionally separated into dedicated layers such as:
- meta-tria-security
- meta-tria-device-mngr
rather than being embedded inside the BSP itself. This preserves BSP reusability while enabling additional functionality when required.
What changes for existing MSC-LDK users?
For existing MSC-LDK users, the new BSP introduces a different mindset.
Instead of assembling a large project structure and modifying it over time, the recommended workflow is:
- Select a machine YAML.
- Build the minimal BSP.
- Add only the required feature layers.
- Maintain reproducibility through manifests and KAS.
Conclusion
The transition from MSC-LDK to TRIA BSP is more than a tooling update. It represents a complete architectural redesign of the Tria Linux software stack.
For OEMs developing long-life industrial products, the practical outcome is an embedded Linux platform that is:
- easier to build,
- easier to maintain,
- and easier to evolve throughout the product lifecycle.
The new TRIA BSP turns software maintenance from a project-specific challenge into a repeatable and scalable process, helping teams bring products to market faster while preparing for long-term security and CRA compliance.