Reliable update of redundant images

[Stefan.Herb...@weidmueller.com]

Hi,

does SWUpdate supports a reliable update of redundant images? The device always tries to load the primary image and falls back to the secondary image on failure. A simple two image update could break the device when a power loss happens during an update of the first image and the second image isn't completed updated because of an early power loss.

Regards,

Stefan Herbrechtsmeier
Entwickler Software Embedded Systems

Let's connect.

________________________________
Kommanditgesellschaft - Sitz: Detmold - Amtsgericht Lemgo HRA 2790 -
Komplementärin: Weidmüller Interface Führungsgesellschaft mbH -
Sitz: Detmold - Amtsgericht Lemgo HRB 3924;
Geschäftsführer: José Carlos Álvarez Tobar, Elke Eckstein, Jörg Timmermann;
USt-ID-Nr. DE124599660

[Stefano Babic]

Hi Stefan,

On 28/09/2017 14:52, Stefan.Herb...@weidmueller.com wrote:
> Hi,
>
> does SWUpdate supports a reliable update of redundant images?

SWUpdate supports *multiple* images and it is not constrained to have
just two copies (running and standby) of software. Of course, SWUpdate
cannot do anything against a broken concept. Each project should take
care of the own goals and configure SWUpdate *and* the bootloader to
minimize risks. SWUpdate alone cannot do anything.

> The device always tries to load the primary image and falls back to the secondary image on failure. A simple two image update could break the device when a power loss happens during an update of the first image and the second image isn't completed updated because of an early power loss.

No you, are wrong. There is no update of "first" or "second", there is a
"running" and "stand-by" image.

SWUpdate works as a transaction and inform the bootloader that an update
is running by setting the variable "recovery". If "recovery" is set, the
bootloader is not allowed to start the "standby".

Best regards,
Stefano Babic

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Stefan.Herb...@weidmueller.com]

Hi Stefano,

> -----Ursprüngliche Nachricht-----
> Von: Stefano Babic [mailto:sba...@denx.de]
> Gesendet: Freitag, 29. September 2017 12:47
> An: Herbrechtsmeier Dr.-Ing. , Stefan; swup...@googlegroups.com
> Betreff: Re: [swupdate] Reliable update of redundant images

>
> On 28/09/2017 14:52, Stefan.Herb...@weidmueller.com wrote:
> > does SWUpdate supports a reliable update of redundant images?
>
> SWUpdate supports *multiple* images and it is not constrained to have
> just two copies (running and standby) of software. Of course, SWUpdate
> cannot do anything against a broken concept. Each project should take
> care of the own goals and configure SWUpdate *and* the bootloader to
> minimize risks.

You are right if we speak about an operating system update but I speak about a boot loader and secondary program loader update. It is a common concept of a boot rom to try different boot images in a fixed order and even the default secondary program loader use a fixed order of different boot devices.

> SWUpdate alone cannot do anything.

SWUpdate for example could memorize the last successful updated redundant image in the boot loader environment and update this image after the other redundant image was successful updated. Therefore you need to reorder the image updates.

> > The device always tries to load the primary image and falls back to
> the secondary image on failure. A simple two image update could break
> the device when a power loss happens during an update of the first
> image and the second image isn't completed updated because of an early
> power loss.
>
> No you, are wrong. There is no update of "first" or "second", there is
> a "running" and "stand-by" image.

This is only true if you could influence the boot process and this isn't always possible.

> SWUpdate works as a transaction and inform the bootloader that an
> update is running by setting the variable "recovery". If "recovery" is
> set, the bootloader is not allowed to start the "standby".

This only works for one image instance of a dual copy but fails if you have more than one image with a dual copy. I suppose you reference the software collections but they are designed for a single dual copy instance.

The boot loader and secondary program loader are really redundant and I need to update the "primary" and "fallback" image. Normally the system use the "primary" image and only use the "fallback" image if the update of the "primary" image got interrupted. Therefore I need to control the images order at runtime and update the boot loader environment between the separate image updates or better verify the images and always starts with a corrupted image.

[Stefano Babic]

Hi Stefan,

On 29/09/2017 15:49, Stefan.Herb...@weidmueller.com wrote:
> Hi Stefano,
>
>> -----Ursprüngliche Nachricht-----
>> Von: Stefano Babic [mailto:sba...@denx.de]
>> Gesendet: Freitag, 29. September 2017 12:47
>> An: Herbrechtsmeier Dr.-Ing. , Stefan; swup...@googlegroups.com
>> Betreff: Re: [swupdate] Reliable update of redundant images
>>
>> On 28/09/2017 14:52, Stefan.Herb...@weidmueller.com wrote:
>>> does SWUpdate supports a reliable update of redundant images?
>>
>> SWUpdate supports *multiple* images and it is not constrained to have
>> just two copies (running and standby) of software. Of course, SWUpdate
>> cannot do anything against a broken concept. Each project should take
>> care of the own goals and configure SWUpdate *and* the bootloader to
>> minimize risks.
>
> You are right if we speak about an operating system update but I speak about a boot loader and secondary program loader update.

SWUpdate is unaware of the nature of each artifact.

> It is a common concept of a boot rom to try different boot images in a fixed order and even the default secondary program loader use a fixed order of different boot devices.

As I said, you should *accurately* check the use case, because it is
different for each SOC. Take into account that the SPL code (seconary
program loader ? We are talking of U-Boot, right ?) just check the
header of the u-boot image. You have to ensure that the header is
written at the end and not at the beginning of U-Boot image.

>
>> SWUpdate alone cannot do anything.
>
> SWUpdate for example could memorize the last successful updated redundant image in the boot loader environment

...well, you have said that this is checked by U-Boot. As said, SWUpdate
cannot guarantee all. The whole concept must be proofed, and includes
which U-Boot scripts are running and which variables are set.

> and update this image after the other redundant image was successful updated. Therefore you need to reorder the image updates.

Environment is *always* set as last part of the update.

>
>>> The device always tries to load the primary image and falls back to
>> the secondary image on failure. A simple two image update could break
>> the device when a power loss happens during an update of the first
>> image and the second image isn't completed updated because of an early
>> power loss.
>>
>> No you, are wrong. There is no update of "first" or "second", there is
>> a "running" and "stand-by" image.
>
> This is only true if you could influence the boot process and this isn't always possible.

Can you tell me the use case ? Why is it not possible ?

>
>> SWUpdate works as a transaction and inform the bootloader that an
>> update is running by setting the variable "recovery". If "recovery" is
>> set, the bootloader is not allowed to start the "standby".
>
> This only works for one image instance of a dual copy but fails if you have more than one image with a dual copy. I suppose you reference the software collections but they are designed for a single dual copy instance.

Wrong. collections are designed to make the setup as more generic as
possible. I can have three copies, four copies, a setup just for the
factory,...

>
> The boot loader and secondary program loader are really redundant and I need to update the "primary" and "fallback" image. Normally the system use the "primary" image and only use the "fallback" image if the update of the "primary" image got interrupted. Therefore I need to control the images order at runtime and update the boot loader environment between the separate image updates or better verify the images and always starts with a corrupted image.

The SPL is not under your full control - which SPL is taken, it depends
(generally) on hardware configuration (boot pins, fuses) or how it is
set. Anyway, redundant bootloader can be reached together with SWUpdate,
design (including U-Boot scripts, sw-description, U-Boot environment)
must take care of it.

[Stefan.Herb...@weidmueller.com]

Hi Stefano,

> -----Ursprüngliche Nachricht-----
> Von: Stefano Babic [mailto:sba...@denx.de]

> Gesendet: Freitag, 29. September 2017 16:19
> An: Herbrechtsmeier Dr.-Ing. , Stefan; sba...@denx.de;
> swup...@googlegroups.com
> Betreff: Re: AW: [swupdate] Reliable update of redundant images

Normally the SPL and even most boot roms only check the header, but if I enable secure boot they should check the full image. However the saved solution is to build a valid header at the end.

> >> SWUpdate alone cannot do anything.
> >
> > SWUpdate for example could memorize the last successful updated
> > redundant image in the boot loader environment
>
>
> ...well, you have said that this is checked by U-Boot. As said,
> SWUpdate cannot guarantee all. The whole concept must be proofed, and
> includes which U-Boot scripts are running and which variables are set.
>
> > and update this image after the other redundant image was successful
> updated. Therefore you need to reorder the image updates.
>
> Environment is *always* set as last part of the update.
>
> >
> >>> The device always tries to load the primary image and falls back to
> >> the secondary image on failure. A simple two image update could
> break
> >> the device when a power loss happens during an update of the first
> >> image and the second image isn't completed updated because of an
> >> early power loss.
> >>
> >> No you, are wrong. There is no update of "first" or "second", there
> >> is a "running" and "stand-by" image.
> >
> > This is only true if you could influence the boot process and this
> isn't always possible.
>
> Can you tell me the use case ? Why is it not possible ?

I need a reliable update process of the SPL and boot loader.

> >> SWUpdate works as a transaction and inform the bootloader that an
> >> update is running by setting the variable "recovery". If "recovery"
> >> is set, the bootloader is not allowed to start the "standby".
> >
> > This only works for one image instance of a dual copy but fails if
> you have more than one image with a dual copy. I suppose you reference
> the software collections but they are designed for a single dual copy
> instance.
>
> Wrong. collections are designed to make the setup as more generic as
> possible. I can have three copies, four copies, a setup just for the
> factory,...

I mean a system with a dual boot loader and a dual SWUpdate image. I have two independent "running" images. At the moment I have to describe any combination as a separate collection.

> > The boot loader and secondary program loader are really redundant and
> I need to update the "primary" and "fallback" image. Normally the
> system use the "primary" image and only use the "fallback" image if the
> update of the "primary" image got interrupted. Therefore I need to
> control the images order at runtime and update the boot loader
> environment between the separate image updates or better verify the
> images and always starts with a corrupted image.
>
> The SPL is not under your full control - which SPL is taken, it depends
> (generally) on hardware configuration (boot pins, fuses) or how it is
> set. Anyway, redundant bootloader can be reached together with
> SWUpdate, design (including U-Boot scripts, sw-description, U-Boot
> environment) must take care of it.

How would you handle a reliable update of a redundant boot loader?

Based on your comments and a review of the boot process I see two possible designs:

In both designs the SPL and boot loader form a unity and will be updated together. This simplify the update process and minimize the test cases.

Instead of a redundant SPL and boot loader I use the boot rom functionality to implement a dual image design. In place of a boot loader environment variable the "running" SPL image is marked by a valid image header. The switch between this images is done inside the boot loader and controlled by a boot loader environment variable. The simplest solution is to erase some well known four bytes from the SPL header in the update image and overwrite this bytes inside the nor flash from the boot loader if the "running" SPL image from the boot loader environment variable and the actual "running" SPL image are different. Additionally the "stand-by" SPL image will be erased or the well known bytes will be overwritten by zero and the boot loader will reset the device.

Alternative the redundant SPL and boot loader are only used during their update process. SWUpdate always updates the secondary SPL as well as boot loader and sets a boot loader environment variable. If this variable is set the boot loader erases the SPL and copies the secondary boot loader over the primary boot loader. Then the boot loader reads the SPL into memory, erases the well known bytes, overwrites the primary SPL, writes the well known bytes, clears the environment variable and reset the device.

In both cases any power loss will restart the update process inside the boot loader and the redundancy is only used for a reliable update process.

The advantage of the second design is the uniform boot process after each update. The disadvantage is that SWUpdate sets the boot loader environment on every update even if an image is skipped because of the "install-if-different" property.

Best regards,

Stefan Herbrechtsmeier
Software Developer Embedded Systems

[Stefano Babic]

Hi Stefan,

On 04/10/2017 10:28, Stefan.Herb...@weidmueller.com wrote:

>> As I said, you should *accurately* check the use case, because it is
>> different for each SOC. Take into account that the SPL code (seconary
>> program loader ? We are talking of U-Boot, right ?) just check the
>> header of the u-boot image. You have to ensure that the header is
>> written at the end and not at the beginning of U-Boot image.
>
> Normally the SPL and even most boot roms only check the header, but if I enable secure boot they should check the full image.

That's true - ok, then I guess you have a i.MX6. Without signing SPL,
the Bootrom does not check the header, but just the magic number in the
Header. But with secure boot, the SPL is checked by HAB, right.

> However the saved solution is to build a valid header at the end.

Right.

>
>>>> SWUpdate alone cannot do anything.
>>>
>>> SWUpdate for example could memorize the last successful updated
>>> redundant image in the boot loader environment
>>
>>
>> ...well, you have said that this is checked by U-Boot. As said,
>> SWUpdate cannot guarantee all. The whole concept must be proofed, and
>> includes which U-Boot scripts are running and which variables are set.
>>
>>> and update this image after the other redundant image was successful
>> updated. Therefore you need to reorder the image updates.
>>
>> Environment is *always* set as last part of the update.
>>
>>>
>>>>> The device always tries to load the primary image and falls back to
>>>> the secondary image on failure. A simple two image update could
>> break
>>>> the device when a power loss happens during an update of the first
>>>> image and the second image isn't completed updated because of an
>>>> early power loss.
>>>>
>>>> No you, are wrong. There is no update of "first" or "second", there
>>>> is a "running" and "stand-by" image.
>>>
>>> This is only true if you could influence the boot process and this
>> isn't always possible.
>>
>> Can you tell me the use case ? Why is it not possible ?
>
> I need a reliable update process of the SPL and boot loader.

You do not explain why you cannot influence the boot process.

>
>>>> SWUpdate works as a transaction and inform the bootloader that an
>>>> update is running by setting the variable "recovery". If "recovery"
>>>> is set, the bootloader is not allowed to start the "standby".
>>>
>>> This only works for one image instance of a dual copy but fails if
>> you have more than one image with a dual copy. I suppose you reference
>> the software collections but they are designed for a single dual copy
>> instance.
>>
>> Wrong. collections are designed to make the setup as more generic as
>> possible. I can have three copies, four copies, a setup just for the
>> factory,...
>
> I mean a system with a dual boot loader and a dual SWUpdate image. I have two independent "running" images. At the moment I have to describe any combination as a separate collection.

I do not understand. SPL + U-Boot is like to have kernel outside rootfs.
If you have two independent running images, you have two copies of the
whole software including SPL+U-Boot. You have just to invalidate the old
SPL copy when update is finished, but you lose fallback.

>
>>> The boot loader and secondary program loader are really redundant and
>> I need to update the "primary" and "fallback" image. Normally the
>> system use the "primary" image and only use the "fallback" image if the
>> update of the "primary" image got interrupted. Therefore I need to
>> control the images order at runtime and update the boot loader
>> environment between the separate image updates or better verify the
>> images and always starts with a corrupted image.
>>
>> The SPL is not under your full control - which SPL is taken, it depends
>> (generally) on hardware configuration (boot pins, fuses) or how it is
>> set. Anyway, redundant bootloader can be reached together with
>> SWUpdate, design (including U-Boot scripts, sw-description, U-Boot
>> environment) must take care of it.
>
> How would you handle a reliable update of a redundant boot loader?
>
> Based on your comments and a review of the boot process I see two possible designs:
>
> In both designs the SPL and boot loader form a unity and will be updated together.

They *must* be together. Even if someone splits them, they belong
together. U-Boot does not ensure that a new u-boot.img can work with an
older SPL.

> This simplify the update process and minimize the test cases.

ok

>
> Instead of a redundant SPL and boot loader I use the boot rom functionality to implement a dual image design.

Maybe I am wrong, new speculation, you have Zync / Ultrascale...

I guess I cannot be more precise without knowing the SOC. In fact, what
you want to reach is not something related to SWUpdate, but it is
strictly connected to the features that the SOC has. Different SOC,
maybe different solution.

> In place of a boot loader environment variable the "running" SPL image is marked by a valid image header.

I am losing you. A boot loader variable is a U-Boot variable. This is
evaluated in SPL (if environment is enabled in SPL) or more probably in
U-Boot. But not by the bootrom, that decides on some other conditions
(bootpins, fuses, etc.)

So I do not understand the reason of the U-Boot variable. Yes, you can
switch in SWUpdate if you write a wrong header into the old (and now
updated) SPL.

> The switch between this images is done inside the boot loader and controlled by a boot loader environment variable.

That means that after an update you are running the old SPL+U-Boot, that
should make the copy and the switch - bad.

If you have updated, you should run the updated software, and not the
old one, right ?

> The simplest solution is to erase some well known four bytes from the SPL header in the update image and overwrite this bytes inside the nor flash from the boot loader if the "running" SPL image from the boot loader environment variable and the actual "running" SPL image are different. Additionally the "stand-by" SPL image will be erased or the well known bytes will be overwritten by zero and the boot loader will reset the device.

Something in this way depending on your SOC, right.

>
> Alternative the redundant SPL and boot loader are only used during their update process. SWUpdate always updates the secondary SPL as well as boot loader and sets a boot loader environment variable. If this variable is set the boot loader erases the SPL and copies the secondary boot loader over the primary boot loader.

You are still running the old copy....

> Then the boot loader reads the SPL into memory, erases the well known bytes, overwrites the primary SPL, writes the well known bytes, clears the environment variable and reset the device.
>
> In both cases any power loss will restart the update process inside the boot loader and the redundancy is only used for a reliable update process.
>
> The advantage of the second design is the uniform boot process after each update. The disadvantage is that SWUpdate sets the boot loader environment on every update even if an image is skipped because of the "install-if-different" property.

Best regards,

[Stefan.Herb...@weidmueller.com]

Hi Stefano,

> -----Ursprüngliche Nachricht-----
> Von: Stefano Babic [mailto:sba...@denx.de]

> Gesendet: Mittwoch, 4. Oktober 2017 11:01

> An: Herbrechtsmeier Dr.-Ing. , Stefan; sba...@denx.de;
> swup...@googlegroups.com

> Betreff: Re: AW: AW: [swupdate] Reliable update of redundant images

>
> On 04/10/2017 10:28, Stefan.Herb...@weidmueller.com wrote:
>
> >> As I said, you should *accurately* check the use case, because it is
> >> different for each SOC. Take into account that the SPL code
> (seconary
> >> program loader ? We are talking of U-Boot, right ?) just check the
> >> header of the u-boot image. You have to ensure that the header is
> >> written at the end and not at the beginning of U-Boot image.
> >
> > Normally the SPL and even most boot roms only check the header, but
> if I enable secure boot they should check the full image.
>
> That's true - ok, then I guess you have a i.MX6. Without signing SPL,
> the Bootrom does not check the header, but just the magic number in the
> Header. But with secure boot, the SPL is checked by HAB, right.

I have a Xilinx Zynq with a similar behavior.

You are right I can influence the boot process but only indirect by a valid header of the primary image.

> >>>> SWUpdate works as a transaction and inform the bootloader that an
> >>>> update is running by setting the variable "recovery". If
> "recovery"
> >>>> is set, the bootloader is not allowed to start the "standby".
> >>>
> >>> This only works for one image instance of a dual copy but fails if
> >> you have more than one image with a dual copy. I suppose you
> >> reference the software collections but they are designed for a
> single
> >> dual copy instance.
> >>
> >> Wrong. collections are designed to make the setup as more generic as
> >> possible. I can have three copies, four copies, a setup just for the
> >> factory,...
> >
> > I mean a system with a dual boot loader and a dual SWUpdate image. I
> have two independent "running" images. At the moment I have to describe
> any combination as a separate collection.
>
> I do not understand. SPL + U-Boot is like to have kernel outside
> rootfs.
> If you have two independent running images, you have two copies of the
> whole software including SPL+U-Boot. You have just to invalidate the
> old SPL copy when update is finished, but you lose fallback.

This assume that I always update the whole software even when the boot loader is the same. Why not only update the kernel and rootfs?

I have a Zync

> I guess I cannot be more precise without knowing the SOC. In fact, what
> you want to reach is not something related to SWUpdate, but it is
> strictly connected to the features that the SOC has. Different SOC,
> maybe different solution.

You are right.

> > In place of a boot loader environment variable the "running" SPL
> image is marked by a valid image header.
>
> I am losing you. A boot loader variable is a U-Boot variable. This is
> evaluated in SPL (if environment is enabled in SPL) or more probably in
> U-Boot. But not by the bootrom, that decides on some other conditions
> (bootpins, fuses, etc.)

Correct, therefore I have to use a valid header to mark the "running" SPL.

> So I do not understand the reason of the U-Boot variable. Yes, you can
> switch in SWUpdate if you write a wrong header into the old (and now
> updated) SPL.
>
> > The switch between this images is done inside the boot loader and
> controlled by a boot loader environment variable.
>
> That means that after an update you are running the old SPL+U-Boot,
> that should make the copy and the switch - bad.
>
> If you have updated, you should run the updated software, and not the
> old one, right ?

This means the following procedure must be run inside the SWUpdate image. Is it possible to write some bytes inside a MTD device without first erasing a sector?

> > The simplest solution is to erase some well known four bytes from the
> SPL header in the update image and overwrite this bytes inside the nor
> flash from the boot loader if the "running" SPL image from the boot
> loader environment variable and the actual "running" SPL image are
> different. Additionally the "stand-by" SPL image will be erased or the
> well known bytes will be overwritten by zero and the boot loader will
> reset the device.
>
> Something in this way depending on your SOC, right.
>
> >
> > Alternative the redundant SPL and boot loader are only used during
> their update process. SWUpdate always updates the secondary SPL as well
> as boot loader and sets a boot loader environment variable. If this
> variable is set the boot loader erases the SPL and copies the secondary
> boot loader over the primary boot loader.
>
> You are still running the old copy....

Yes the whole update takes places inside the old boot loader.

> > Then the boot loader reads the SPL into memory, erases the well known
> bytes, overwrites the primary SPL, writes the well known bytes, clears
> the environment variable and reset the device.
> >
> > In both cases any power loss will restart the update process inside
> the boot loader and the redundancy is only used for a reliable update
> process.
> >
> > The advantage of the second design is the uniform boot process after
> each update. The disadvantage is that SWUpdate sets the boot loader
> environment on every update even if an image is skipped because of the
> "install-if-different" property.
>

If I understand you correct you propose to use a post script to build a valid header inside the "stand-by" SPL image and erase the "running" SPL image to direct activate the new SPL image.

What happens if I use the "install-if-different" property and the boot loader is already up to date? How could I skip the post script?

Kind regards,

[Stefano Babic]

Hi Stefan,

On 04/10/2017 11:40, Stefan.Herb...@weidmueller.com wrote:

>>>>>> SWUpdate works as a transaction and inform the bootloader that an
>>>>>> update is running by setting the variable "recovery". If
>> "recovery"
>>>>>> is set, the bootloader is not allowed to start the "standby".
>>>>>
>>>>> This only works for one image instance of a dual copy but fails if
>>>> you have more than one image with a dual copy. I suppose you
>>>> reference the software collections but they are designed for a
>> single
>>>> dual copy instance.
>>>>
>>>> Wrong. collections are designed to make the setup as more generic as
>>>> possible. I can have three copies, four copies, a setup just for the
>>>> factory,...
>>>
>>> I mean a system with a dual boot loader and a dual SWUpdate image. I
>> have two independent "running" images. At the moment I have to describe
>> any combination as a separate collection.
>>
>> I do not understand. SPL + U-Boot is like to have kernel outside
>> rootfs.
>> If you have two independent running images, you have two copies of the
>> whole software including SPL+U-Boot. You have just to invalidate the
>> old SPL copy when update is finished, but you lose fallback.
>
> This assume that I always update the whole software even when the boot loader is the same. Why not only update the kernel and rootfs?

Even then, of course.

>>
>> Maybe I am wrong, new speculation, you have Zync / Ultrascale...
>
> I have a Zync

Ok, second speculation was correct :-)

>>
>> If you have updated, you should run the updated software, and not the
>> old one, right ?
>
> This means the following procedure must be run inside the SWUpdate image. Is it possible to write some bytes inside a MTD device without first erasing a sector?

Use the "rawfile" handler instead of "flash" handler. If you write
zeroes, it works.

>>> Then the boot loader reads the SPL into memory, erases the well known
>> bytes, overwrites the primary SPL, writes the well known bytes, clears
>> the environment variable and reset the device.
>>>
>>> In both cases any power loss will restart the update process inside
>> the boot loader and the redundancy is only used for a reliable update
>> process.
>>>
>>> The advantage of the second design is the uniform boot process after
>> each update. The disadvantage is that SWUpdate sets the boot loader
>> environment on every update even if an image is skipped because of the
>> "install-if-different" property.
>>
>
> If I understand you correct you propose to use a post script to build a valid header inside the "stand-by" SPL image and erase the "running" SPL image to direct activate the new SPL image.
>
> What happens if I use the "install-if-different" property and the boot loader is already up to date? How could I skip the post script?

If you add a version verification inside your post-install script, you
can do it.

[Stefan.Herb...@weidmueller.com]

Hi Stefano,

> -----Ursprüngliche Nachricht-----
> Von: Stefano Babic [mailto:sba...@denx.de]

> Gesendet: Mittwoch, 4. Oktober 2017 11:48

> An: Herbrechtsmeier Dr.-Ing. , Stefan; sba...@denx.de;
> swup...@googlegroups.com

> Betreff: Re: AW: AW: AW: [swupdate] Reliable update of redundant images

This means for you the system has always only one single state even if the system has multiple independent configurations and I have to describe each combination as a single collection. As example for a dual copy of boot loader and SWUpdate I have four collections. Thereby each boot loader image configuration is redundantly described inside two collections, each SWUpdate image configuration is redundantly described in two configurations and common images like root filesystem are redundantly described in all collections?

> >> Maybe I am wrong, new speculation, you have Zync / Ultrascale...
> >
> > I have a Zync
>
> Ok, second speculation was correct :-)
>
> >>
> >> If you have updated, you should run the updated software, and not
> the
> >> old one, right ?
> >
> > This means the following procedure must be run inside the SWUpdate
> image. Is it possible to write some bytes inside a MTD device without
> first erasing a sector?
>
> Use the "rawfile" handler instead of "flash" handler. If you write
> zeroes, it works.

The files are handled before the images. This means I have to manipulate the SPL inside the nor flash from a post script.

> >>> Then the boot loader reads the SPL into memory, erases the well
> >>> known
> >> bytes, overwrites the primary SPL, writes the well known bytes,
> >> clears the environment variable and reset the device.
> >>>
> >>> In both cases any power loss will restart the update process inside
> >> the boot loader and the redundancy is only used for a reliable
> update
> >> process.
> >>>
> >>> The advantage of the second design is the uniform boot process
> after
> >> each update. The disadvantage is that SWUpdate sets the boot loader
> >> environment on every update even if an image is skipped because of
> >> the "install-if-different" property.
> >>
> >
> > If I understand you correct you propose to use a post script to build
> a valid header inside the "stand-by" SPL image and erase the "running"
> SPL image to direct activate the new SPL image.
> >
> > What happens if I use the "install-if-different" property and the
> boot loader is already up to date? How could I skip the post script?
>
> If you add a version verification inside your post-install script, you
> can do it.

This means I have to pass the version of the boot loader inside the cpio via data attribute to the post-install script or it is possible to access the image list from a post-install script?

Best regards,

Stefan Herbrechtsmeier
Entwickler Software Embedded Systems

[Stefano Babic]

Hi Stefan,

Yes, you could do in this way - if I had to do, I have considered all
together, that is bootloader is part of the release and I still have two
configurations.

> Thereby each boot loader image configuration is redundantly described inside two collections, each SWUpdate image configuration is redundantly described in two configurations and common images like root filesystem are redundantly described in all collections?
>
>>>> Maybe I am wrong, new speculation, you have Zync / Ultrascale...
>>>
>>> I have a Zync
>>
>> Ok, second speculation was correct :-)
>>
>>>>
>>>> If you have updated, you should run the updated software, and not
>> the
>>>> old one, right ?
>>>
>>> This means the following procedure must be run inside the SWUpdate
>> image. Is it possible to write some bytes inside a MTD device without
>> first erasing a sector?
>>
>> Use the "rawfile" handler instead of "flash" handler. If you write
>> zeroes, it works.
>
> The files are handled before the images. This means I have to manipulate the SPL inside the nor flash from a post script.

This is correct, right. Up now, the order of the installation is not
sured. Anyway, you are not the first raising this topic, and maybe this
will be changed in future.

>
>>>>> Then the boot loader reads the SPL into memory, erases the well
>>>>> known
>>>> bytes, overwrites the primary SPL, writes the well known bytes,
>>>> clears the environment variable and reset the device.
>>>>>
>>>>> In both cases any power loss will restart the update process inside
>>>> the boot loader and the redundancy is only used for a reliable
>> update
>>>> process.
>>>>>
>>>>> The advantage of the second design is the uniform boot process
>> after
>>>> each update. The disadvantage is that SWUpdate sets the boot loader
>>>> environment on every update even if an image is skipped because of
>>>> the "install-if-different" property.
>>>>
>>>
>>> If I understand you correct you propose to use a post script to build
>> a valid header inside the "stand-by" SPL image and erase the "running"
>> SPL image to direct activate the new SPL image.
>>>
>>> What happens if I use the "install-if-different" property and the
>> boot loader is already up to date? How could I skip the post script?
>>
>> If you add a version verification inside your post-install script, you
>> can do it.
>
> This means I have to pass the version of the boot loader inside the cpio via data attribute to the post-install script or it is possible to access the image list from a post-install script?

