[PATCH v3 0/2] bootstd: New bootmeth for RAUC A/B systems

[Martin Schwan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Tom,
Hi Neil,

first of all: Thank you for the kind words!

On Thu, 2025-06-05 at 22:56 +0200, Neil Armstrong wrote:
> On 05/06/2025 22:02, Tom Rini wrote:
> > On Thu, Jun 05, 2025 at 07:46:54PM +0200,
> > neil.armstrong at linaro.org 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.
> > 
> 
> Ack thx, indeed the code change would be minimal

Neil is theoretically right here and some additional block devices are
supported by RAUC, which are currently not supported by the
bootmeth_rauc. The offical RAUC documentation [1] lists the following
supported devices:

- - SD card
- - e.MMC
- - SSD/NVMe
- - NAND

I've added this to my to-do list, so at least SSD and NVMe drives will
be properly supported in the future. I'll send a separate patch for
that.

Raw NAND flash is another story, as these typically do not have real
partitions, but rather work with raw offsets or UBI volumes. Again, I'd
consider this something to be for a separate patch.

Regards,
Martin

[1]:
https://rauc.readthedocs.io/en/latest/integration.html#partitioning-your-device

> 
> Neil

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQTh9jc8NBVKmMG9gxNR3YU452eTAQUCaEKU3gAKCRBR3YU452eT
AVCkAP9hy9rEehwIYltNj1ZcLL9zbON2df5mkSqMeJN8BKzV1QEApoR4+Zn4AzqR
qV8RPVcrcXfor74PcAtO7QuCExb4hAI=
=kd+J
-----END PGP SIGNATURE-----