2025-05-16 –, Promenade 1
As an industrial company, having several hundreds of thousands IoT products on the market connected to the cloud, we have to respect the following rules:
- by 1 august 2025, "RED DR" (Radio Equipment Directive Delegated Regulation): Delegated regulation - 2022/30 - EN - EUR-Lex
- by 11 december 2027, "CRA" (Cyber Resilience Act): Regulation - 2024/2847 - EN - EUR-Lex
We think that the secure boot is important for the safety of our customers and then we created three different boot:
- PRODUCTION – with all enforcements enabled
- DEVELOPMENT – minimal enforcements allowing debug
- SWUPDATE – with all enforcement to allow to flash the PROD via OTA
How to have only one poky-tmp and not three to save cost and time?
Moreover due to Continuous Integration pull request approval workflow the build per year will increase. We have not found in the web and asking to many Yocto developers any proper solution so we hope to find it here at Yocto Project® Workshop at Embedded Recipes 2025.
In Embedded Linux development using the Yocto Project, managing multiple image variants often involves a trade-off between flexibility and build performance. In our current setup, we produce three distinct Yocto Images, each requiring a different Linux kernel configuration, particularly due to the presence or absence of dm-verity as a root filesystem integrity mechanism.
Despite leveraging Yocto’s multiconfig feature, we currently maintain three separate TMPDIR environments (poky-tmp) to avoid conflicts between build artifacts. While effective, this approach introduces significant performance and resources management challenges.
In spite of the shared state cache, separated TMPDIRs result in:
- Longer total build time: kernel compilation and tasks execution are still duplicated where TMPDIR isolation prevents reuse.
- Higher disk usage: separate TMPDIRs increase overall storage footprint.
- Continuous Integration complexity: maintaining multiple configurations increases maintenance and the potential for inconsistency.
The keys questions are:
- Can kernel, module, and rootfs separation be preserved within one TMPDIR?
- How do we prevent contamination and overwrite across builds?
- Are there Yocto best practices or tested strategies for this scenario?
A shared TMPDIR on top of the existing shared sstate-cache would be a natural next step to optimize our Yocto pipeline.
This workshop aims to validate whether this approach is viable in our current architecture and, if so, define a clear path for implementation.
At the end summarizing we would like:
- one Yocto board
- three kernels
- three file systems
- one poky TMPDIR
2000..now —> BTicino (www.bticino.com) part of Legrand (www.legrand.com)
- Embedded Linux specialist
“I put IoT working devices on the market for 10years, keeping them updated for cybersecurity”
Working in Linux BSP from pxa255, pxa270, dm365, dm3730, imx6, imx7, px30.
Involved from the idea of the product, software and hardware design, validation, after market support. Any debugging tools for RF, digital buses, jtag, needed to check hardware and BSP. RF experience on the field. Following new technical trends having a lot of technical contacts. Participating to conferences as FOSDE, ELC-E, Embedded World, MWC, in order to create new technical relationship with other developers and companies.
- Day by day teacher
inspiring new Zephyr operating system in the company, sport coach inside Bticino, teaching to new developers/tester from scratch.
1998..2000 —> Manzoni Group (1000+ tons stamping presses) from 1998 to 2000
Scada, software for strain gauge controller, technical intervention