No, it is not possible and it is not foreseen.

[Stefan.Herb...@weidmueller.com]

Hi Stefano,

> -----Ursprüngliche Nachricht-----
> Von: Stefano Babic [mailto:sba...@denx.de]

> Gesendet: Mittwoch, 4. Oktober 2017 16:00

> An: Herbrechtsmeier Dr.-Ing. , Stefan; sba...@denx.de;
> swup...@googlegroups.com

> Betreff: Re: AW: AW: AW: AW: [swupdate] Reliable update of redundant

What is the advantage of a single release?

> > Thereby each boot loader image configuration is redundantly described
> inside two collections, each SWUpdate image configuration is
> redundantly described in two configurations and common images like root
> filesystem are redundantly described in all collections?
> >
> >>>> Maybe I am wrong, new speculation, you have Zync / Ultrascale...
> >>>
> >>> I have a Zync
> >>
> >> Ok, second speculation was correct :-)
> >>
> >>>>
> >>>> If you have updated, you should run the updated software, and not
> >> the
> >>>> old one, right ?
> >>>
> >>> This means the following procedure must be run inside the SWUpdate
> >> image. Is it possible to write some bytes inside a MTD device
> without
> >> first erasing a sector?
> >>
> >> Use the "rawfile" handler instead of "flash" handler. If you write
> >> zeroes, it works.
> >
> > The files are handled before the images. This means I have to
> manipulate the SPL inside the nor flash from a post script.
>
> This is correct, right. Up now, the order of the installation is not
> sured. Anyway, you are not the first raising this topic, and maybe this
> will be changed in future.

Okay

This means the script needs to detect the update by itself if I use the "install-if-different" attribute.

Best regards,

Stefan Herbrechtsmeier
Software Developer Embedded Systems

[Stefan.Herb...@weidmueller.com]

Hi Stefano,

Is it foreseen to combine "install-if-different" with a dual copy strategy?

Maybe via a "execute-if-different" attribute for the "scripts" and "bootenv" section entries?

Why not use a similar functionality to skip images in a multi copy strategy? A "running" copy column inside the sw-description and a new attribute with a space separated list of compatible copies. The image will be skipped if "install-if-different" is true and the copy of the sw-description is inside the compatible copies list. Or a "copy" and "install-if-running" attribute with the desired copy string inside the sw-description.

Best regards

Stefan Herbrechtsmeier
Software Developer Embedded Systems

[Stefano Babic]

Hi Stefan,

On 05/10/2017 10:19, Stefan.Herb...@weidmueller.com wrote:

>> Yes, you could do in this way - if I had to do, I have considered all
>> together, that is bootloader is part of the release and I still have
>> two configurations.
>
> Is it foreseen to combine "install-if-different" with a dual copy strategy?

Even if not yet foreseen, there is always place to add new
functionalities...

>
> Maybe via a "execute-if-different" attribute for the "scripts" and "bootenv" section entries?
>

Let's see. What I dislike is that you want to combine something across
artifacts. One statement from design is that artifacts are orthogonal,
that is the installation of an artifact does not depend on another artifact.

In your case, you want to combine a postinstall script with the
attribute (install-if-different) of another artifact.

Anyway, what you are trying to do is to change the result of
sw-description at runtime - have you checked if you can do it with an
embedded script, that runs when an artifact is parsed ? That has exactly
this goal.

I mean, you can add a "hook" to the entry regarding SPL / U-Boot. The
script has as parameter the whole image structure. The LUA script can
change parameters and they are stored back when the script returns.

> Why not use a similar functionality to skip images in a multi copy strategy? A "running" copy column inside the sw-description and a new attribute with a space separated list of compatible copies. The image will be skipped if "install-if-different" is true and the copy of the sw-description is inside the compatible copies list. Or a "copy" and "install-if-running" attribute with the desired copy string inside the sw-description.
>

[Stefan.Herb...@weidmueller.com]

Hi Stefano,

> -----Ursprüngliche Nachricht-----
> Von: Stefano Babic [mailto:sba...@denx.de]

> Gesendet: Donnerstag, 5. Oktober 2017 15:16

> An: Herbrechtsmeier Dr.-Ing. , Stefan; sba...@denx.de;
> swup...@googlegroups.com

> Betreff: Re: AW: AW: AW: AW: AW: [swupdate] Reliable update of
> redundant images
>

