Hello Jan, > -----Ursprüngliche Nachricht----- > Von: Jan Lübbe <j...@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
