Browse Prior Art Database

Method of updating single image microcode device, to lock out user initiated and programmatic reset functions

IP.com Disclosure Number: IPCOM000199278D
Publication Date: 2010-Aug-27
Document File: 1 page(s) / 25K

Publishing Venue

The IP.com Prior Art Database

Abstract

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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 67% of the total text.

Page 1 of 1

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

partition

• 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...