Patent Description:
A resilient and upgradable boot loader is an essential component of any embedded system including embedded systems with a level of reliability that it is referred to as a carrier grade embedded system. (see content on Internet at //en. org/wiki/Carrier_grade). The main function of a boot loader is to initialize and set system hardware to a proper and known state before running higher level software. In order to enable new system features and functionality, the boot loader must be also be upgradable. In a carrier-grade system, this upgrade process must be resilient and be able to recover from a corrupted boot loader caused by an event such as power loss during the update. Since the embedded system may be located remotely, it is important that the embedded system perform this update without the need for any other physical interaction. Different methods have been used in the prior art to provide a resilient and upgradable boot loader.

<CIT> relates to methods and apparatus for improving network boot efficiency. Boot images that are initially sent from a boot server to various clients are cached at network devices along communication paths between the boot server and the clients. In response to subsequent boot image requests from the clients, boot images cached at the network devices are downloaded directly from the network devices rather than from the boot server, reducing network traffic to and from the boot server and domains in between. In addition, boot program bootstrap files may also be cached and downloaded in a similar manner. Techniques are also disclosed for intercepting boot image download and network bootstrap program requests at the network devices, and for maintaining valid boot image cache configurations across the network. The network devices generally include switches, routers, bridges, and gateway servers.

<CIT> discloses systems and methods for failsafe firmware upgrades. Specifically, there is a vehicle telematics device, including: a processor; and a firmware memory comprising a firmware image coupled to the processor, wherein the firmware image further comprise a first segment and a second segment; wherein a primary bootloader application located in the firmware image: verifies the integrity of the first segment; verifies the integrity of the second segment; selects a firmware image contained in the firmware memory using a failsafe process; and boots the vehicle telematics device using the selected firmware image.

<FIG> shows a prior art approach that involves using three boot loader images within the system: a failsafe image <NUM>, a primary image <NUM>, and a secondary image <NUM>. These images are often stored apart from the memory <NUM> that contains the operating system files. The failsafe image <NUM> is non-upgradable (read-only) and thus cannot be corrupted. The failsafe image <NUM> always runs first at power-up and checks the integrity of the upgradable primary image <NUM>. If the primary image <NUM> is deemed to be good, then the failsafe image <NUM> executes the primary image <NUM>. Otherwise, the failsafe image <NUM> will attempt to verify and boot the secondary image <NUM>.

In order to limit the risk of impact to the bootup images, the process to upgrade the primary image <NUM> does not occur during the upgrade of the secondary image <NUM>. Thus, a power interruption during upgrade of the bootup images would only corrupt one of the two upgradable images (<NUM> or <NUM>). Since a power loss event can only corrupt either the primary image <NUM> or the secondary image <NUM> but not both, there will always be at least one good image to boot. After booting with the non-corrupted primary image <NUM> or secondary image <NUM>, higher level application software will update or fix the corrupt boot loader image.

The problem with the failsafe method is that the state of the system hardware will be a combination of configurations made by the read-only failsafe image <NUM> and one of the upgradable images, <NUM> or <NUM>. This is the result of the failsafe image <NUM> always running at power-up and then executing either the primary image <NUM> or the secondary image <NUM>.

The failsafe image <NUM> may contain unwanted or unknown system configurations (i.e. bugs <NUM>) that can cause problems as the system continues to boot and operate. These unwanted configurations are not limited to the CPU (or SoC - System on a Chip) <NUM> but also include interactions with system peripherals <NUM>. Since the failsafe image <NUM> is not upgradable, these bugs <NUM> cannot be removed. Alternatively, a failsafe image <NUM> that was error-free when placed into service may become problematic as the system including system peripherals evolve over time.

Here is an example of a system peripheral that may remain in a bad state without the use of a system power cycle: I2C (or SMBus) I/O expanders are popular embedded devices used to add additional GPIO resources to a system. The PCA9554 is an example of such a device.

Note that the PCA9554 device has no reset method other than removing power. A non-upgradable failsafe image <NUM> may incorrectly configure the PCA9554 device to hold another system peripheral in reset or incorrectly set a system status LED. Without a power cycle before booting the upgradable boot loader, the system may stay in this improper state. Thus a power cycle may be needed to clear improper states from some devices.

<FIG> shows another prior art upgrade method that has two stored boot loader images. For purposes of illustration, assume there are a first image in memory area <NUM> and a second image in memory area <NUM>. The system sets an active image <NUM> which is currently the second image in memory area <NUM>. There is also an inactive image <NUM> which is currently the first image in memory area <NUM>. The mapping of active image and inactive image to the first image in memory area <NUM> and the second image in memory area <NUM> is selectable using a nonvolatile hardware setting. When a new boot loader image update is required, the new image is loaded into the memory area containing the inactive image <NUM>. After loading the new image to become the updated inactive image <NUM>, the inactive image <NUM> is verified with a checksum.

Once the new boot loader image loaded into the inactive image <NUM> has been verified, a nonvolatile hardware setting (i.e. reset vector table or boot bus address space) is made to swap the new inactive image <NUM> to become the new active image <NUM>. The system will then reset itself and boot the new active image <NUM>.

Without the ability to power cycle itself after updating one image and making that updated image the active image <NUM>, the system will suffer a similar problem described with the failsafe boot loader. In this case, the system state will be a combination of configurations made by the newly active and newly inactive images. Only a power cycle reset after updating the boot loader can put the system back to a truly known state.

Unless explicit to the contrary, the word "or" should be interpreted as an inclusive or rather than an exclusive or. Thus, the default meaning of or should be the same as the more awkward and/or.

Unless explicit to the contrary, the word "set" should be interpreted as a group of one or more items.

This summary is meant to provide an introduction to the concepts that are disclosed within the specification without being an exhaustive list of the many teachings and variations upon those teachings that are provided in the extended discussion within this disclosure. Thus, the contents of this summary should not be used to limit the scope of the claims that follow.

Inventive concepts are illustrated in a series of examples, some examples showing more than one inventive concept. Individual inventive concepts can be implemented without implementing all details provided in a particular example. It is not necessary to provide examples of every possible combination of the inventive concepts provide below as one of skill in the art will recognize that inventive concepts illustrated in various examples can be combined together in order to address a specific application.

Other systems, methods, features and advantages of the disclosed teachings will be immediately apparent or will become apparent to one with skill in the art upon examination of the following figures and detailed description. The claimed invention is defined by the appended independent claim. The dependent claims define preferred embodiments.

The disclosure can be better understood with reference to the following figures. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the disclosure.

The presently disclosed subject matter is described with specificity to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or elements similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the term "step" may be used herein to connote different aspects of methods employed, the term should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described.

<FIG> illustrates a simplified view of an embedded system <NUM> with a failsafe boot loader. The embedded system <NUM> includes a nonvolatile boot source setting <NUM> and a power supply reset <NUM>.

The boot source setting <NUM> within the nonvolatile storage device <NUM> controls which boot source image the nonvolatile storage device <NUM> provides to the CPU/SoC <NUM> when requested at power-up. The boot source setting <NUM> is controllable by the CPU/SoC <NUM> and is persistent through power cycles. The boot source setting <NUM> may be set to one of three different images: failsafe image <NUM>, primary image <NUM>, or secondary image <NUM>.

The system power reset <NUM> allows the CPU/SoC <NUM> to momentary toggle power provided by the system power unit <NUM> to the entire system <NUM>, including at least some and ideally all system peripherals <NUM>.

<FIG> shows a process <NUM> for the failsafe boot flow.

Branch <NUM>. The failsafe image <NUM> checks to ensure that primary image <NUM> is good (not corrupted). If primary image <NUM> is good then proceed to Step <NUM>, else proceed to branch <NUM> discussed below.

Step <NUM>. Set boot source setting <NUM> within the nonvolatile storage device <NUM> to be the primary image <NUM>.

Step <NUM> Power cycle the system <NUM> by having the CPU/SoC <NUM> activate the system power reset <NUM> to momentary toggle power provided by the system power unit <NUM> to the entire system <NUM>, including system peripherals <NUM>. Note as some devices require a power interruption of more than an instant in order to cycle, the power cycle duration may be set to be of sufficient duration to effectively power cycle all components on the system. Note that this step is completed automatically, that is without requiring a human to act to turn off the power to create a power cycle event.

Step <NUM> After the power cycle, boot the primary image <NUM> as the boot source setting <NUM> points to the primary image <NUM>.

Step <NUM> Then set the boot source setting <NUM> to point to the failsafe image <NUM> for use after the next power-up <NUM>.

After the boot loader has completed its validation process and executed required system initialization and configuration, it will transfer execution to an operating system or other runtime load that executes the system application. Those of skill in the art will recognize that the system application may exist as processes running within an operating system (OS) that is separate from the boot loader image. In this case, the bootloader will first start the OS by loading a kernel image from a non-volatile file system into system RAM. The boot loader will then execute the OS kernel in RAM which will in turn start the system application. Thus, the upgradable boot loader transfers execution to an operating system or other runtime load.

The system application may also exist as addition functionality within the boot loader image itself. In this case, the application is started by simply continuing execution within the boot loader image. Thus, the upgradable boot loader is itself a complete runtime.

Step <NUM> Upon next reboot, return to step <NUM> and boot failsafe image <NUM> as the boot source setting <NUM> within the nonvolatile storage device <NUM> was set to point to the failsafe image <NUM>. Those of skill in the art will recognize that a system reboot may be triggered by software and that is the path of <NUM> to <NUM>. A reboot after an interval without power would reenter the process <NUM> as described above.

Those of skill in the art know that it is common for an embedded system to employ a "watchdog" to detect and recover from malfunctions. A watchdog operates by resetting the system if its timer is not cleared within a defined amount of time. Typically, a watchdog will initiate a processor reset in an attempt to recover a system. However, simply issuing a processor reset may not clear the root cause of why the watchdog triggered. With the addition of a power cycle in the boot process, the system has a better chance of recovering from the reason why the watchdog triggered.

Branch <NUM>. The failsafe image <NUM> checks to ensure that secondary image <NUM> is good (not corrupted). If secondary image <NUM> is good, then proceed to Step <NUM>, else proceed to step <NUM>, declare hardware failure and initiate diagnostics under control of the failsafe image <NUM>. The diagnostics may start automatically or be available as an option to a technician but the diagnostic routines would be within the failsafe image <NUM>. Alternatively, the failsafe image <NUM> may be used manually boot operating system for use in further diagnostics.

Step <NUM>. Set boot source setting <NUM> within the nonvolatile storage device <NUM> to be the secondary image <NUM>.

Step <NUM> Power cycle the system <NUM> by having the CPU/SoC <NUM> activate the system power reset <NUM> to momentary toggle power provided by the system power unit <NUM> to the entire system <NUM>, including system peripherals <NUM>.

Step <NUM> After the power cycle, boot the secondary image <NUM> as the boot source setting <NUM> points to the secondary image <NUM>.

Step <NUM> Start System Application. As noted above, after the boot loader has completed its validation process and executed required system initialization and configuration, it will transfer execution to an operating system or other runtime load that executes the system application. The system application may exist as processes running within an operating system (OS) that is separate from the boot loader image. The system application may also exist as addition functionality within the boot loader image itself.

Any system configurations made by the failsafe image <NUM> are undone by the power cycle <NUM> or <NUM> and the system <NUM> is booted from a non-corrupt boot source image (either primary image <NUM> or secondary image <NUM>). Before the step <NUM> of starting the system application, the boot loader using either the primary image <NUM> or the secondary image <NUM> will set the boot source setting <NUM> to point to the failsafe image <NUM> so that the failsafe <NUM> is booted should there be a reboot or power-up.

This makes the embedded system <NUM> have a reliable starting boot source image as the failsafe image <NUM>. The failsafe image <NUM> although limited in functionality is read-only and not subject to corruption. Corruption of the primary image <NUM> or the secondary image <NUM> which might come if a power interruption occurred during an update of primary image <NUM> or the secondary image <NUM> will not be a problem as a power interruption will only corrupt one of the two images and will trigger a reboot and the failsafe image <NUM> will discern which of the two images <NUM> or <NUM> to use for a full reboot.

<FIG> illustrates a simplified view of an embedded system <NUM> with an active/inactive boot loader.

The active/inactive boot loader includes the system power reset <NUM> and a non-volatile boot source setting <NUM> analogous to the boot source setting <NUM> in embedded system <NUM>. A difference between embedded system <NUM> and embedded system <NUM> is that embedded system <NUM> has just two boot loader images rather than three. There is a first image <NUM> in a first memory location and a second image <NUM> in a second memory location. One of the two images (<NUM>, <NUM>) is deemed to be the active image <NUM> and one is deemed to be the inactive image <NUM>. The mapping of the active image <NUM> and inactive image <NUM> to the first image <NUM> and the second image <NUM> is stored in the boot source setting <NUM>.

<FIG> shows process <NUM> for booting embedded system <NUM>.

Step <NUM> Look to the boot source setting <NUM> to know which of the two images (first image <NUM> and second image <NUM>) is the current active image <NUM>. Assume that is initially second image <NUM>. Boot the active image <NUM> found at second image <NUM>.

Step <NUM> After the active image <NUM> is booted, start system application. After the boot loader has completed its validation process and executed required system initialization and configuration, it will transfer execution to a runtime load that provides the system application. Those of skill in the art will recognize that the application may exist as processes running within an operating system (OS) that is separate from the boot loader image. In this case, the bootloader will first start the OS by loading a kernel image from a non-volatile file system into system RAM. The boot loader will then execute the OS kernel in RAM which will in turn start the system application. Thus, the upgradable boot loader transfers execution to a runtime load.

The application may also exist as addition functionality within the boot loader image itself. In this case, the application is started by simply continuing execution within the boot loader image. Thus, the upgradable boot loader is itself a complete runtime.

Branch <NUM>. Check if there is a new boot loader. If yes, then go to step <NUM>. If no, go to step <NUM>.

Step <NUM> No changes made to the mapping of active image <NUM> to first image <NUM> and second image <NUM>. The next reboot will use the same active image <NUM> as last used.

Step <NUM>. Copy the new boot loader image into the inactive image <NUM>. In this example that was initially first image <NUM>.

Branch <NUM>. Check that new boot loader image loaded into the inactive image <NUM> is good (not corrupted). This may be done through checksum or other methods known to those of skill in the art. If good, then proceed to step <NUM>. Else proceed to step <NUM> and assert a boot loader update failure alarm and/or system error log. At the next reboot, the process will be unchanged and the same active image <NUM> will be used and there will be another attempt to update the inactive image <NUM>.

Step <NUM>. Now that a new boot loader image has been stored and verified, swap the boot source setting <NUM> for the active image <NUM> to the location with the new boot loader image. In this example, the boot source setting <NUM> initially mapped the active image <NUM> to the second image <NUM>. Now the boot source setting <NUM> will be set to map the active image <NUM> to the first image <NUM>.

Step <NUM>. Power cycle the system <NUM> by having the CPU/SoC <NUM> activate the system power reset <NUM> to momentary toggle power provided by the system power unit <NUM> to the entire system <NUM>, including system peripherals <NUM>.

Step <NUM>. The power cycle causes the process <NUM> to restart but this time the active image <NUM> will be mapped to the first image <NUM> containing the newly downloaded boot loader image.

The process set forth above can be summarized as follows. On initial power-up, the selected active boot loader is run and boots the operation system. The boot loader is updated by writing the new boot loader image to the inactive image location and verified using a checksum and/or version and/or date. If validated, the boot selector is set to make the newly updated boot image active and the system is power cycled. If validation fails, a failure indication is set and the boot loader selection remains with the current boot image.

Several different methods can be used to implement the nonvolatile boot source setting (<NUM> or <NUM>). eMMC flash devices provide distinct hardware partitions and a register to control which partition is used to offer the boot image when requested by the connected CPU. Systems using discrete flash devices on a parallel bus can use external nonvolatile logic to manipulate address lines to select different regions of flash memory. Some processor archite
ctures use a programmable reset vector table that can be used to select different regions of nonvolatile memory. Those of skill in the art can substitute other non-volatile memory options to store the nonvolatile boot source setting.

Resetting power to a system can be implemented various different ways. Power supplies often provide a control input to enable/disable power output. For example, DC-DC converter modules from Vicor provide a "Primary Control" pin that can be used to momentarily disable power output. The method used to fully power cycle the system is not limited to an onboard power subsystem; a full system power cycle can also be initiated by sending a message to an external networked power controller device.

A common method used to verify that a boot loader image is not corrupt and is safe to boot is to provide a small block of data at the beginning of the image. This block of "header" data can provide information such as image size, version, release date, and a checksum or CRC. Using this information, an image can be verified by comparing the calculated checksum/CRC of the image (excluding the header) to the value provided in the header. Those of skill in the art will appreciate that many other ways are known to check the completeness and lack of corruption in a download (such as CRC32, MD5, and other methods) and one of skill in the art can substitute one of these tests for a checksum or analogous test.

In the failsafe boot method previously described, the primary and secondary boot loader images are the same. By default, the primary image has the higher selection priority and the secondary is booted only if the primary image is corrupt. An alternative to this is to provide a nonvolatile setting to specify which upgradable image has the higher boot selection priority. In this case, the primary and secondary images may not be the same; one may be the latest version and the other may be the previous version. During the boot loader update process, only one image is updated and is set as the higher priority image.

One of skill in the art will recognize that some of the alternative implementations set forth above are not universally mutually exclusive and that in some cases additional implementations can be created that employ aspects of two or more of the variations described above. Likewise, the present disclosure is not limited to the specific examples or particular embodiments provided to promote understanding of the various teachings of the present disclosure. Moreover, the scope of the claims which follow covers the range of variations, modifications, and substitutes for the components described herein as would be known to those of skill in the art.

Claim 1:
A process for using a boot loader to load a set of boot commands from one of two boot images accessible to a device (<NUM>) before loading a system application; the process comprising:
assigning one memory location selected from a first memory location and a second memory location to become a current active memory location in accordance with a boot source setting value (<NUM>); and
assigning another memory location selected from the first memory location and the second memory location but not the one memory location as a current inactive memory location;
wherein the first memory location, the second memory location, and the boot source setting value are all in non-volatile memory (<NUM>) accessible by the boot loader;
providing power to a device with the boot loader and providing power to at least one peripheral device (<NUM>) in communication with the device;
booting the device with an upgradable boot image (<NUM>) found in the current active memory location as indicated in the boot source setting value, before loading a system application for the device;
if a new upgradable boot image exists, then load the new upgradable boot image to the current inactive memory location;
if a check of the new upgradable boot image in the current inactive memory location indicates a failure to load properly, then a next reboot of the device will continue to use the current active memory location; and
if a check of the new upgradable boot image in the current inactive memory location indicates a valid boot image was loaded into the current inactive memory location, then
<NUM>) change the boot source setting value to make the current inactive memory location into a new active memory location and make the current active memory location into a new inactive memory location; before
<NUM>) applying a power cycle to the device and the at least one peripheral device in communication with the device so that successful loading of the new upgradable boot image causes booting of the device with the new upgradable boot image found in the new active memory location.