Updating the system management information of a computer system

A method, system, apparatus, and computer-readable medium for updating the management information of a computer system are provided. According to one method, a system management information table is built during the execution of the computer system. The system management information table is built from a base set of management information and one or more updates to the base set of management information. The updates to the base set of management information may be stored a protected region of a non-volatile memory device. A utility program is provided for storing the updates to the management information in the non-volatile memory device.

BACKGROUND

Computing systems often utilize firmware that is stored in a non-volatile memory device, such as a read-only memory (“ROM”) device or a non-volatile random access memory (“NVRAM”) device. The firmware provides program code for performing power-on self tests, booting, and for providing support to the operating system and other functions. When computer systems are designed, there are many different combinations of hardware devices that may be present in the computer system or on a computer system motherboard. To support such a wide variety of hardware combinations, the motherboard manufacturers often provide original equipment manufacturers (“OEMs”) with a reference board and corresponding firmware image that represents the most common motherboard chipset configuration.

The reference board provides an OEM with a proof of concept that the OEM will then customize according to their requirements. The OEM may add, remove, or interchange hardware components to and from the reference board according to desired hardware configurations. As various hardware components are added or removed from a computer system motherboard, the firmware image must be updated to reflect the configuration change in order for the modified chipset configuration to properly function. The OEM must then request a firmware image that corresponds to the specific components of the customized motherboard. The customized firmware image is created and provided to the OEM for flashing into a memory device and distribution with the OEM's customized motherboard.

The firmware customization process often includes the modification of management data that is contained within the firmware for the customized system board. In particular, computing systems often utilize a firmware that is compatible with the system management basic input/output system (“SMBIOS”) specification. The SMBIOS specification addresses how motherboard and system vendors present management information about their products in a standard format. The information is intended to allow generic instrumentation to deliver this information to management applications, thereby eliminating the need for error prone operations like probing system hardware for presence detection.

In order to provide the correct management information for the customized board, management data contained within the firmware must be modified. This is typically not a process that is performed by the OEM. As a result, the firmware manufacturer must customize the SMBIOS data contained in the firmware for the OEM. This process consumes time and resources as the firmware image is created by a manufacturer, delivered to an OEM, returned to the manufacturer for customization, and so on.

It is with respect to these considerations and others that the various embodiments described below have been made.

SUMMARY

In accordance with the embodiments and implementations described herein, a method, system, apparatus, and computer-readable medium for updating the system management information of a computer system at runtime are provided. Through the embodiments described herein, an OEM can update the management information contained in a firmware without the assistance of the firmware manufacturer. The updates provided by the OEM and stored in the system firmware are then utilized during the execution of the computer system.

According to one aspect, a method is provided for updating the system management data of a computer system. According to the method, a system management information table is built during the execution of the computer system. The system management information table is built from a base set of management information and one or more updates to the base set of management information. In particular, the system management information table may be built using the base set of management information and the updates may be utilized to overwrite particular entries in the table. Alternatively, the system management information table may be built using information contained in both the base set of management information and the updates to the set of management information. According to one implementation, the management information table comprises a SMBIOS structure table compatible with the SMBIOS specification.

According to one aspect of the method, the base set of management information may be stored in a non-volatile memory device, such as an NVRAM. The updates to the base set of management information may also be stored in the non-volatile memory device. In one embodiment, the updates are stored in a protected boot block region of the non-volatile memory device. The updates to the management information may be read from the non-volatile memory device utilizing a system management interrupt (“SMI”).

According to another aspect of the method, a utility program is provided for storing the updates to the management information in the non-volatile memory device. In particular, the utility program is operative to receive the updates to the management information. The utility then stores the updates to the management information in the protected boot block of the non-volatile memory device. A SMI may be utilized by the utility program for reading the updates from the non-volatile memory device and for writing the updates to the non-volatile memory device. The utility program may be utilized, for instance, by an OEM to store updated management information in the firmware prior to shipping. At execution time, the updated management information is utilized by the computer system.

According to another aspect of the invention, a memory is provided for storing data for updating the management information of a computer system at runtime. The memory includes a management information update data structure stored in the memory. The management information update data structure includes a globally unique identifier (“GUID”) field for storing data that uniquely identifies the data structure. The data structure also includes a data area for storing the data for updating the management information of the computer system at runtime. The data structure also includes a length field for storing data identifying the length of the data field.

