Re: [U-Boot] Should I create a new UCLASS for Bootstate or Add new Ops to UCLASS_BOOTCOUNT ??
Hi Joel,
On Sat, 7 Sep 2019 at 18:34, Joel Peshkin joel.peshkin@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.
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
Joel,
On 10.09.2019, at 01:07, Simon Glass sjg@chromium.org wrote:
Hi Joel,
On Sat, 7 Sep 2019 at 18:34, Joel Peshkin joel.peshkin@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
participants (2)
-
Philipp Tomsich -
Simon Glass