Patent Description:
During the last few years, considerable developments have been made in the arena of server management. An industry standard called Intelligent Platform Management Interface (IPMI), described in, e.g., "<NPL>, defines a protocol, requirements and guidelines for implementing a management solution for server-class computer systems. The features provided by the IPMI standard include power management, system event logging, environmental health monitoring using various sensors, watchdog timers, field replaceable unit information, in-band and out of band access to the management controller, SNMP traps, etc..

A component that is normally included in a server-class computer to implement the IPMI standard is known as a Baseboard Management Controller (BMC). A BMC is a specialized microcontroller embedded on the motherboard of the computer, which manages the interface between the system management software and the platform hardware. The BMC generally provides the "intelligence" in the IPMI architecture.

Most server-class computer systems on the market today have system components that require a firmware image to make them operational. "Firmware" is software that is stored in a read-only memory (ROM) (which may be reprogrammable), such as a ROM, PROM, EPROM, EEPROM, etc. Some examples of such components that require firmware are BMCs, the system basic input/output system (BIOS), storage controllers (e.g., SCSI/SAS/Fibre Channel components), and network interface controllers (NICs). These firmware images typically reside in the system flash memory where the BIOS resides or in component-specific flash parts.

As with any mechanical components, these system components can experience an operational problem that either degrades drive read-write performance or causes a drive failure. Some problems relate to drive firmware or hardware, including magnetic media, spin motor, read/write head assembly or drive circuitry. Such firmware and hardware problems generally dictate that the disk drive be returned to the original manufacturer for repair or replacement. Other potential problems are user-related, and often result from software problems within the storage operating system or user applications.

When operating in the server, the version of the installed firmware is customized and fully compatible to the peripheral IO of the motherboard. The settings of the firmware are typically aligned with the configuration of the chassis where it was installed. However, upon return of the system component after repair, the firmware may have been upgraded or downgraded during repair, i.e. configured in a repair mode. In addition, when providing a replacement or new system component, the firmware may be upgraded or downgraded relative to the original firmware, i.e. in a factory mode.

Restoration of the system component to its user mode with custom settings requires manually saving and restoring the system component settings and manually upgrading or downgrading reversion of the firmware per the customer's profile. However, manually performing these tasks can be burdensome in regards to costs and maintenance.

<CIT> describes a system and method of updating device firmware on a rack server computer system using a network switch.

The invention is defined by the subject-matter of the independent claim.

The present invention is described with reference to the attached figures, wherein like reference numerals are used throughout the figures to designate similar or equivalent elements. The figures are not drawn to scale and they are provided merely to illustrate the instant invention. Several aspects of the invention are described below with reference to example applications for illustration. It should be understood that numerous specific details, relationships, and methods are set forth to provide a full understanding of the invention. One having ordinary skill in the relevant art, however, will readily recognize that the invention can be practiced without one or more of the specific details or with other methods. In other instances, well-known structures or operations are not shown in detail to avoid obscuring the invention. The present invention is not limited by the illustrated ordering of acts or events, as some acts may occur in different orders and/or concurrently with other acts or events. Furthermore, not all illustrated acts or events are required to implement a methodology in accordance with the present invention.

In order to efficiently restore the system component to a user mode with custom settings, preferred embodiments of the present invention provide a method for autonomously provisioning firmware and custom settings for a server device. In this disclosure, a server device operating within a server rack can require service or replacement. The server device operating in the server rack can be operating with a specific firmware and custom settings. However, upon service or replacement, the server component can be provisioned with a different firmware, custom settings, or without custom settings. For example, upon service or replacement, the server component can be provisioned to operate in repair mode or factory mode. The present disclosure provides an efficient method for autonomously provisioning firmware and custom settings for a server device and/or components therein after service or replacement.