The data area of the management information update data structure includes a first data field for storing data identifying a table type within a system management information table. The data area also includes a second data field for storing data identifying an offset within the table type identified by the data stored in the first field. The data area also includes a third field for storing data for updating the contents of the system management information table at the location specified by the data stored in the first data field and the second data field. The system management information table may be an SMBIOS structure table.

These and various other features as well as advantages will be apparent from a reading of the following detailed description and a review of the associated drawings.

DETAILED DESCRIPTION

Methods, systems, apparatuses, and computer-readable media are provided herein for updating the system management information of a computer system. In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments or examples. Referring now to the drawings, in which like numerals represent like elements throughout the several figures, aspects of the various implementations provided herein and an exemplary operating environment will be described.

FIG. 1and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the embodiments described herein may be implemented. Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the embodiments described herein may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. The embodiments described herein may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

Turning now toFIG. 1, an illustrative computer architecture for practicing the embodiments presented herein will be described. It should be appreciated that although the embodiments described herein are discussed in the context of a conventional desktop or server computer, virtually any type of computing device may be utilized.FIG. 1shows an illustrative computer architecture for a computer100that is operative to update its system management information at runtime as described herein.

In order to provide the functionality described herein, the computer100includes a baseboard, or “motherboard”, which is a printed circuit board to which a multitude of components or devices may be connected by way of a system bus or other electrical communication path. In one illustrative embodiment, a CPU102operates in conjunction with a chipset104. The CPU102is a standard central processor that performs arithmetic and logical operations necessary for the operation of the computer. The computer100may include a multitude of CPUs102.

The chipset104includes a north bridge106and a south bridge108. The north bridge106provides an interface between the CPU102and the remainder of the computer100. The north bridge106also provides an interface to a random access memory (“RAM”) used as the main memory114in the computer100and, possibly, to an on-board graphics adapter112. The north bridge106may also include functionality for providing networking functionality through a gigabit Ethernet adapter110. The gigabit Ethernet adapter110is capable of connecting the computer100to another computer via a network. Connections which may be made by the network adapter110may include local area network (“LAN”) or wide area network (“WAN”) connections. LAN and WAN networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. The north bridge106is connected to the south bridge108.

The south bridge108is responsible for controlling many of the input/output functions of the computer100. In particular, the south bridge108may provide one or more universal serial bus (“USB”) ports116, a sound adapter124, an Ethernet controller134, and one or more general purpose input/output (“GPIO”) pins118. The south bridge108may also provide a bus for interfacing peripheral card devices such as a BIOS boot system compliant SCSI host bus adapter130. In one embodiment, the bus comprises a peripheral component interconnect (“PCI”) bus. The south bridge108may also provide a system management bus132for use in managing the various components of the computer100. Power management circuitry126and clock generation circuitry128may also be utilized during the operation of the south bridge108.

The south bridge108is also operative to provide one or more interfaces for connecting mass storage devices to the computer100. For instance, according to an embodiment, the south bridge108includes a serial advanced technology attachment (“SATA”) adapter for providing one or more serial ATA ports120and an ATA100adapter for providing one or more ATA100 ports122. The serial ATA ports120and the ATA100 ports122may be, in turn, connected to one or more mass storage devices storing an operating system and application programs. As known to those skilled in the art, an operating system comprises a set of programs that control operations of a computer and allocation of resources. An application program is software that runs on top of the operating system software, or other runtime environment, and uses computer resources to perform application specific tasks desired by the user. As will be described in greater detail below, an application is provided herein that stores system management information updates in the firmware136stored in the NVRAM137.

The mass storage devices connected to the south bridge108and the SCSI host bus adapter130, and their associated computer-readable media, provide non-volatile storage for the computer100. Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available media that can be accessed by the computer100. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, DVD, HD-DVD, BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer.

A low pin count (“LPC”) interface may also be provided by the south bridge108for connecting a “Super I/O” device138. The Super I/O device138is responsible for providing a number of input/output ports, including a keyboard port, a mouse port, a serial interface, a parallel port, and other types of input/output ports. The LPC interface may also connect a computer storage media such as a ROM or a flash memory such as a NVRAM137for storing the firmware136that includes program code containing the basic routines that help to start up the computer100and to transfer information between elements within the computer100. The Extensible Firmware Interface (“EFI”) firmware136comprises a firmware that is compatible with the EFI specification. It should be appreciated that although the embodiments described herein are discussed in the context of a computing system that utilizes an EFI-compatible firmware, other types of firmware may be utilized. For instance, the firmware may comprise a Basic Input and Output System (“BIOS”) firmware or other type of firmware known to those in the art. Additional details regarding the operation of the EFI firmware136are provided below with respect toFIGS. 2-3.

