From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Lynch Jr. Date: Tue, 28 Dec 2010 13:45:22 -0500 Subject: [U-Boot] Updating a system In-Reply-To: <4D19A86B.9050300@free.fr> References: <1293522848.3652.647.camel@t-dhlii> <4D19A86B.9050300@free.fr> Message-ID: <1293561922.3652.1286.camel@t-dhlii> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Sorry; Your sugestions are appreciated. I had not yet looked at some of the u-boot capabilities you described. But I am trying to find out if there is something approaching a standard scheme for handling this - rather than going off and doing something myself that is non-standard. I have a fairly good grasp of what needs to and can be done if there is no common solution already. On Tue, 2010-12-28 at 10:05 +0100, Albert ARIBAUD wrote: > Hi David, > > Le 28/12/2010 08:54, David Lynch Jr. a ?crit : > > I need to setup a system so that it can boot a user web updateable > > kernel/rootfs or a failsafe version. The process has to be manageable by > > completely non-technical users and work from a single flash media - no > > plugging in an SD card or USB stick to recover. > > Before I re-invent the wheel is there an existing scheme to manage > > multiple boot choices with an automatic fallback to a failsafe ? > > Depends what you mean by "fail-safe". > > There is no way for a bootloader to detect "failures" in the OS and set > of applications that it helps launching, at least no general, > already-defined and 100%... fail-safe... way. You'll have to devise your > own scheme for the bootloader to find out it should start the backup > system instead of the main one. What U-boot can do for you here is > provide tools to build this method. > > One tool is support for OS and root Flash images which can be checked > for integrity (e.g. images made with make uImage). When told to run such > images, u-boot will check their integrity and run them only if > unaltered; otherwise it'll go on executing whatever instruction follows. > This allows you to at least not run a main system if corrupt; it even > allows you to not run a corrput backup system, however what you would do > next is you own lookout. > > Another tool is the ability to store and retrieve a flag value which > will persist across reboots and resets, both in u-boot and in linux, for > instance you'd use some bytes of eeprom or a scratch register on a > backed-up I2C RTC (mind the total power losses though!) > > As a (very bad and incomplete) example, initially the flag value would > be set to "PASS" and the main system would use a watchdog scheme which, > in case of "failures", would set the flag value to "FAIL" and reset. > Then in u-boot, commands executed from boootcmd would check the flag > value and boot either the main (if PASS) or backup (if FAIL) system. > > But as I said, these are only generic tools which can help making a > system fail-safe. > > Amicalement,