[U-Boot] anyone implemented a failsafe upgrade involving two kernel/rootfs pairs?
i want to do pretty much what's described here:
https://github.com/DFE/HidaV/wiki/Safe-Update-and-boot-fallbacks
that is, a single u-boot and config in flash, followed by a pair of kernel/rootfs partitions, that is remotely upgradeable by, from userspace, determining the "older" (backup) of the pairs, overwriting that pair with a new pair, then flipping the switch in the u-boot configuration to always boot the newer kernel and rootfs (with an emergency revert to the backup pair under circumstances i haven't imagined yet).
it *looks* fairly straightforward, but while that's a nice write-up, it does warn right up front that it hasn't been implemented so if anyone has done something like this they care to share, that would be delightful.
FYI, i'm using this pdlogic zoom am1808 experimenter kit:
http://www.logicpd.com/products/system-on-modules/zoom-am1808/
for testing and, at the very end, the only change i would have to make is modify the solution to handle NOR flash that will be on the production board.
if there's a writeup on this out there somewhere, that would be great. if not, if i can get this done, i'll be happy to write it up and post it publicly on my wiki for others.
at the moment, i'm using openembedded to build a bootable kernel/rootfs pair for this board, and starting by adding the u-boot-fw-utils package so i have fw_{printenv/setenv} onboard. thanks for any pointers.
rday
p.s. i do have the bootable SD card that came with the kit, it's based on the arago project so i know i have something that boots to userspace as a starting point -- always good to know.
Dear Robert,
In message alpine.DEB.2.02.1301310731270.7034@oneiric you wrote:
that is, a single u-boot and config in flash, followed by a pair of kernel/rootfs partitions, that is remotely upgradeable by, from userspace, determining the "older" (backup) of the pairs, overwriting that pair with a new pair, then flipping the switch in the u-boot configuration to always boot the newer kernel and rootfs (with an emergency revert to the backup pair under circumstances i haven't imagined yet).
The emergency revert usually relies on two things:
- Watchdog support that will reset (reboot) the system reliably in case the Linux kernel does not boot or does not manage to start the user space control application that will trigger the watchdog.
- The "boot counter" feature that will allow to run an alternativce boot command (i. e. booting from the backup) in case the number of boot attempts exceeds the set limit.
it *looks* fairly straightforward, but while that's a nice write-up, it does warn right up front that it hasn't been implemented so if anyone has done something like this they care to share, that would be delightful.
Things like that have been done a number of times before; the fact that such features as watchdog support and boot counter were added to U-Boot are an indication for this. However, in the cases known to me, the actual implementation was done as shell scripts (i. e. environment settings) which were not published.
Best regards,
Wolfgang Denk
On Thu, 31 Jan 2013, Wolfgang Denk wrote:
Dear Robert,
In message alpine.DEB.2.02.1301310731270.7034@oneiric you wrote:
that is, a single u-boot and config in flash, followed by a pair of kernel/rootfs partitions, that is remotely upgradeable by, from userspace, determining the "older" (backup) of the pairs, overwriting that pair with a new pair, then flipping the switch in the u-boot configuration to always boot the newer kernel and rootfs (with an emergency revert to the backup pair under circumstances i haven't imagined yet).
The emergency revert usually relies on two things:
Watchdog support that will reset (reboot) the system reliably in case the Linux kernel does not boot or does not manage to start the user space control application that will trigger the watchdog.
The "boot counter" feature that will allow to run an alternativce boot command (i. e. booting from the backup) in case the number of boot attempts exceeds the set limit.
it *looks* fairly straightforward, but while that's a nice write-up, it does warn right up front that it hasn't been implemented so if anyone has done something like this they care to share, that would be delightful.
Things like that have been done a number of times before; the fact that such features as watchdog support and boot counter were added to U-Boot are an indication for this. However, in the cases known to me, the actual implementation was done as shell scripts (i. e. environment settings) which were not published.
ok, i'm going to clear my schedule for the day and just read the u-boot manual cover to cover finally -- it will probably resolve a lot of my questions. if it's all right, i might update some of the manual wiki pages, like this one that corresponds to the patch i just submitted:
http://www.denx.de/wiki/view/DULG/HowCanIAccessUBootEnvironmentVariablesInLi...
where that comment should read:
# Configuration file for fw_(printenv/setenv) utility.
if it's anything more than just a trivial fix, i'll ask first.
rday
p.s. just edited that page, hope i did it correctly. onward ...
Dear Robert,
In message alpine.DEB.2.02.1301310921310.9010@oneiric you wrote:
ok, i'm going to clear my schedule for the day and just read the u-boot manual cover to cover finally -- it will probably resolve a lot
Don't hold your breath that it will cover all topics. There are way too many cases where customers are not willing to also pay for public documentation of the stuff they asked for; we're already happy that almost all code goes into mainline.
of my questions. if it's all right, i might update some of the manual wiki pages, like this one that corresponds to the patch i just submitted:
All such reductional work is highly welcome.
p.s. just edited that page, hope i did it correctly. onward ...
Looks fine, thanks.
Best regards,
Wolfgang Denk
participants (2)
-
Robert P. J. Day -
Wolfgang Denk