mail archive of the rauc mailing list
 help / color / mirror / Atom feed
From: Martin Hollingsworth <Martin.Hollingsworth@itk-engineering.de>
To: "Jan Lübbe" <jlu@pengutronix.de>,
	"Michael Tretter" <m.tretter@pengutronix.de>
Cc: "rauc@pengutronix.de" <rauc@pengutronix.de>
Subject: Re: [RAUC] boot-mbr-switch from u-boot
Date: Fri, 27 Nov 2020 15:21:34 +0000	[thread overview]
Message-ID: <3145f91d748f4c92bcb5be049ab84ddb@itk-engineering.de> (raw)
In-Reply-To: <cd8ffdc2b3044ff1dc9b4a75e21c4fa6571e7eaf.camel@pengutronix.de>

Hello Jan,

> -----Ursprüngliche Nachricht-----
> Von: Jan Lübbe <jlu@pengutronix.de>
> Gesendet: Donnerstag, 26. November 2020 15:00
>
> Usually I'd put the kernel into the RootFS, as it also needs to match
> any kernel modules (which are usually in the RootFS).

Thanks for the recommondation.

> In RAUC's model, the boot-* slot types are not redundant. So they
> support only *atomic* updates, but no *fallback*.
>
> The idea behind this is that you need to have the decision mechanism
> somewhere (usually in the bootloader), which cannot be part of the
> fallback capable components itself. So the best you can do is atomic
> updates. This is what the boot-* slots implement.
>
> It follows from this model that anything that's must be version-matched
> to the rootfs needs to be loaded *after* the decision point from the
> active side.

Thanks for the clarification!

> > In addition I could see the following solution:
> >
> > Implement boot-mbr-switch inside u-boot whenever BOOT_ORDER  must be
> > rearranged. My first guess would be to add this to the RAUC boot
> > script by manipulating the boot partition table (boot partition start
> > offset?).
>
> And then you'd reset to start the bootloader again, to switch to the
> old one? Not that boot-mbr-switch selects the lower/upper area from the
> region completely independently from the A/B boot order (as it's only
> intended for atomic updates).
>
> The clean boot flow (from RAUCs perspective) would be to anything
> that's loaded and relevant to Linux after the decision point. And the
> boot-mbr-switch wouldn't be involved in "normal" system updates.
>
> If that's not feasible in your case, the least fragile approach I can
> think of is to have a copy of the bootloader/-partition in the rootfs.
> Then remember the source of the most recently copied contents to the
> real boot partitions in the env. If the bootloader then detects that B
> should be booted but the A bootloader was last copied, perform the
> copy, change the offset, remember B as the new source in the env and
> reset. All of that would be invisible to RAUC, tough.

So basically you suggest to implement mbr.c from RAUC into u-boot with a few differences.

The more trivial (and less robust) idea of mine would have relied on the old bootloader partition being still available on the storage device. Calculating the old partition should be easy with region-start and region-size configs at hand.

Thank you everybody who has contributed to the discussion. For the moment I am unsure which way I will go from here and for now focus on finishing RAUC integration on Xilinx ZynqMP.

Have a nice weekend and regards,
Martin Hollingsworth
_______________________________________________
RAUC mailing list

      reply	other threads:[~2020-11-27 15:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-26  8:57 Martin Hollingsworth
2020-11-26 11:20 ` Michael Tretter
2020-11-26 12:18   ` Martin Hollingsworth
2020-11-26 14:00     ` Jan Lübbe
2020-11-27 15:21       ` Martin Hollingsworth [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3145f91d748f4c92bcb5be049ab84ddb@itk-engineering.de \
    --to=martin.hollingsworth@itk-engineering.de \
    --cc=jlu@pengutronix.de \
    --cc=m.tretter@pengutronix.de \
    --cc=rauc@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox