[RAUC] boot-mbr-switch from u-boot

[RAUC] boot-mbr-switch from u-boot

[Martin Hollingsworth]

[-- Attachment #1.1: Type: text/plain, Size: 1003 bytes --]

Hello RAUC community,

I am integrating RAUC into a Xilinx ZynqMP device and using boot-mbr-switch method according to documentation chapter 7.6.2. Bootloader is u-boot, RAUC u-boot scripts are from contrib/uboot.sh, RAUC is v1.2 (upgrade planned).



When switching between slots from within u-boot the MBR partition table is not altered. So when installing a new system (inclduing new bootloader partition content) which doesn't boot 3 times, after the fallback we run the new bootloader partition with the old rootfs. Do I understand this from the source code correctly?



In my opinion this is a major problem, because on Xilinx ZynqMP the bootloader partition contains the Xilinx bootbin, a first stage bootloader which flashes the FPGA firmware before starting u-boot. In this case we run the old linux against a new FPGA and have an inconsistent system after the RAUC fallback.



Does anyone have a solution for this problem?



Thanks and regards,

Martin Hollingsworth


[-- Attachment #1.2: Type: text/html, Size: 3121 bytes --]

[-- Attachment #2: Type: text/plain, Size: 66 bytes --]

_______________________________________________
RAUC mailing list

Re: [RAUC] boot-mbr-switch from u-boot

[Michael Tretter]

Hello Martin,

On Thu, 26 Nov 2020 08:57:49 +0000, Martin Hollingsworth wrote:
> I am integrating RAUC into a Xilinx ZynqMP device and using boot-mbr-switch
> method according to documentation chapter 7.6.2. Bootloader is u-boot, RAUC
> u-boot scripts are from contrib/uboot.sh, RAUC is v1.2 (upgrade planned).
> 
> When switching between slots from within u-boot the MBR partition table is
> not altered. So when installing a new system (inclduing new bootloader
> partition content) which doesn't boot 3 times, after the fallback we run the
> new bootloader partition with the old rootfs. Do I understand this from the
> source code correctly?

Correct.

> 
> In my opinion this is a major problem, because on Xilinx ZynqMP the
> bootloader partition contains the Xilinx bootbin, a first stage bootloader
> which flashes the FPGA firmware before starting u-boot. In this case we run
> the old linux against a new FPGA and have an inconsistent system after the
> RAUC fallback.

How do you tell Linux, what is contained in the FPGA firmware? Linux should
not make any assumptions about the loaded FPGA firmware.

> 
> Does anyone have a solution for this problem?

There are a few solutions:

You could use a different mechanism to load the firmware. Instead of the
boot.bin, put the bitstream into the rootfs (or another partition) and load it
from the bootloader (I'm not sure, if U-Boot supports this, but Barebox does.)
or from Linux.

If it is mandatory to load the firmware from the FSBL (or the bootloader
partition in general), you would need a means to tell Linux, which firmware
was loaded. That information has to be stored in the updated bootloader
partition.

Michael

_______________________________________________
RAUC mailing list

Re: [RAUC] boot-mbr-switch from u-boot

[Martin Hollingsworth]

Hello Michael,
thanks for the quick response.

>How do you tell Linux, what is contained in the FPGA firmware? Linux should
>not make any assumptions about the loaded FPGA firmware.

Through dtb entries the FPGA IP cores are registered as hardware, the kernel loads the appropriate drivers. On Xilinx ZynqMP platform using the Xilinx default boot procedure the dtb is part of the Xilinx bootbin file (the FSBL file on boot partition). The fsbl loads the dtb into memory because u-boot is dtb aware (since ~Xilinx v2020.1). The Kernel Image is default also part of the boot partition, but maybe this could be moved to the rootFS partition.

>> Does anyone have a solution for this problem?
>
>There are a few solutions:
>
>You could use a different mechanism to load the firmware. Instead of the
>boot.bin, put the bitstream into the rootfs (or another partition) and load it
>from the bootloader (I'm not sure, if U-Boot supports this, but Barebox does.)
>or from Linux.
>
>If it is mandatory to load the firmware from the FSBL (or the bootloader
>partition in general), you would need a means to tell Linux, which firmware
>was loaded. That information has to be stored in the updated bootloader
>partition.

The second is the case for my platform.

Assuming the old Linux system can boot with the updated boot partition and the userspace can detect the firmware mismatch: can RAUC manually switch the boot partition via MBR without switching the rootFS slot? Currently I would say no, because bootloader and rootFS slots are grouped together.
Assuming the old Linux system cannot boot, we have just bricked the Linux system via the Slot switch. Hence we loose the RAUC "fallback to last installed system" feature whenever u-boot does the slot switch (instead of rauc-mark-bad).

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?).

Cheers, Martin

_______________________________________________
RAUC mailing list

Re: [RAUC] boot-mbr-switch from u-boot

[Jan Lübbe]

On Thu, 2020-11-26 at 12:18 +0000, Martin Hollingsworth wrote:
> Hello Michael,
> thanks for the quick response.
> 
> > How do you tell Linux, what is contained in the FPGA firmware? Linux should
> > not make any assumptions about the loaded FPGA firmware.
> 
> Through dtb entries the FPGA IP cores are registered as hardware, the
> kernel loads the appropriate drivers. On Xilinx ZynqMP platform using
> the Xilinx default boot procedure the dtb is part of the Xilinx
> bootbin file (the FSBL file on boot partition). The fsbl loads the
> dtb into memory because u-boot is dtb aware (since ~Xilinx v2020.1).
> The Kernel Image is default also part of the boot partition, but
> maybe this could be moved to the rootFS partition.

Usually I'd put the kernel into the RootFS, as it also needs to match
any kernel modules (which are usually in the RootFS).

> > > Does anyone have a solution for this problem?
> > 
> > There are a few solutions:
> > 
> > You could use a different mechanism to load the firmware. Instead of the
> > boot.bin, put the bitstream into the rootfs (or another partition) and load it
> > from the bootloader (I'm not sure, if U-Boot supports this, but Barebox does.)
> > or from Linux.
> > 
> > If it is mandatory to load the firmware from the FSBL (or the bootloader
> > partition in general), you would need a means to tell Linux, which firmware
> > was loaded. That information has to be stored in the updated bootloader
> > partition.
> 
> The second is the case for my platform.
> 
> Assuming the old Linux system can boot with the updated boot
> partition and the userspace can detect the firmware mismatch: can
> RAUC manually switch the boot partition via MBR without switching the
> rootFS slot? Currently I would say no, because bootloader and rootFS
> slots are grouped together.
> Assuming the old Linux system cannot boot, we have just bricked the
> Linux system via the Slot switch. Hence we loose the RAUC "fallback
> to last installed system" feature whenever u-boot does the slot
> switch (instead of rauc-mark-bad).

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.

> 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.

Regards,
Jan




_______________________________________________
RAUC mailing list

Re: [RAUC] boot-mbr-switch from u-boot

[Martin Hollingsworth]

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