Skip to main content

Blog tag

yocto

Posts tagged with yocto.

  • Setting Up A/B OTA System Updates in Yocto for NXP i.MX with Verified Boot

    Shipping a production embedded Linux product on an NXP i.MX board eventually leads to the same question: how do we update these devices in the field without bricking them? If the product is going to live for five, ten, or fifteen years, the answer needs to be more robust than “SSH in and run apt upgrade.” For devices that cannot afford to brick under any circumstances, the established answer is A/B system updates: two copies of the system on separate partitions, a bootloader that picks between them, atomic switchover, and automatic rollback if the new copy does not come up cleanly.

    This article is a practical, technically detailed walk-through of how to build A/B system updates for NXP i.MX boards. The approach is generic across the i.MX 8, 8M, and 9 families; we have validated it end-to-end on the NXP FRDM-IMX91. Along the way, we cover partition layout, U-Boot configuration, A/B version selection from the bootloader, signed FIT images for verified boot, and dm-verity for runtime rootfs integrity, all the way up to how these pieces plug into a meta-imx build. By the end, you'll have a reference design that updates atomically, rolls back on failure, and cryptographically verifies boot artifacts and rootfs blocks, ready to drive with Rugix Ctrl or any other update engine.

    Read post
  • GitHub CI for Yocto Builds with NixOS

    You know you're in a very special niche when you write blog posts with both "NixOS" and "Yocto" in the title. But, here we go. If you're still reading, you're probably one of the few people who will actually appreciate this. Welcome. 👋

    At Silitics, we maintain meta-rugix, the Yocto layers for integrating Rugix Ctrl into Yocto-based systems. As the layers mature and gain more users, we need CI to catch issues before they ship. The problem: even our Debian-based Rugix Bakery builds are slow and hit disk limits on hosted runners, and Yocto is worse. We're talking hours of build time and 50+ GB of disk space. We kept putting it off, but we just set up self-hosted GitHub runners on NixOS, and it wasn't as painful as we feared.

    In this article, we'll walk through how we set up our CI infrastructure: declarative runner configuration, shared build caches, rootless Podman, and secrets management with SOPS. If you're struggling with Yocto CI, this might save you some headaches.

    Read post