In some embodiments, the physical location of the server device and the associated device information is determined. Furthermore, a firmware package for the server device can be identified based on the installation location and identification information of the server device. The firmware can be installed based on the installation location and identification information of the server device. References in this specification to "an embodiment", "one embodiment", or the like, mean that the particular feature, structure or characteristic being described is included in at least one embodiment of the present invention. Occurrences of such phrases in this specification do not necessarily all refer to the same embodiment.

<FIG> illustrates an example system <NUM> for autonomously provisioning firmware and custom settings for a server device, according to some embodiments. In some implementations, system <NUM> can include server rack <NUM> that includes multiple servers <NUM>. Each server <NUM> can include various components such as one or more central processing units (CPU) <NUM>, one or more service controllers such as a management controller (MC) <NUM>, one or more sensors <NUM>, one or more storage devices <NUM>, and other components known in the art but not shown, such as power supplies, fans, memory modules, etc. In some embodiments, an exemplary MC can include a baseboard management controller (BMC), The approaches described herein are not limited to a particular service controller or set of service controllers.

CPU <NUM> can have multiple cores and be the main processor for server <NUM>. In some embodiments, at least one of the servers <NUM> can include multiple CPUs <NUM>. While reference is made herein to a "rack system," "server," "hard drive," "service controller" and the like, it should be understood that use of the singular in the examples herein does not preclude use of the plural in various embodiments.

In some embodiments, MC <NUM> is a specialized microcontroller (microprocessor), usually embedded on the motherboard of a computer, generally a server. For example, MC <NUM> manages the interface between system management software and platform hardware and monitors the physical state of server <NUM> using sensors and communicating with the system administrator <NUM> through an independent connection (e.g., out-of-band). The system management software is discussed at detail below. MC <NUM> is part of the intelligent platform management interface (IPMI) and can operate independently of CPU <NUM>.

In some embodiments, different types of sensors built into the server <NUM> report to MC <NUM> on parameters such as the installation location of a server component and the identification information of the server component. Server components can be a variety of IT components including, but not limited to, servers <NUM>, storage devices, network switches, terminal servers, power distribution units, server racks <NUM>, and so on. In some embodiments, the server rack <NUM> can include different types of server components, such as servers or other IT assets that may be operated from a server rack <NUM>. For example, the server rack <NUM> or the servers <NUM> themselves can include radio frequency identification (RFID) tags that are configured to monitor the server components. Alternatively, the server rack <NUM> or the servers <NUM> themselves can include an electrically erasable programmable read only memory (EEPROM) (not shown), which supports reprogramming and reading authenticity. Furthermore, in some embodiments, the identification is readable by a compatible hardware circuit and software, built inside the MC <NUM> or rack management controller (RMC) (not shown). In some embodiments, the sensors <NUM> are devices that can be monitored by IPMI through MC <NUM>.

<FIG> is a block diagram of server components to be tracked by implementing sensors installed within a server rack <NUM> or the servers <NUM> themselves according to an embodiment of the invention. As an exemplary embodiment, <FIG> implements RFID tags <NUM>, <NUM>, <NUM> attached to every asset that is to be tracked via the MC <NUM> or rack management controller (RMC) (not shown). In some embodiments, RFID tags <NUM> are associated with each server <NUM>. RFID tags <NUM> can be associated with a cluster of servers <NUM>. RFID tags <NUM> can be associated with the server rack <NUM>. In one embodiment, the MC <NUM> or rack management controller (RMC) (not shown) may be maintained by an organization controlling the assets. The RFID tags <NUM>, <NUM>, <NUM> can be synchronized with appropriate information in the MC <NUM>, including a description, owner, device serial number, location ID, and so on. In one embodiment, a previous bar code on an asset may be utilized for the synchronization. The information associated with the barcode is synchronized in the MC <NUM> to be further associated with the asset's new RFID tag <NUM>, <NUM>, <NUM>.

