Method of updating single image microcode device, to lock out user initiated and programmatic reset functions
Publication Date: 2010-Aug-27
The IP.com Prior Art Database
Most embedded computer systems today deploy a two image design. This means that when the embedded system is running from one of the images, the other image can be updated, and when update is complete and successful, then the system is moved to the newly updated image and then the previous image location can be used for additional updates. However, in some embedded system, due to limitations of space, design considerations, etc, only one image location is available for running from and updating. This can be problematic when a new update is required as if something goes wrong with the image update process, it may leave the image in a state were it cannot be used by the embedded system. Also, most embedded systems, have watchdog timers or reset functions that monitor system health or user initiated reset methods to allow the system to be reset. In a single image system, if one of these triggers occur during the image update, this will result in the single image possibly becoming corrupted and unusable.
Method of updating single image microcode device , to lock out user initiated and programmatic reset functions
During the rc.init processing, a new init process script will be executed. This script will occur before other processes are started, such as networking. The script will perform the following functions;
• Get unique signature of the uBOOT image that is currently installed into the /dev/mtd7
• Get unique signature of the uBOOT image that is available on the currently booting filesystem image
• If there is a difference in these two images, then the controller will perform the following actions:
o Inform the BMC that a uBOOT update is beginning. The BMC will use this new
message to enter a special operational mode. The BMC shall hold off any power off requests and any reset requests to the controller. The BMC shall only acknowledge receipt of commands sent by the controller to the BMC, and shall not initiate any commands.
NOTE: If a power off request occurs during this time, the SAS switch may be
f, however the RFCI will remain powered on and the AMM will NOT
be informed that the power off request has been completed until the uBOOT update is successful.
o Start a thread which will heartbeat the BMC to inform the BMC that the RAID
controller is functional; this heartbeats shall occur at least once a minute.
o Send a message to the PPC FPGA, that no resets are allowed from any source.
NOTE: The above steps must occur; otherwise if a reset or p...