Hi On Tue, May 5, 2015 at 6:55 AM, Craig McQueen <craig.mcqu...@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 -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto