Joel, > On 10.09.2019, at 01:07, Simon Glass <s...@chromium.org> wrote: > > Hi Joel, > > On Sat, 7 Sep 2019 at 18:34, Joel Peshkin <joel.pesh...@broadcom.com> wrote: >> >> >> Hi Simon, >> >> I need to create and upstream driver for a set of functions that manage >> volatile information that persist across reboots. These are simple >> registers that survive reboot but get cleared on power-cycle. The key >> operations we need to implement are ... >> >> boot_state_set_alternate_image_once() >> Called before rebooting (from uboot proper or from Linux)... sets flags >> to cause the next reboot to select an alternate image >> >> boot_state_getandclear_alternate_image() >> Called during boot (during SPL or TPL if using dual-uboot images as we >> do). Gets the status of the alternate_image flag and clears it.
Could you elaborate how these are used? This sounds a lot like an A/B partition scheme, but I’d like to fully understand the use cases and what data is stored where before commenting in more detail. >> In our implementation, we have registers that always clear on power-cycle, >> but survive the soft reboot. Other implementations, where there is no such >> register, would still only use the alternate image once as long as the boot >> attempt reaches the getandclear_alternate_image() function, so drivers >> similar to those available in bootcount could easily handle the same >> function. >> >> Would you prefer that I create a new UCLASS or is it OK to extend the >> UCLASS_BOOTCOUNT operations and upstream the new operations, supported on a >> subset of the drivers that implement UCLASS_BOOTCOUNT ?? > > I think that adding new operations makes sense for now. > > I've added a few other people for thoughts. > > Regards, > Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
