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

["Jan Lübbe" <jlu@pengutronix.de>]

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