Yocto构建系统中OS更新方案咨询及工具选型疑问

Hey there! Let's break down your Yocto update-related questions one by one—this stuff can get a bit tangled, but I’ve spent plenty of time messing around with it, so here’s what I’ve learned:

1. Yocto构建系统中OS更新的工作机制是怎样的？ #

First off, Yocto itself doesn’t come with a full-fledged update system out of the box—it provides the foundation to build update-ready images, and you pair it with a dedicated update tool to handle the deployment part.

At build time, Yocto lets you generate different image formats (like partitioned WIC images, squashfs, or raw disk images) that are compatible with update tools. The key is that Yocto structures your system into discrete components (bootloader, kernel, rootfs, packages) that update tools can target individually. When you trigger an update, the tool will either:

• Replace entire partitions (common for A/B setups)
• Patch or overwrite specific files/packages
• Flash new binary components (like U-Boot or kernel) to their dedicated storage locations

Yocto also supports signing images and components, which is critical for secure updates—you can configure recipes to generate signed artifacts that update tools will verify before applying changes.

2. 如何实现Bootloader、Kernel、根文件系统文件、包的升级需求？ #

Let’s tackle each component separately:

Bootloader (U-Boot) #

• Update the build: To upgrade U-Boot, you can either modify the existing recipe in your BSP layer or create a u-boot.bbappend in your custom layer. Update the SRC_URI to point to the latest U-Boot source, adjust SRCREV to the correct commit/tag, and add any necessary patches for your hardware. Build the image, and Yocto will generate a new u-boot.bin.
• Enable updates: For deployment, you’ll need U-Boot to support things like environment variable persistence, or dual-boot (A/B) partitions. If using tools like swupdate or RAUC, you’ll need to configure their manifest files to specify the U-Boot binary path and the target partition. You might also need to add a U-Boot handler script to the update tool to flash the new binary safely.

Kernel Image (zImage/bzImage) #

• Update the build: Create a linux-custom.bbappend (or modify your existing kernel recipe) to point to the latest kernel source, update SRCREV, and apply any hardware-specific patches. Yocto will compile the new kernel image and device tree blobs (DTBs).
• Deployment: Use your update tool to write the new kernel and DTB to their dedicated partitions. For A/B setups, you’ll flash to the inactive partition and switch to it on reboot.

根文件系统新增文件（脚本/可执行文件） #

• Add during build: Create a custom recipe (e.g., my-custom-assets.bb) where you use the do_install task to copy your scripts/executables to ${D}/usr/bin (or another appropriate path). Add this recipe to IMAGE_INSTALL in your image recipe to include it in the rootfs.
• Update post-deployment: If you need to add files without rebuilding the entire image, use a package management tool (like opkg) by packaging the assets into a .ipkg, host it on a package feed, and install it on the device with opkg install my-custom-assets. Alternatively, tools like swupdate can push individual files to the rootfs via its manifest.

包的添加/升级（如dropbear） #

• Upgrade an existing package: If you want to update dropbear to the latest version, create a dropbear.bbappend in your custom layer. Update SRC_URI to the latest source tarball, set SRCREV to the correct commit, and adjust any build flags if needed. Yocto will compile the updated package and include it in your image.
• Add a new package: Simply add dropbear to IMAGE_INSTALL or CORE_IMAGE_EXTRA_INSTALL in your image recipe. If you need it installed post-deployment, use opkg install dropbear (assuming you’ve set up a package feed).

3. 更新是整体式还是仅增量更新必要部分？ #

Yocto supports both—you get to choose based on your use case:

• 整体更新: Just like Buildroot, you can generate a full system image (e.g., core-image-full-cmdline.wic) and reflash the entire storage device. This is simple and reliable for small devices or initial deployments, but it’s bandwidth-heavy and downtime is longer.
• 增量更新: You can use tools like swupdate, RAUC, or package managers to only update the parts that changed:
  • swupdate can generate delta patches to update specific components (kernel, bootloader, individual files) without reflashing the whole system.
  • RAUC uses A/B partitions—you flash updates to the inactive partition, then switch to it on reboot, so only the inactive partition is written to.
  • Package managers (opkg/rpm) let you update individual packages without touching the rest of the system, which is great for app-level updates.

4. 更新工具的最佳选型？ #

There’s no one-size-fits-all answer, but here’s how to pick based on your needs:

• swupdate: Lightweight, flexible, and perfect for most embedded use cases. It supports local (USB/SD) and network updates, handles all components (bootloader, kernel, rootfs), and supports signing/verification. It’s easy to integrate with Yocto via the meta-swupdate layer, and the manifest-based configuration makes it straightforward to define what gets updated.
• RAUC: If reliability is your top priority (e.g., industrial devices), RAUC is the way to go. It’s built around A/B partition updates, which means you can roll back instantly if an update fails. It has strong security features (signing, encryption) and integrates seamlessly with Yocto via meta-rauc.
• opkg/rpm: Ideal if you need frequent, granular updates (like upgrading a single app). It’s great for devices with network connectivity, but it’s not suitable for bootloader or kernel updates, and your rootfs needs to be built with package management support.
• Mender/Foundries.io: These are end-to-end OTA platforms, great for managing large fleets of devices. They handle image building, secure delivery, deployment, and rollback. They’re open-source with commercial support, but they might be overkill for small projects.

For most small to medium embedded projects, swupdate is a solid default. If you need A/B redundancy, go with RAUC.

内容的提问来源于stack exchange，提问作者md.jamal