[yocto] Yocto-ish upgrade-in-place strategy

[Maxin John]

Hi

On Tue, May 5, 2015 at 6:55 AM, Craig McQueen
<craig.mcqueen at innerrange.com> wrote:
> I’m working on this for a BeagleBone Black type system, which uses eMMC
> (i.e. disk partitions). I’m considering:

<snip>

>
> The BeagleBone Black U-Boot implements an incrementing ‘bootcount’, stored
> in RTC scratch, I believe. A Linux kernel driver could be written which
> allows for this to be reset to 0 by the kernel or userspace app. Then,
> U-Boot could do some alternative action if bootcount gets too big (meaning
> it’s not successfully booting)—such as revert to the other older image, if
> present.

Here, one probable scenario could be user switching off the device
after firmware upgrade
instead of allowing the device to restart. The "bootcount" value may
not be preserved
in the scratch registers after poweroff. In that case, we can store
the "bootcount" value in the
persistent environment using "BOOTCOUNT_ENV" in u-boot. This could
avoid the trouble
of developing and integrating the kernel driver or userspace app for
resetting bootcount.
Instead, we can rely on the fw_(printenv/setenv) utility already
present in u-boot.

Best Regards,
Maxin