In some embodiments of the invention, the RFID tags <NUM>, <NUM>, <NUM> are passive tags. In other words, the tags <NUM>, <NUM>, <NUM> do not include their own battery or other power source. Passive tags typically are made of less expensive material and components, and therefore require less cost to implement. An outside source, such as an antenna, activates the passive tag so that the tag sends a signal. This signal includes the identification information and the installation location of the system component to be tracked by the MC <NUM> or rack management controller (RMC) (not shown). An outside source may then read the signal being sent by the system component for the MC <NUM> or rack management controller (RMC) (not shown). In some embodiments of the invention, this outside source may be the same source that activated the tag. For example, the outside source can include a RFID reader module.

In alternative embodiments of the invention, the RFID tags <NUM>, <NUM>, <NUM> can include any one of or a combination of passive, semi-passive, or active tags. Semi-passive tags include a battery that powers the tag, but otherwise do not have the requisite power to send a transmission signal to an antenna. Active tags include a power source that supports that tag powering up, as well as supports transmitting signals to an antenna.

In some embodiments of the invention, the actual size of the RFID tags <NUM>, <NUM>, <NUM> are no bigger than the actual height of the component the tag is identifying. For example, the RFID tag may be one inch by one inch in size. In other embodiments, the tag is internally made of a foam material with a type of Mylar on the outside of the tag. This helps protect the tag from various outside forces that can affect the correct operation of the tag, such as pulling, twisting, and banging on the tag. In the invention, the RFID tags <NUM>, <NUM>, <NUM> are orientated at a horizontal angle to the antenna that is powering the tag in order to facilitate correct operation of the tag. In addition, the RFID tags <NUM>, <NUM>, <NUM> can be offset at least a quarter-inch away from the server component it is identifying in order to reduce interference between the component and the RF signal from the tag. In one embodiment, a boot or other structure may be used to facilitate the tag's offset from the server component.

In still other embodiments, it is envisioned that a variety of attachments may be utilized to attach the RFID tags <NUM>, <NUM>, <NUM> to a server component. For example, at least one of or a combination of a clip, tie, or adhesive material may be utilized to attach the tag to the component. This attachment may be used in such a way as to maintain the other requirements, such as orientation and offset, for the correct operation of the RFID tag. It should be realized that the sensors <NUM> can be any devices configured to identify the server components to which they are assigned. The RFID devices mentioned above are only for example, and not to limit this disclosure. The person having ordinary knowledge in the art may flexibly select any devices in accordance with the disclosure. Upon determining the installation location of the server component, a firmware package for the server component can be identified based on the installation location and identification information of the server device.

<FIG> shows an exemplary system management software <NUM> in accordance with some embodiments. The system management software <NUM> can include a secured cloud server. In alternative embodiments of the invention, the system management software can include a local server. The system management software <NUM> can be configured as a data structure with a package header <NUM>. The package header <NUM> can include an array of certificates <NUM>. Furthermore, the system management software <NUM> can include server system information <NUM>, and server system identification <NUM>. Information and identification of the individual component can be included within the server system information <NUM> and server system identification <NUM>, respectively. Furthermore, the system management software <NUM> can include package data <NUM>, optional data <NUM> and an image data directory <NUM>. The image data directory <NUM> can include images 308N. The image files 308N can include various firmwares, which have been validated as a production version.

<FIG> is a block diagram of an exemplary methodology <NUM> for uploading the firmware package using the system management software <NUM> according to an embodiment. At step <NUM>, the firmware image 308N is collected from the server component by an operator <NUM>. At <NUM>, the server component information and identification is input into the system management software <NUM>. At <NUM>, the firmware package is prepared. Preparation of the firmware is discussed in greater detail below with respect to <FIG>. An owner private key <NUM> and a public key pair is associated with each server component. The public key pair is discussed in greater detail below. At step <NUM>, a sign tool is used. The private key <NUM> is used to create a signature to retrieve a secure image or encrypt the server component. The private key <NUM> is used to sign the firmware package, and install the certificate at step <NUM>. The current firmware is uploaded to the system management software <NUM> at step <NUM>.

<FIG> is a block diagram of an exemplary methodology <NUM> for the automatic provision of firmware for a server component according to an embodiment. At step <NUM>, the server component is received, provisioned to operate in factory mode. The server component includes a newly built server motherboard, provisioned with a standard version firmware and standard settings. In some embodiments, when a new server motherboard received is built at a production line, the firmware version and firmware settings are predetermined based on basic validation. In some embodiments, basic validation includes standard testing items of hardware function on a server motherboard, wherein the settings of the motherboard is configured for factory testing items instead of custom setting testing items. In this state, every firmware is configured in factory mode. An operator can then install the server component into the server <NUM>. The identification of the operational firmware associated with the server component can be logged into the server <NUM> and the server rack <NUM>. This firmware will be associated with this server component and its installation location.

At step <NUM>, upon installing the server component into the server <NUM> and the server rack <NUM>, the MC <NUM> or rack management controller (RMC) can determine the installation location by reading the identification from a tag. Based on the determined installation location, the MC <NUM> or rack management controller (RMC) can login, at step <NUM>, to a system management software (e.g., cloud based server) and download a firmware package appropriate for the server component located within the server <NUM> and the server rack <NUM>. The MC <NUM> then upgrades or downgrades the firmware within the server component to provision the server component to operate in a user mode. For example, in a user mode, the server component can include a server motherboard installed in server <NUM> and the server rack <NUM> provisioned with a compatible version firmware and standard settings.

At step <NUM>, upon installing the server component into the server <NUM> and the server rack <NUM>, the MC <NUM> or rack management controller (RMC) can determine the installation location by reading identification from tag. Based on the installation location, the MC <NUM> or rack management controller (RMC) can login to the system management software (e.g., cloud based server) and download a settings package appropriate for the server component located within the exact server <NUM> and the exact server rack <NUM>. The MC <NUM> then programs the settings within the server component to provision the server component to operate in a custom mode, in which a customer customizes their private settings for optimal hardware performance.

In some cases, distinct settings require proprietary programming methods. For example, a storage controller can support a setting preprogrammed throughout band interface, such as LSI Storlib function. The MC <NUM> can use an Inter-Integrated Circuit (I<NUM>C) bus to program the custom settings for the server component. Protocol may involve Management Component Transport Protocol (MCTP) over I<NUM>C, I<NUM>C and Platform Environmental Control Interface (PECI) etc. Once the custom setting is provisioned, the firmware is running as custom mode at step <NUM>. In the custom mode, the server component can include a server motherboard installed in server <NUM> of the server rack <NUM> provisioned with a compatible version firmware and custom settings. As with any mechanical components, the server component can experience an operational problem that either degrades drive read-write performance or causes a drive failure.

At step <NUM>, a user can submit the required warranty claim with the system component with a return merchandise authorization (RMA) form to the vendor's customer service. A service engineer can fill out a profile of the component failure in the system management software. In some embodiments, the service engineer can retrieve the setting of the component failure. Furthermore, the service engineer can upload settings to the system management software. In some embodiments of the invention, the system management software can include a secured cloud server. In alternative embodiments of the invention, the system management software can include a local server. The service engineer then programs the firmware within the server component to provision the server component to operate in a repair mode. When a service engineer repairs the server component, the MC <NUM> can recognize its variable of "state" as repair mode. Once the server component is installed into the server <NUM> and the server rack <NUM>, the MC <NUM> can recognize its state as being in the repair mode. The MC <NUM> can reprogram the old firmware setting by loading files through in-band, out of band or EEPROM. For example, in the repair mode, the server component can include a server motherboard installed in server <NUM> and the server rack <NUM> provisioned with a standard version firmware and standard settings. Upon returning the server component to the user, the server component is reinserted into the server <NUM> of the server rack <NUM>, and provisioned to operate in user mode (<NUM>). In an event the server component is replaced, a new server component, provisioned to operate in factory mode, is provided to the user (<NUM>) and the process can be repeated to reprovision.

