-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Simon,
On Thu, 2025-06-05 at 11:29 -0600, Simon Glass wrote: > Hi Martin, > > On Wed, 4 Jun 2025 at 06:16, Martin Schwan <[email protected]> > 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. > > > > To test this patch stack with PHYTEC's phyBOARD-Pollux i.MX8M Plus > > board, you need to adjust the boot files to include the > > boot.scr.uimg > > containing the distro's boot script and set "optargs" to > > "${raucargs}" > > in it. Also disable any legacyboot in the U-Boot environment and > > simply > > boot with Standard Boot: > > > > bootmeth order rauc > > bootflow scan -lb > > > > Regards, > > Martin > > > > [1]: > > https://www.phytec.eu/en/produkte/single-board-computer/phyboard-pollux/ > > [2]: > > https://download.phytec.de/Software/Linux/BSP-Yocto-i.MX8MP/BSP-Yocto-Ampliphy-i.MX8MP-PD24.1.2/ > > > > --- > > Changes in v3: > > - Invert if-statement check for setting default value of > > BOOT_*_LEFT env > > variables. This would falsely trigger an error message before. > > - Link to v2: > > https://lore.kernel.org/r/[email protected] > > > > Changes in v2: > > - Remove LOG_DEBUG from boot/bootmeth_rauc.c > > - Reorder asm/cache.h include to be last > > - Do not check for RAUC-specific files in the rootfs anymore. This > > does > > not work on encrypted root filesystems and is not a stable > > indicator > > for a functioning RAUC system. > > - Add a description of the term "slot" in the corresponding private > > struct. > > - Remove boot tries left from struct distro_rauc_slot. The boot > > tries > > are read directly from the environment, as that's the only > > correct > > source RAUC is relying on. > > - Remove the current boot_order from struct distro_rauc_priv, for > > the > > same reason as above (env is correct source). > > - Add function for retrieving a slot struct, to ease finding the > > right > > one when e.g. iterating or getting by name. > > - Fix multiline comments. > > - Fix various if-statements which were explicitly comparing to 0 or > > NULL. > > - Free various, temporary instances of allocated string lists. > > - Set default env values for BOOT_ORDER and associated BOOT_*_LEFT > > variables. These variables are mandatory for RAUC to work. > > - Use calloc() instead of malloc() for allocating the private > > slots. > > - Use config options for configuring the partitions and default > > boot > > order, instead of setting them via the U-Boot env. > > - Use bootstd_get_prefixes()'s return value and check all available > > prefixes for the boot script. > > - Add a proper boot order selection logic for the rauc bootmeth, > > similar > > to the previous environment scripting, with fallbacks and slot > > try > > checks. > > - Introduce config option for resetting all slot tries in case they > > are > > all zero. This may prevent a system from locking up in the > > bootloader. > > - Rename env variable "mmcroot" to "distro_rootpart", to be in line > > with > > "distro_bootpart". > > - Change the bootmeth flag to "global", as the rauc bootmeth does > > not > > work for individual partitions. > > - Update documentation accordingly. > > - Link to v1: > > https://lore.kernel.org/r/[email protected] > > > > --- > > Martin Schwan (2): > > bootstd: Add implementation for bootmeth rauc > > doc: Add description for bootmeth rauc > > > > boot/Kconfig | 51 +++++ > > boot/Makefile | 1 + > > boot/bootmeth_rauc.c | 432 > > +++++++++++++++++++++++++++++++++++++++ > > doc/develop/bootstd/index.rst | 1 + > > doc/develop/bootstd/overview.rst | 1 + > > doc/develop/bootstd/rauc.rst | 56 +++++ > > 6 files changed, 542 insertions(+) > > --- > > base-commit: b22a276f039f818d5564bec6637071cfc8a7e432 > > change-id: 20250129-wip-bootmeth-rauc-03b5e2dd88f4 > > > > Best regards, > > -- > > Martin Schwan <[email protected]> > > > > Great to see this. Could you please add a test, e.g. to > test/boot/bootflow.c ? Let me know if you need help. Thank you! :) I will have a look into adding a test for it. Sorry, that I didn't make it for the first iteration, as you mentioned it previously. Will it be okay, if I add this in a separate patch? I'll probably not have time for this until end of June, as I'm on vacation the next two weeks. But I definitely have it on my agenda. Regards, Martin > > Regards, > Simon -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQTh9jc8NBVKmMG9gxNR3YU452eTAQUCaEKRtwAKCRBR3YU452eT AdGKAP0UZJVaXbUol0KXr0zH7LAlvMPsx+aWQ1ZY1Z1NOjL+awEAmTEZcM3rgi8w He7kNGlqKKvSbgZCC4jlzcpMmruA1QQ= =tcMt -----END PGP SIGNATURE-----
