On Thu, Jun 05, 2025 at 07:46:54PM +0200, [email protected] wrote: > Hi, > > On 04/06/2025 14:15, Martin Schwan wrote: > > This series implements a new bootmeth for RAUC A/B systems. RAUC (Robust > > Auto Update Controller) is a lightweight update client, providing "Safe > > and Secure OTA Updates for Embedded Linux". See the following links for > > more information about RAUC: > > > > https://rauc.io/ > > https://rauc.readthedocs.io/en/latest/ > > > > PHYTEC uses RAUC in its Yocto based distribution "Ampliphy" as the > > default way of updating embedded devices based on PHYTEC hardware. So > > far, the logic selecting the correct partitions and files to boot was > > being implemented in the U-Boot environment. While this is a > > straightforward way to do it, adding and supporting new platforms became > > somewhat tedious and is platform-specific. The introduction of U-Boot's > > "Standard Boot" provided a convincing alternative, promising a simpler > > and more portable way of booting, even for RAUC systems. This led me to > > implement a new bootmeth supporting RAUC A/B systems. Note, that this > > new bootmeth is not proprietary to PHYTEC products and is designed to > > work on other hardware with a RAUC A/B system, too. > > > > The bootmeth currently only supports symmetric A/B partitioning layouts. > > E.g. A/rescue is not (yet) supported. The partition indexes and default > > slot tries can be specified via configuration options. > > > > For now, the bootmeth_rauc uses a similar approach for loading the > > Kernel and device tree as the bootmeth_script, in that it requires a FIT > > containing a U-Boot script loading the desired distro. It could be > > possible to support booting without a script and load the Kernel and DT > > directly with this bootmeth, but I found the script method to be very > > flexible for now, in letting the distro decide what to load. > > > > The bootmeth_rauc was tested on a phyBOARD-Pollux i.MX8M Plus [1] with > > BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2 [2]. > > > > Supported boot devices are currently only MMC devices, but it should be > > possible to add SPI flashes in the future. > > It's quite a late comment, but this implementation has really nothing > specific to do with MMC, you could just support any block device. > > So if you could just add a config selecting the block type, defaulting > to mmc, this could be used on any block like USB, UFS, NVMe, ... with > almost 0 changes.
I raised this with v1. The challenge is that RAUC itself doesn't yet support non-MMC options. If/when that changes it's easy to update here. -- Tom
signature.asc
Description: PGP signature