<FIG> is a block diagram of an exemplary methodology <NUM> for upgrading or downgrading the firmware package using the system management software <NUM> in user mode according to an embodiment. When an operator <NUM> sends an Intelligent Platform Management Interface (IPMI) command or Representational state transfer (REST) or RESTful instructions to the MC <NUM>, it requests the MC <NUM> transfer its variable of "state" from factory mode to user mode. At step <NUM>, the MC <NUM> will examine its intranet connection to connect to a cloud server with specific IP address and domain name server. At step <NUM>, the MC <NUM> sends a request to the system management software <NUM> for the firmware package. The request refers to the identification of a server component within the server <NUM> to search for the latest firmware package with the same identification within the system management software <NUM>. An acknowledgement from the system management software <NUM> is received at step <NUM> to indicate receipt of the requests and delivery of the firmware package (step <NUM>).

After the system management software <NUM> delivers the latest firmware package with the same identification to the MC <NUM>, the MC <NUM> examines firmware package certificate of using the server product's public key <NUM>, at step <NUM>. The public key <NUM> is used to decode the secure image or decrypt the server component. At steps <NUM> and <NUM>, a determination is made regarding the security of the firmware certificate. Where the firmware certificate is determined to be unsecure, the methodology <NUM> advances to step <NUM> where a failure event is returned. At steps <NUM> and <NUM>, both the server component identification and the server component information are compared with the firmware package and the record of the server product to determine if they are identical. Where the comparison determines the two are not identical, the methodology <NUM> advances to step <NUM> where a failure event is returned. If the comparison determines the two are identical, the MC <NUM> ensures the firmware package is the one originally signed. A firmware list is created at step <NUM>. At step <NUM>, the verified firmware package can be used to upgrade/downgrade the firmware version in the server component. In the event of a failure, the package is not suitable for upgrade/downgrade. As a result, the operator may re-examine an error report of the eventlog, and proceed to a corrected action. In some embodiments, the corrected action can include, for example, re-uploading the firmware package to the system management software with a correct signature signed. This is the case where the error report of the eventlog indicates an incorrect signature was found.

<FIG> is a block diagram of an exemplary methodology <NUM> for programing settings within the server component to provision the server component to operate in a custom mode according to an embodiment. When an operator <NUM> sends an Intelligent Platform Management Interface (IPMI) command or Representational state transfer (REST) or RESTful instructions to the MC <NUM>, it requests the MC <NUM> transfer its variable of "state" from user mode to custom mode. At step <NUM>, the location of the server component within the server device and server rack is determined. The custom firmware setting can be loaded from the non-volatile memory. The software read/write interface can be invoked to program the custom firmware setting to the server component. For example, the MC <NUM> can load the custom firmware setting of storage controller and the custom firmware setting program into the server component device using I2C interface and Management Component Transport Protocol (MCTP) over Peripheral Component Interconnect (PCI interface).

At step <NUM>, the MC <NUM> creates a custom firmware list of the server component based on the installation location of the server component and the identification information of the server component. The MC <NUM> determines, at step <NUM>, whether the MC <NUM> supports the interface to be installed.

Where the MC <NUM> does not support the interface, an alternative method can be implemented where a BIOS (basic input output system) can be used to load its custom firmware setting. The process <NUM> advances to step <NUM>, where the category of the entity is identified. Next, the process proceeds to step <NUM>, a system management interrupt (SMI) number flag is asserted notifying the BIOS to load the custom firmware setting. At step <NUM>, an acknowledgement is received from the BIOS notifying the request is received and examined. Where the acknowledgement is received, the process advances from <NUM> to <NUM> where the completion stage determines the status is Normal (step <NUM>), the upload is logged as success at step <NUM>. Where an acknowledgement is not received, the process advances to step <NUM> where the process is determined to "Timeout. " At this point, the process cycles through the request at <NUM>, and either returns a "Success" notification at step <NUM> or restarts the process at step <NUM>.