The LPC interface may also be utilized to connect a NVRAM137to the computer100. The NVRAM137may be utilized by the firmware136to store configuration data and other kinds of data for the computer100. In particular, as will be described in greater detail below, the NVRAM137may be utilized to store system management information for use by the computer system100. Updates to the system management information may also be stored in the NVRAM137and utilized by the computer100at execution time. The updates may also be stored in the main memory114or on a mass storage device. Additional details regarding this process will be provided below with respect toFIGS. 4-8. It should be appreciated that the configuration and other data for the computer100may be stored on the same NVRAM device as the firmware136.

According to one implementation, the CPU102comprises a general purpose microprocessor from INTEL CORPORATION. For instance, the CPU102may comprise a PENTIUM 4 or XEON microprocessor from INTEL CORPORATION. As known to those skilled in the art, such microprocessors support a system management mode (“SMM”). The SMM executes code in the firmware136to provide an alternative operating environment that can be used to monitor and manage various system resources for more efficient energy usage, to control system hardware, and/or to run proprietary code. The SMM computing mode was introduced by the INTEL CORPORATION in the 386SL processor. The SMM computing mode is also available in the PENTIUM 4, XEON, P6 family, and PENTIUM processors. SMM is also available in compatible microprocessors from other manufacturers.

SMM is a special-purpose operating mode for handling system-wide functions like power management, system hardware control, or proprietary OEM-designed code. It is generally intended only for use by system firmware, not by applications software or general-purpose system software. The main benefit of SMM is that it offers a distinct and easily isolated processor environment that operates transparently to the operating system or executive and software applications.