> On 05/10/2017 10:19, Stefan.Herb...@weidmueller.com wrote:
>
> >> Yes, you could do in this way - if I had to do, I have considered
> all
> >> together, that is bootloader is part of the release and I still have
> >> two configurations.
> >
> > Is it foreseen to combine "install-if-different" with a dual copy
> strategy?
>
> Even if not yet foreseen, there is always place to add new
> functionalities...
>
> >
> > Maybe via a "execute-if-different" attribute for the "scripts" and
> "bootenv" section entries?
> >
>
> Let's see. What I dislike is that you want to combine something across
> artifacts. One statement from design is that artifacts are orthogonal,
> that is the installation of an artifact does not depend on another
> artifact.
>
> In your case, you want to combine a postinstall script with the
> attribute (install-if-different) of another artifact.

No, I want to add support for the name, version and execute-if-different (install-if-different) attribute to the scripts and bootenv section. The artifacts only use the same information from the sw-versions but have its own configuration inside the sw-description. At the moment you couldn't control the scripts and bootenv execution.

> Anyway, what you are trying to do is to change the result of sw-
> description at runtime

No, I want to add the install-if-different functionality to the scripts and bootenv section. I want to add more constrains to the single artifacts inside the sw-description.

> - have you checked if you can do it with an
> embedded script, that runs when an artifact is parsed ? That has
> exactly this goal.
>
> I mean, you can add a "hook" to the entry regarding SPL / U-Boot. The
> script has as parameter the whole image structure. The LUA script can
> change parameters and they are stored back when the script returns.

Could the hook remove an image from the list or skip it? Is the hook available inside scripts and bootenv?

> > Why not use a similar functionality to skip images in a multi copy
> strategy? A "running" copy column inside the sw-description and a new
> attribute with a space separated list of compatible copies. The image
> will be skipped if "install-if-different" is true and the copy of the
> sw-description is inside the compatible copies list. Or a "copy" and
> "install-if-running" attribute with the desired copy string inside the
> sw-description.

I confound the sw-description and sw-versions. I want to add a new column to the sw-versions with could be checked by single artifacts inside the sw-description.

Best regards,

[Stefano Babic]

Hi Stefan,

On 05/10/2017 16:28, Stefan.Herb...@weidmueller.com wrote:

>> Let's see. What I dislike is that you want to combine something across
>> artifacts. One statement from design is that artifacts are orthogonal,
>> that is the installation of an artifact does not depend on another
>> artifact.
>>
>> In your case, you want to combine a postinstall script with the
>> attribute (install-if-different) of another artifact.
>
> No, I want to add support for the name, version and execute-if-different (install-if-different) attribute to the scripts and bootenv section. The artifacts only use the same information from the sw-versions but have its own configuration inside the sw-description. At the moment you couldn't control the scripts and bootenv execution.

Ok, I think I was confused by the misleading use of sw-description in
your last e-mail.

>
>> Anyway, what you are trying to do is to change the result of sw-
>> description at runtime
>
> No, I want to add the install-if-different functionality to the scripts and bootenv section. I want to add more constrains to the single artifacts inside the sw-description.
>
>> - have you checked if you can do it with an
>> embedded script, that runs when an artifact is parsed ? That has
>> exactly this goal.
>>
>> I mean, you can add a "hook" to the entry regarding SPL / U-Boot. The
>> script has as parameter the whole image structure. The LUA script can
>> change parameters and they are stored back when the script returns.
>
> Could the hook remove an image from the list or skip it? Is the hook available inside scripts and bootenv?

Not yet, but this feature can be added quite easy.

>
>>> Why not use a similar functionality to skip images in a multi copy
>> strategy? A "running" copy column inside the sw-description and a new
>> attribute with a space separated list of compatible copies. The image
>> will be skipped if "install-if-different" is true and the copy of the
>> sw-description is inside the compatible copies list. Or a "copy" and
>> "install-if-running" attribute with the desired copy string inside the
>> sw-description.
>
> I confound the sw-description and sw-versions.

Ok, that makes more sense.

> I want to add a new column to the sw-versions with could be checked by single artifacts inside the sw-description.

sw-versions is evaluated later (after the parsing) in the
check_if_required() function. I guess that such a new column can be
added if it does not introduce compatibility issues.

[Stefan.Herb...@weidmueller.com]

Hi Stefano,

at the moment I see four different solutions to handle multiple independent dual copies:

a) Add a single image and single bootenv entry to the sw-description per dual copy image. Use a hook script to set the device attribute of the image to the standby device and another hook script to set the value of the bootenv.
b) Add two images and two bootenv entries to the sw-description per dual copy image. Use two hook scripts to set a skip attribute of image and bootenv for the running devices.
c) Add two image and two bootenv entries to the sw-description per dual copy image. Use a new column inside the sw-version file and a new attribute with the desired running partition to skip one of the image and bootenv.
d) Add a single image and single bootenv entry to the sw-description per dual copy image. Use an array for the device and value attributes and a new column inside the sw-version file to select the correct element from the array.

Which solution would you recommend?

Does SWUpdate support more when one update without a reset? If I understand the behavior correct a repeated update of the same image without a reset could break the system if a power loss happens during the second run because the first update already activate the standby image.

Best regards