Where the MC <NUM> supports the interface, the methodology <NUM> advances to step <NUM> where the custom setting for the server component is prepared.

Referring now to <FIG>. The program setting is installed in the server component at step <NUM>. Specifically, at step <NUM>, the MC <NUM> programs the custom setting to the storage controller on the server component. The custom setting is prepared at step <NUM>. The custom firmware setting can be loaded from the non-volatile memory. The software read/write interface can be invoked to program the custom firmware setting to the server component. For example, the MC <NUM> can load the custom firmware setting of storage controller and the custom firmware setting program into the server component device using I2C interface (step <NUM>) or the Management Component Transport Protocol (MCTP) (step <NUM>) over Peripheral Component Interconnect (PCI interface). Once installed, the status from the storage controller can be collected at step <NUM>.

Referring now to <FIG>. After loading the custom firmware setting of storage controller and the custom firmware setting program into the server component device, the settings can be verified at step <NUM>. Where the verification stage determines the status is Abnormal (step <NUM>) or Normal (step <NUM>), the installation is logged as success at step <NUM>.

In some embodiments, the custom firmware setting can be preserved in a non-volatile memory of the server component or the server <NUM>. For example, the custom firmware setting can be preserved in the EEPROM of the MC <NUM>, in a UEFI BIOS flash chip, or an EEPROM of the RMC. The format of the custom firmware setting can be limited by the device's software read/write interface, where writing the custom firmware setting to the device uses independent software interface which has been built inside the BMC, the UEFI BIOS or the RMC.

<FIG> is a block diagram of an alternative exemplary methodology <NUM> for programing settings within the server component to provision the server component to operate in a custom mode according to an embodiment. In the alternative exemplary process , an UEFI (unified extensible firmware interface) BIOS (basic input output system) can be used to load its custom firmware setting. As an initial matter, the MC <NUM> is queried for the custom firmware (BIOS) settings and configuration at step <NUM>. At step <NUM>, the MC <NUM> can determine whether to load the custom firmware (BIOS) settings and configuration of the storage controller and the custom firmware setting program into the server component device. Where the BIOS settings are determined to be configured to load, the process <NUM> advances to step <NUM>, where the custom settings are prepared. At step <NUM>, the program settings can be stored on the firmware nonvolatile random access memory (NVRAM), where the MC <NUM> is notified (step <NUM>). The process advances to step <NUM> where a determination is made whether to boot the system and finalize the installation of the custom firmware. If an error occurs in the installation process, the process <NUM> advances to step <NUM>, where the BIOS POST sequence load process repeats.

<FIG> is a block diagram of an alternative exemplary methodology <NUM> for firmware setting reading in RMA state according to an embodiment. During the RMA state, a service engineer <NUM> can record the server component information and server component identification as a customer profile when the failure server component is received. Because a user can have new custom settings per their usage, the service engineer can get new custom firmware setting from the failed server component, or request the customer to provide their existing custom firmware setting from a servicing server component.

At step <NUM>, a service engineer sends the IPMI command or REST or RESTful instructions to the MC <NUM>, and request the MC <NUM> to collect the firmware custom setting of all entities. At step <NUM>, the MC <NUM> can determine if its software interface is configured to retrieve existing settings. If the MC <NUM> is configured to retrieve existing settings the process <NUM> advances to step <NUM>, where the software interface is located. In some embodiments, each one of the firmware existing/custom settings has a private format. The MC <NUM> can save the firmware setting as a text file, binary file, JavaScript Object Notation (JSON), or a file format deliverable through in-band service and out-of band service from the MC <NUM>. At step <NUM>, the process <NUM> determines the destination of the output. In some embodiments, the service engineer can decide to upload the file to the system management software <NUM> (step <NUM>), or perform a backup to either the EEPROM of the server component (step <NUM>), the EEPROM of the server rack <NUM> or the EEPROM of the RMC through the MC <NUM> influence.