When SMM is invoked through a system management interrupt (“SMI”), the current state of the processor (the processor's context) is saved. The CPU102then switches to a separate operating environment contained in a special portion of the main memory114called the system management RAM (“SMRAM”). While in SMM, the CPU102executes SMI handler code to handle the SMI interrupt. When the SMI handler has completed its operations, it executes a resume (“RSM”) instruction. This instruction causes the saved context of the processor to be reloaded, causes the to processor to switch back to executing in protected or real mode, and to resume executing the interrupted application or operating-system program or task.

The execution of the SMM computing mode is transparent to applications and operating systems. This transparency is guaranteed because the only way to enter SMM is by means of an SMI, because the processor executes SMM code in a separate address space (the SMRAM) that can be made inaccessible from the other operating modes, because the processor saves the context of the interrupted program upon entering SMM, because all interrupts normally handled by the operating system are disabled upon entry into SMM, and because the RSM instruction can only be executed in SMM. Additional details regarding the operation of the SMM computing mode are provided in documentation available from INTEL CORPORATION and are well known to those skilled in the art. It should also be appreciated that the CPU102has other distinct execution modes, such as the real mode and the protected mode.

It should be appreciated that the computer100may comprise other types of computing devices, including hand-held computers, embedded computer systems, personal digital assistants, and other types of computing devices known to those skilled in the art. It is also contemplated that the computer100may not include all of the components shown inFIG. 1, may include other components that are not explicitly shown inFIG. 1, or may utilize an architecture completely different than that shown inFIG. 1.

Referring now toFIG. 2, additional details regarding the operation of the EFI firmware136of the computer100will be described. In most computing systems, low level instruction code is used as an intermediary between the hardware components of the computing system and the operating software and other high level software executing on the computing system. In some computer systems, this low-level instruction code is known as the BIOS. The BIOS provides a set of software routines that allow high-level software to interact with the hardware components of the computing system using standard calls.

Because of limitations of the BIOS in many PC-compatible computers, a new specification for creating the firmware that is responsible for booting the computer and for intermediating the communication between the operating system and the hardware has been created. The specification is called the Extensible Firmware Interface specification and is available from INTEL CORPORATION. The original EFI specification from INTEL CORPORATION is also being extended by the UNIFIED Extensible Firmware Interface Forum (“UEFI”).

The EFI specification describes an interface between the operating system and the system firmware. In particular, the specification defines the interface that platform firmware must implement and the interface that the operating system may use in booting. How the firmware implements the interface is left up to the manufacturer of the firmware. The EFI specification provides protocols for EFI drivers to communicate with each other, and the EFI core provides functions such as allocation of memory, creating events, setting the clock, and many others.

As described above, the firmware136comprises a firmware compatible with the EFI specification from INTEL CORPORATION or from the UEFI FORUM. The EFI specification describes an interface between the operating system202and the system firmware136. The EFI specification defines the interface that platform firmware must implement, and the interface that the operating system202may use in booting. How the firmware136implements the interface is left up to the manufacturer of the firmware. The intent of the specification is to define a way for the operating system202and firmware136to communicate only information necessary to support the operating system boot process. This is accomplished through a formal and complete abstract specification of the software-visible interface presented to the operating system by the platform and the firmware.

According to one implementation of EFI on INTEL CORPORATION IA-32 platforms, both the EFI206and a BIOS208may be present in the firmware136. The BIOS208may be provided in the form of a compatibility support module. This allows users and system integrators to support both firmware interfaces. In order to provide this functionality, an interface212may be provided for use by legacy operating systems and applications. Additional details regarding the architecture and operation of the EFI206are provided below with respect toFIG. 3. Moreover, additional details regarding the operation and architecture of EFI can be found in the EFI specification which is available from INTEL CORPORATION end expressly incorporated herein by reference.

EFI also provides an EFI environment that executes within the SMM mode described above. The “mini-EFI” that executes within the SMM is utilized to provide EFI-like functionality for programs executing within the SMM. Programs executing within the mini-EFI in SMM may have access to the functions and data utilized by the EFI206.

Turning now toFIG. 3, additional details regarding an EFI specification-compliant system utilized to provide an operating environment for the various implementations presented herein will be described. As shown inFIG. 3, the system includes platform hardware316and an operating system202. The platform firmware308may retrieve an OS image from the EFI system partition318using an EFI O/S loader302. The EFI system partition318may be an architecturally shareable system partition. As such, the EFI system partition318defines a partition and file system that are designed to allow safe sharing of mass storage between multiple vendors. An O/S partition320may also be utilized.

Once started, the EFI O/S loader302continues to boot the complete operating system202. In doing so, the EFI O/S loader302may use EFI boot services304and interface to other supported specifications to survey, comprehend, and initialize the various platform components and the operating system software that manages them. Thus, interfaces314from other specifications may also be present on the system. For example, the Advanced Configuration and Power Management Interface (“ACPI”) and the System Management BIOS (“SMBIOS”) specifications may be supported.

EFI boot services304provides interfaces for devices and system functionality that can be used during boot time. EFI runtime services306may also be available to the O/S loader302during the boot phase. For example, a minimal set of runtime services may be presented to ensure appropriate abstraction of base platform hardware resources that may be needed by the operating system202during its normal operation. EFI allows extension of platform firmware by loading EFI driver and EFI application images which, when loaded, have access to all EFI-defined runtime and boot services.

Various program modules provide the boot and runtime services. These program modules may be loaded by the EFI boot loader312at system boot time. The EFI boot loader312is a component in the EFI firmware that determines which program modules should be explicitly loaded and when. Once the EFI firmware is initialized, it passes control to the boot loader312. The boot loader312is then responsible for determining which of the program modules to load and in what order. It should be appreciated that both the operating system202and the EFI firmware may provide a runtime environment for application programs as described herein.

As discussed briefly above, the EFI may operate in conjunction with an interface from the SMBIOS specification. The SMBIOS specification addresses how motherboard and system vendors present management information about their products in a standard format. The information is intended to allow generic instrumentation to deliver this information to management applications, thereby eliminating the need for error prone operations like probing system hardware for presence detection. In particular, the SMBIOS provides management information in the form of a SMBIOS structure table that is exposed to the operating system202and applications. The SMBIOS structure table is created in the main memory114from a base set of management data for the hardware stored in the NVRAM137. For instance, the SMBIOS structure table may be created when the computer performs its power-on self test (“POST”). The SMBIOS structure table is also created using data from EFI or BIOS drivers. Once the SMBIOS structure table has been created in the memory114, it is exposed to the operating system202and applications.

The SMBIOS structure table may be accessed using a table-based method or through Plug-and-Play functions. In particular, a SMBIOS structure table entry point allows access to the SMBIOS structures through 32-bit protected-mode operating systems, such as MICROSOFT WINDOWS NT. In this manner, access can be had to the table directly. Information in the SMBIOS structure table can also be accessed through a Plug-and-Play function interface. The Plug-and-Play interface can be utilized to retrieve and modify entries in the SMBIOS structure table. Additional details regarding the operation and use of the SMBIOS can be found in the SMBIOS Reference Specification from the Distributed Management Task Force. Additional details regarding the creation of the SMBIOS structure table utilizing updated management information will be provided below with reference toFIGS. 4-8.

Referring now toFIG. 4, additional details will be provided regarding one embodiment provided herein for updating the system management data of the computer100. As discussed briefly above, the computer100maintains system management data that provides information regarding the hardware of the computer100. In one implementation, this information is provided in the form of an SMBIOS structure table408. The SMBIOS structure table408is created by the SMBIOS driver406.

The format of the SMBIOS structure table408is specifically defined by the SMBIOS Reference Specification, but generally includes a packed table of structures having different types. The structure types are also defined by the SMBIOS Reference Specification. Each structure type contains a number of data fields that are defined by an offset within the structure type. The SMBIOS structure table408is made available for use by the operating system202and other application programs, such as the update application402.

As shown inFIG. 4, the NVRAM137stores the EFI firmware136. The NVRAM137also stores a set of base management data424. The base management data424contains management data regarding the hardware of the computer100, and is utilized by the SMBIOS driver406to create the SMBIOS structure table408. The base management data424is typically generated at manufacture time and stored in the NVRAM137. It should be appreciated that data utilized within the SMBIOS structure table408may also be provided by drivers or protocols executing within the EFI firmware136or BIOS.

As will be described in greater detail herein, an update application402is provided that is operative to receive updates to the base management data424and to store the update data422in the NVRAM137. In particular, according to one implementation, the update data422is stored in the protected boot block region420of the NVRAM137. This protects the update data422from being overwritten during an update of the firmware137. The update data422may also be stored in the main memory114or on a mass storage device.

In order to read and write the updated data422in the NVRAM137, the update application402utilizes an SMI to invoke the SMM on the computer100. As shown inFIG. 5, a SMM dispatcher410is responsible for handling the processing of an SMI, including the identification of an appropriate SMM handler for handling the generated SMI. The SMM handlers are responsible for performing the actual processing necessary to handle the interrupt.

According to one implementation, a GET SMBIOS INFO handler414is provided for obtaining information about the SMBIOS structures contained in the NVRAM137. A GET SMBIOS STRUCTURE handler416is also provided for to retrieving the actual SMBIOS data from the NVRAM137. A SET SMBIOS STRUCTURE418is also provided for updating the SMBIOS structures stored in the NVRAM. The interfaces to these structures are similar to the interfaces to the corresponding Plug-and-Play structures utilized to access the SMBIOS structure table in the memory114.

According to implementations, the update application402is operative to retrieve the update data422from the protected boot block region420of the NVRAM137and to display the data. This is accomplished by generating an SMI, and calling the GET SMBIOS INFO handler414and the GET SMBIOS STRUCTURE handler416. The update application402is also operative to receive modifications to the data from a user. In response, the update application402is operative to write the updated management information to the update data422using the SET SMBIOS STRUCTURE handler418. As will be described in greater detail below, the SMBIOS driver406is operative to retrieve and utilize the update data422when creating the SMBIOS structure table408. Additional details regarding the operation of the update application402are provided below with respect toFIG. 5.

Referring now toFIG. 5, an illustrative routine500will be described that illustrates a process for storing the update data422in the NVRAM137. The logical operations of the various implementations presented herein are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance requirements of the computing system on which the embodiments described herein are implemented. Accordingly, the logical operations making up the implementations described herein are referred to variously as operations, structural devices, acts or modules. It will be recognized by one skilled in the art that these operations, structural devices, acts and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof without deviating from the spirit and scope of the present invention as recited within the claims attached hereto.

The routine500begins at operation502, where the update application402retrieves the update data422from the NVRAM137using the GET SMBIOS INFO and GET SMBIOS STRUCTURE handlers414and416, respectively. The routine500then continues to operation504, where the update application402displays the current contents of the update data422. At operation506, the update application402receives updates to the management data from a user. The routine500then continues to operation508, where the updates received from the user are written to the update data422using the SET SMBIOS STRUCTURE handler418. From operation508, the routine500continues to operation510, where it ends.

Referring now toFIG. 6, an aspect of one embodiment for updating the SMBIOS structure table408will be described. As discussed briefly above, the SMBIOS driver406builds the SMBIOS structure table408. According to embodiments, the SMBIOS driver406is operative to generate the SMBIOS structure table408using the base management data424stored in the firmware137. Additionally, the SMBIOS driver406is further operative to retrieve the update data422from the NVRAM137using an SMI and the GET SMBIOS INFO handler414and the GET SMBIOS STRUCTURE handler416. The updated management data is then used to overwrite the appropriate entries in the SMBIOS structure table408. Alternatively, the SMBIOS driver406may create the SMBIOS structure table408using both the base data424and the update data422. In this manner, the update data422is utilized as part of the SMBIOS structure table408rather than the base management data424. Turning now toFIG. 7, an illustrative routine700will be described further illustrating the operation of the SMBIOS driver406. The routine700begins at operation702, where the SMBIOS driver406reads the base management data424from the NVRAM137. The SMBIOS driver406then begins building the SMBIOS structure table408using the management data contained in the base management data424. This occurs at operation704.

From operation704, the routine700continues to operation706, where the SMBIOS driver406determines whether updated management data has been stored in the protected boot block portion of the NVRAM137. If so, the routine700branches from operation706to operation708. Otherwise, the routine700continues to operation712, where it ends.

At operation708, the SMBIOS driver406retrieves the update data422from the NVRAM137. The routine700then continues to operation710, where the update data422is utilized to overwrite the appropriate portions of the SMBIOS structure table408, thereby updating its contents. As will be described in greater detail below with respect toFIG. 8, a data structure is provided herein for storing the update data422. The data structure also provides data defining the exact location within the SMBIOS structure table408for the management data. From operation710, the routine700continues to operation712, where it ends.

According to one implementation, a determination is made as to whether the particular structure table and field to be update is supported. If they are not supported, an error is returned. If the table and field to be updated are supported, the update data422is searched to locate the last data record of the table and field to be updated. If the update is indicated as being only a write once update, and the record already exists, an error is returned. If not, a determination is made as to where space exists for the update. If not, an attempt is made to compact the data area by removing previous updates. If space becomes available, then the update is made and success is returned. If space is not available, an error is returned.

Referring now toFIG. 8, an illustrative management information update data structure802will be described for storing the update data422. In particular, the data structure802includes a data field804A for storing a globally unique identifier (“GUID”) that uniquely identifies the data structure802. A data field804B is also provided for storing a header. A data field804C is provided for storing data that describes the length of a data field804D that is utilized to store the updated management information. A data field804E is also provided for storing a terminator that signifies the end of the data structure802.

According to one implementation, the area of the flash utilized to store the update data is initially an empty area of the flash device. The empty area consists of ‘0xff’ followed by a terminator of ‘0xffffffff.’ When reading the data area for update records, the area is read until a value of ‘0xffffffff’ is read. This value indicates that the last record has been read. This may be in the empty data area or the terminator.

As discussed briefly above, the data field804D is the actual data area that is utilized to store the updated management information. The data field804D is itself a data structure that includes not only the updated management information, but also information that describes the exact location within the SMBIOS structure table408where the updated management data should reside. In particular, the data field804D includes one or more structures806, each having the same format.

For instance, the structure806A includes a field808A for storing data identifying the table type within the SMBIOS structure table where the updated management data should be placed. A field808B is utilized to store data identifying the offset within the table identified by the data in the field808A. A field808C is utilized to store data indicating the actual size of the string that is utilized to update the management data (stored in the field808E). A field808D is utilized to store a flag that indicates whether the updated field may be updated only once or multiple times. A field808E is utilized to store the actual string for updating the management data in the location of the SMBIOS structure table408identified by the data in the fields808A and808B. In this manner, the data structure802provides not only the updated management data but also indicates the location within the SMBIOS structure table408where the data should be placed. It should be appreciated that any number of the structures806may be included in the data field804D.

Based on the foregoing, it should be appreciated that embodiments described herein provide methods, systems, apparatuses, and computer-readable media for updating the system management data of a computer system. Moreover, although the embodiments described herein have been described in language specific to computer structural features, methodological acts and by computer readable media, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific structures, acts or media described. Therefore, the specific structural features, acts and mediums are disclosed as exemplary embodiments implementing the claimed invention.