[U-Boot] Should I create a new UCLASS for Bootstate or Add new Ops to UCLASS_BOOTCOUNT ??

[Philipp Tomsich]

Joel,

> On 10.09.2019, at 01:07, Simon Glass <sjg at chromium.org> wrote:
> 
> Hi Joel,
> 
> On Sat, 7 Sep 2019 at 18:34, Joel Peshkin <joel.peshkin at 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