After upload the file to the system management software <NUM> (step <NUM>), or perform a backup to either the EEPROM of the server component (step <NUM>), MC <NUM> determines if the upload is complete at step <NUM>. Where the completion stage determines the status is Normal (step <NUM>), the upload is logged as success at step <NUM>.

Where the MC <NUM> is not configured to retrieve the existing settings, an alternative method can be implemented where a BIOS (basic input output system) can be used to load its custom firmware setting. The process <NUM> advances to step <NUM>, where the category of the entity is identified. Next, the process proceeds to step <NUM>, a system management interrupt (SMI) number flag is asserted notifying the BIOS to load the custom firmware setting. At step <NUM>, an acknowledgement from the BIOS notifying the request is received and examined. Where the acknowledgement is received, the process advances from <NUM> to <NUM> where the completion stage determines the status is Normal (step <NUM>), the upload is logged as success at step <NUM>. Where an acknowledgement is not received, the process advances to step <NUM> where the process is determined to "Timeout. " At this point, the process cycles through the request at <NUM>, and either returns a "Success" notification at step <NUM> or restarts the process at step <NUM>.

While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Numerous changes to the disclosed embodiments can be made in accordance with the disclosure herein without departing from the scope of the invention. Thus, the breadth and scope of the present invention should not be limited by any of the above described embodiments. Rather, the scope of the invention should be defined in accordance with the following claims.

Although the invention has been illustrated and described with respect to one or more embodiments, equivalent alterations and modifications will occur to others skilled in the art upon the reading and understanding of this specification and the annexed drawings. In addition, while a particular feature of the invention may have been disclosed with respect to only one of several embodiments, such feature may be combined with one or more other features of the other embodiments as may be desired and advantageous for any given or particular application.

Furthermore, to the extent that the terms "including", "includes", "having", "has", "with", or variants thereof are used in either the detailed description and/or the claims, such terms are intended to be inclusive in a manner similar to the term "comprising.

Claim 1:
A method comprising:
determining an installation location and identification information of a server device (<NUM>) installed into a rack device (<NUM>), wherein the server device (<NUM>) is operating in a first mode of operation, the first mode of operation including at least one of a factory mode and a repair mode;
identifying a firmware package for the server device (<NUM>) based on the installation location and identification information of the server device (<NUM>); and
installing the firmware package based on the determined installation location and the identification information of the server device (<NUM>); wherein
installation of the firmware package configures the server device (<NUM>) to operate in at least one of a custom mode having custom setting or a user mode; wherein
the firmware package is configured as a data structure comprising:
a package header, wherein the package header comprises an array of certificates (<NUM>);
server device information (<NUM>);
server device identification (<NUM>);
firmware package data (<NUM>); and
image files (308N) corresponding with firmware validation,
determining the installation location comprises reading an RFID tag (<NUM>, <NUM>, <NUM>) associated with the rack device (<NUM>) and the installation location,
the RFID tag (<NUM>, <NUM>, <NUM>) is orientated at a horizontal angle to an antenna that is powering the RFID tag (<NUM>, <NUM>, <NUM>);
in the factory mode, the server device (<NUM>) comprises a newly built server motherboard, provisioned with a standard version firmware and standard settings;
the repair mode comprises firmware version and custom setting configured by a service engineer prior to service and uploaded to a cloud server;
in the custom mode, a customer customizes private settings for optimal hardware performance; and
the user mode comprises
a firmware upgrade from the first mode of operation,
a firmware downgrade from the first mode of operation, and/or
the user mode comprises an additional setting provision from the first mode of operation.