Method, device and computer program product for composing modular firmware

Abstract

Boot firmware for a computing device may be modularly and dynamically composed to facilitate changes and updates to the firmware of the computing device. The firmware image may include a main module and a module list, the main module is responsible for certain basic initializations, and the module list may include a list of additional modules that are executed during the boot process. The module list may be used to identify and access a module selected from a module library, such as via a globally unique identifier. Once the selected module is obtained, the selected module may be executed taking into account required dependent modules (whether or not included in the selected module) and configuration settings. The module library may be stored entirely locally (such as part of a distributed firmware image), entirely remotely, or a mixture of local and remote.

Description

Technical Field

[0001] The present disclosure relates generally to computing devices, and more particularly to firmware used to enable computing devices to operate. Background Art

[0002] Firmware is used for a variety of purposes in today's computing devices, such as personal computers, servers, and other devices. Boot firmware, such as the Basic Input / Output System (BIOS) and / or the Unified Extensible Firmware Interface (UEFI), handles various initialization procedures when the computing device is booted, such as initializing and facilitating communication with the computing device's hardware and initializing the operating system. Firmware is typically stored and installed in memory (such as Serial Peripheral Interface Read Only Memory (SPI ROM)) during manufacturing.

[0003] If an end user wishes to make changes to the firmware, such as debugging issues, improving performance, customization, or adding new features, the user will need to submit a request to a developer, such as an Original Equipment Manufacturer (OEM) or Original Design Manufacturer (ODM). Once the request is made, the OEM or ODM will make the requested changes to the firmware and rebuild the firmware image. This new firmware image then needs to be installed in the computing device, whether it is installed by the OEM, ODM, or the end user. Additional steps may also be required, such as verification / testing of the new firmware image and restarting the computing device. This entire process can be expensive and time-consuming. In addition, regardless of the type or scope of the requested changes, the time and money investment required to merge the new firmware image may be approximately the same. Therefore, even small changes to the firmware code may ultimately require considerable time and expense. Summary of the invention

[0004] The term "embodiment" and similar terms are intended to refer broadly to all application subject matter of the present invention and the claims that follow. Statements containing these words should not be understood to limit the application subject matter described herein or to limit the meaning or scope of the claims that follow. The embodiments of the present disclosure covered herein are defined by the following claims rather than by this disclosure. This disclosure is a high-level overview of various aspects of the disclosure and introduces some concepts that are further described in the following implementation paragraphs. This disclosure is not intended to identify the necessary features of the requested application subject matter, nor is it intended to be used alone to determine the scope of the requested application subject matter. The application subject matter should be understood by reference to appropriate portions of the entire specification of the present invention, any or all of the drawings, and each claim.

[0005] An embodiment of the present disclosure includes a method for composing modular firmware, comprising accessing a firmware image stored locally from a computing device. The firmware image includes a main module and a module list. The method also includes executing the main module, and executing the main module includes initializing one or more hardware resources of the computing device. The method also includes accessing a module list associated with the firmware image. The module list includes unique identification information of a group of selected modules associated with a module library. The module library includes multiple executable modules. The method also includes composing a firmware package based on the group of selected modules. Composing the firmware package includes accessing each module of the group of selected modules. The method also includes executing the firmware package.

[0006] In some cases, forming the firmware package also includes accessing dependency information associated with at least one module of the group of selected modules. Forming the firmware package also includes using the dependency information to identify additional modules. In some cases, the additional module is not included in the group of selected modules. In this case, forming the firmware package also includes adding the additional module to the firmware package. In some cases, the dependency information identifies the parent module and the child module. In this case, forming the firmware package also includes using the dependency information to generate a module sequence. Generating the module sequence includes deploying the parent module in the module sequence before the child module. In this case, executing the firmware package includes executing the firmware package based on the module sequence.

[0007] In some cases, the module library is stored in a firmware image. In some cases, at least some of the module library is stored in a remote storage device accessible via a network interface. In this case, accessing each module of the set of selected modules includes accessing at least one module of the set of selected modules from the remote storage device via the network interface.

[0008] In some cases, the computing device includes a processor and an independent processor. In this case, executing the main module, accessing the module list, and assembling the firmware package are implemented by the independent processor; and executing the firmware package is implemented by the main processor. In some cases, assembling the firmware package also includes copying each module of the group of selected modules to a system memory accessible to the main processor. In this case, executing the firmware package includes accessing the firmware package from the system memory. In some cases, the method also includes accessing configuration parameters from the firmware image and storing the configuration parameters in the system memory. The method also includes storing a module sequence in the system memory, the module sequence indicating the order in which the modules of the firmware package are executed. In this case, executing the firmware package also includes executing each module of the firmware package in the order indicated by the module sequence. Executing each module of the firmware package includes applying the configuration parameters.

[0009] In some cases, the method also includes accessing configuration parameters associated with a module list, wherein executing the firmware package includes applying the configuration parameters. In some cases, the method also includes initializing an operating system after executing the firmware package. In some cases, the method also includes updating the module list to generate an updated module list, the updated module list having a set of updated selected modules. The set of updated selected modules is different from the set of selected modules. In this case, the method also includes restarting the computing device, and forming an updated firmware package based on the set of updated selected modules. The method also includes executing the updated firmware package. In some cases, the computing device includes one or more hardware resources and one or more additional hardware resources. Executing the firmware package includes initializing one or more additional hardware resources.

[0010] Embodiments of the present disclosure include a computer program product tangibly embodied in a non-transitory machine-readable storage medium, comprising a plurality of instructions configured to cause one or more data processing devices to implement any of the methods described above.

[0011] An embodiment of the present disclosure includes a computing device that composes modular firmware. The computing device includes a first hardware device, a second hardware device, and one or more processors. The computing device also includes a non-transitory computer-readable storage medium containing multiple instructions that, when executed on one or more processors, cause the one or more processors to perform operations. The multiple operations include accessing a firmware image, the firmware image including a main module and a module list. The multiple operations also include executing the main module, and executing the main module includes initializing the first hardware device. The multiple operations also include accessing a module list associated with the firmware image. The module list includes unique identification information of a group of selected modules associated with a module library. The module library includes multiple executable modules. The multiple operations also include composing a firmware package based on the group of selected modules. Composing the firmware package includes accessing each module of the group of selected modules. The multiple operations also include executing an updated firmware package, and executing the updated firmware package includes initializing the second hardware device.

[0012] In some cases, forming the firmware package also includes accessing dependency information associated with at least one module of the group of selected modules. Forming the firmware package also includes using the dependency information to identify additional modules. In some cases, the additional module is not included in the group of selected modules. In this case, forming the firmware package also includes adding the additional information to the firmware package. In some cases, the dependency information identifies the parent module and the child module. In this case, forming the firmware package also includes using the dependency information to generate a module sequence. Generating the module sequence includes deploying the parent module in the module sequence before the child module. In this case, executing the firmware package includes executing the firmware package based on the module sequence.

[0013] In some cases, the firmware image is stored in a non-transitory computer-readable storage medium. In some cases, at least some of the module libraries are stored in a remote storage device accessible via a network interface. In this case, the computing device also includes a network interface. Accessing each module of the set of selected modules includes accessing at least one module of the set of selected modules from the remote storage device via the network interface.

[0014] In some cases, one or more processors include a main processor and an independent processor. Executing the main module, accessing the module list, and assembling the firmware package are implemented by the independent processor; and executing the firmware package is implemented by the main processor. In some cases, assembling the firmware package also includes copying each module of the group of selected modules to a system memory accessible to the main processor. Executing the firmware package includes accessing the firmware package from the system memory. In some cases, the multiple operations also include accessing configuration parameters from the firmware image and storing the configuration parameters in the system memory. The multiple operations also include storing a module sequence in the system memory. The module sequence indicates the order in which the modules of the firmware package are executed. In this case, executing the firmware package also includes executing each module of the firmware package in the order indicated by the module sequence. Each module of the firmware package includes application configuration parameters.

[0015] Additional features and advantages of the present disclosure will be set forth in the following description and will, to some extent, be apparent from the description or may be learned by the practice of the principles set forth herein. The features and advantages of the present disclosure may be realized and obtained by the apparatus and combinations of means particularly indicated in the appended claims. These and other features of the present disclosure will become fully apparent from the following description and appended claims or may be learned by the practice of the principles set forth herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] This specification refers to the following accompanying drawings, in which the same reference symbols are used in different drawings to indicate the same or similar components.

[0017] Figure 1 is a schematic diagram depicting a computing environment implementing modular firmware components according to certain examples of the present disclosure.

[0018] Figure 2 is a schematic diagram depicting an initial firmware suite and an executable firmware package according to certain examples of the present disclosure.

[0019] Figure 3 is a schematic diagram illustrating a general module library used on multiple computing devices according to certain examples of the present disclosure.

[0020] Figure 4 is a flow chart depicting a process for modularly composing firmware on multiple computing devices according to certain examples of the present disclosure.

[0021] Figure 5 is a block diagram of an example system architecture that implements certain examples and features of the present disclosure.

[0022] The present disclosure is susceptible to various modifications and alternative forms. Certain representative embodiments have been shown by way of example in the accompanying drawings and will be described in detail herein. However, it should be understood that the present invention is not intended to be limited to the particular form disclosed. On the contrary, the present disclosure encompasses all modifications, equivalents, and alternatives falling within the scope and spirit of the present invention as defined by the appended claims. DETAILED DESCRIPTION

[0023] Certain examples and features of the present disclosure relate to boot firmware for a computing device that can be modularly and dynamically composed to facilitate changes and updates to the firmware of the computing device. The firmware image can include a main module and a module list, the main module is responsible for certain basic initializations, and the module list can include a list of additional modules that are executed during the boot process. The module list can be used to identify and access a module selected from a module library, such as via a globally unique identifier (GUID). Once the selected module is obtained, the selected module can be executed taking into account required dependent modules (whether or not included in the selected module) and configuration settings. The module library can be stored entirely locally (such as part of a distributed firmware image), entirely remotely (such as accessed via a network connection), or a mixture of local and remote.

[0024] Certain examples and features of the present disclosure can be used with any applicable computing device that uses firmware during bootup, such as a personal computer (e.g., a notebook computer, a desktop computer, or a similar device), a portable computing device (e.g., a tablet, a smartphone, or a similar device), or a computing server (e.g., a rack-mount server or a blade server). The bootup process can begin after the computing device is powered on or after a reboot. During the bootup process, the boot firmware is executed. Conventional boot firmware is often BIOS and / or UEFI firmware, but the present disclosure is not intended to limit the firmware to any particular architectural style.

[0025] According to certain examples of the present disclosure, a modular firmware image may include at least a primary module and a secondary module. The primary module includes platform-dependent (e.g., chipset-dependent) basic essential code to initialize certain hardware resources necessary to access the secondary module and subsequent additional modules. For example, the primary module may include code to allow reading of a storage device storing additional modules. The secondary module includes a module list and, optionally, configuration parameters. The module list is a list of all modules used during the boot process. In some cases, the module list is referred to as a module recipe or firmware recipe. The secondary modules may be stored in non-volatile random access memory (NVRAM), allowing the module list to be modified as needed, such as via a management interface or application programming interface (API). Modification of the module list may allow an individual to modify the firmware that is ultimately executed during the boot of the computing device. Configuration parameters may include global parameters or module-specific parameters. Module-specific parameters may be passed to any add-in module when the add-in module is executed.

[0026] In some cases, users (e.g., end users, distributors, manufacturers, developers, and others who use computing devices) can modify the module list based on system requirements without having to reprogram the entire firmware and rebuild the firmware image. For example, a manufacturer can implement the same firmware image across a large number of different products, only adjusting the major modules and / or minor modules for the individual requirements of each different product. In such an example, a low-end personal computer and a high-end personal computer can share the same firmware image, including the same module library, but different minor modules. Thus, the minor modules of the low-end personal computer can include a module list specific to the hardware and features of the low-end personal computer, so that the low-end personal computer only uses those modules on its module list to boot. Similarly, the minor modules of the high-end personal computer can include a module list specific to the hardware and features of the high-end personal computer, so that the high-end personal computer only uses those modules on its module list to boot. In order to implement a third product (e.g., a mid-range personal computer), the manufacturer can reuse the same firmware image and only modify the minor modules for that specific product. In some cases, the module library may be stored locally (e.g., on a SPI ROM), such as in a firmware image distributed to a computing device. In other cases, some or all of the module libraries may be located on a remote storage device, such as a network server. As used herein, module libraries stored and accessed locally may be referred to as in-band module libraries, while module libraries stored and accessed remotely, such as via a network interface, may be referred to as out-of-band module libraries. In some cases, in-band module libraries may still be updated via a network interface (e.g., via a network interface of a baseboard management controller (BMC)).

[0027] In addition, if it is necessary or desirable to update individual modules of the firmware, certain examples of the present disclosure allow such updates to be easily performed. In some cases, a new firmware image can be generated and distributed to all computing devices, with each computing device retaining only its major modules and / or minor modules, or with new major modules and / or minor modules. In other cases, modules of a module library can be updated and distributed individually, including any related modules based on dependencies (e.g., if the updated module is currently dependent on a new parent module or an updated parent module, that parent module can also be updated; similarly, in some cases, the updated module may require that the child modules that are dependent on the updated module are also updated, in which case the child modules can also be updated). In some cases, the entire module library or a portion of the module library (e.g., some or all of the module library stored on a remote storage device) can be updated.

[0028] As used herein, the term "firmware image" may refer to a single file (e.g., a binary file) or to multiple files. For example, in some cases, a firmware image may include a primary module, a secondary module, and a module library in a single file. However, in other cases, a firmware image including a primary module, a secondary module, and a module library may be divided into multiple files (e.g., a first file including a primary module, a second file including a secondary module, and a third file including a module library). In some cases, the term "firmware image" may refer to a single file or multiple files located in a contiguous memory space.

[0029] According to certain examples of the present disclosure, a computing system may use a main processor for booting. As used herein, the term "main processor" may include any processing device that can be used to read and execute boot firmware code, such as a purpose-built processor, a central processing unit (CPU) of a computing device, or a core of a central processing unit. In some cases, the boot process may also use an additional independent processor. As used herein, the term "independent processor" is intended to indicate that the independent processor is assigned to the task of implementing certain boot functions that are not implemented by the main processor. The independent processor may be isolated from the main processor so that the code and data loaded into the independent processor cannot be directly accessed by the main processor during execution. The independent processor may be any suitable processor, such as an external microcontroller, or a core within a central processing unit (such as a platform security processor (PSP), such as a platform security processor implemented through a trusted execution environment). Such an independent processor (such as a PSP) may be an isolated security processor that operates independently of the main core of the computing device. This independent processor can be responsible for providing the hardware root of trust, training memory, copying BIOS into dynamic random access memory (DRAM), and releasing control of the core (such as an x86 core).

[0030] When only the main processor is used during the boot process, the primary modules may be executed to initialize various hardware resources, and then the secondary modules may be accessed to identify the module list and any existing configuration parameters. The main processor will then proceed to compose a firmware bundle containing each selected module in the module list and then execute the firmware bundle. In some cases, composing the firmware bundle only includes identifying the modules to be executed, such as by including the selected modules from the module list, and including any additional dependent modules that may be necessary to execute any selected modules. In some cases, composing the firmware bundle includes generating a module sequence, or the order in which the modules are to be executed. The processor may then execute the firmware bundle by accessing a module library and executing each assigned module. In some cases, the processor executes the module directly from the module library, however this is not always necessary. In some cases, composing the firmware bundle includes copying the assigned modules to a storage location and then executing the plurality of modules from the storage location. Once all the assigned modules have been executed, the processor may initialize and / or transfer control to the operating system.

[0031] According to certain examples of the present disclosure, when an independent processor is used in parallel with a main processor to boot a computer, the independent processor may be assigned the task of identifying a selected module from a module list of secondary modules, and then copying the selected module to a storage device (e.g., system memory) that is accessible to the main processor. In some cases, the independent processor may execute the primary module and then access the secondary module. In other cases, the independent processor may only copy the selected module to the system memory, and let the main processor execute the primary module, and then execute the copied selected module.

[0032] In one example, when a boot process begins, the standalone processor may initialize system memory; check system requirements from a storage component (e.g., a module list); load and access a module library (e.g., locally and / or remotely); based on the system requirements (e.g., a module list), copy selected modules to system memory, optionally including dependent modules; optionally store additional memory settings and / or module sequences to a table; and release control to the main processor. Once control of the main processor has been released, the main processor may optionally execute the primary module; optionally load the memory settings and / or module sequence from the table; and optionally use the module sequence to execute the copied module.

[0033] In some cases, the module list is a list of GUIDs of selected modules that are executed during the startup of the program, however this is not always necessary. In some cases, the module list may include additional information, such as one or more comments (e.g., a comment indicating the name or target of the module associated with a particular GUID). The module list may be user-updatable. In some cases, the module list may exist in a specific order, or may include sequence information, however this is not always necessary. In some cases, the module sequence is automatically generated based on the module properties of each selected module.

[0034] In some cases, a module list may include an alternate module GUID associated with a particular module GUID. For example, a module list may include a module GUID of "module A," and a module GUID of "module A1" associated with the module GUID of module A. In this case, module A1 may be an alternate or new version of module A, and when both module A and module A1 are compatible with the computer system, it will be used if available. The processor may search for module A1 in the module library, and if module A1 is found, further use of that module. However, if module A1 cannot be found in the module library, the processor may fall back to using module A.

[0035] In some cases, a module list may take the form of, or be interpreted as, a collection of records. Each record may represent a segment of code that is executed. In some cases, a record may contain a single module GUID, in which case the record indicates that the given module GUID will be used. In some cases, a record may contain a basic module GUID, and one or more alternative module GUIDs to that basic module GUID. Thus, as used herein, the phrase "each module of the set of selected modules" and similar phrases may include, as appropriate: (i) all modules identified at various locations in the set of selected modules; or (ii) one module per record of the module list. Thus, for a module list that includes only module A and alternative module A1, executing "each module of the set of selected modules" may mean executing only module A1, or executing only module A if module A1 is not available when both modules A and A1 are compatible with the computer system.

[0036] In some cases, the module list in the secondary module is stored locally, such as in a SPI ROM or in a memory of a BMC of the computing device, but this is not always necessary. In some cases, the module list can be stored in a remote storage device accessible via a network interface. In some cases, a management interface (such as a BMC web user interface (WebUI) or a universal asynchronous receiver / transmitter (UART) console) can be used to provide management of the module list and / or configuration parameters.

[0037] Each module may include attribute information. The attribute information may be in the form of a table, but this is not always necessary. The attribute information may include the module's GUID, the module's version information, and dependency information. The dependency information may include any parent module dependencies (e.g., modules that must be executed before executing a given module) and / or any child module dependencies (e.g., required child modules that must be executed after executing a given module, or optional child modules that need to be executed before executing a given child module). Other information may also be included in the attribute information, such as the module's location (e.g., location in memory), module size, required variables or parameters, and optional variables or parameters.

[0038] When accessing a module library and / or when assembling a firmware package, attribute information may be accessed for each selected module from the module list. The attribute information may be used to (i) ensure that the correct module is selected; (ii) identify any additional modules to be executed that are not included in the module list; and (iii) generate a module sequence that ensures that a parent dependent module is executed before its child modules.

[0039] For example, if a GPU module for initializing a graphics processing unit (GPU) card is included in the module list, that GPU module may include dependency information indicating that a memory module for increasing memory address space will be executed first. If that GPU module is not already in the module list, it will be included in the firmware package to be executed. By using dependency information, a module sequence including the memory module can be generated before the GPU module. In some cases, a parent dependent module itself may require further parent dependent modules.

[0040] In some cases, a management interface (e.g., a BMC WebUI, a UART console, or any other suitable interface) may be used to check the properties (e.g., dependencies) of a given module in a module library. In some cases, if the management interface is used to provide or modify a module list (e.g., in a secondary module), the management interface may automatically check the properties of the selected module and add any necessary dependent modules. In some cases, the management interface may further automatically arrange the module list into a module sequence to ensure that parent dependent modules are executed before their child dependent modules. In some cases, the management interface may store custom module lists and / or configuration settings, allowing a user to deploy custom module lists and / or configuration settings across multiple computing devices.

[0041] The present invention can be implemented in many different forms. Representative embodiments are shown in the accompanying drawings and will be described in detail herein. The present disclosure is an example or illustration of the principles of the present invention, and is not intended to limit the broad viewpoints of the present disclosure to the illustrated embodiments. On this basis, elements and limitations disclosed in paragraphs such as the abstract, the invention content and the embodiments, but not explicitly listed in the claims, should not be incorporated into the claims individually, collectively, implicitly, inferentially or otherwise. For the purpose of this detailed description, unless specifically denied, the singular includes the plural, and vice versa; and the word "include" means "include without limitation". In addition, words that represent approximation, such as "about", "almost", "substantially", "approximately" and similar words, can be used here to mean "in", "near", "close to", "within the range of 3-5%" or "within an acceptable manufacturing tolerance", or any logical combination thereof.

[0042] These illustrated examples are provided to introduce the reader to the overall subject matter discussed herein and are not intended to limit the scope of the disclosed concepts. The following paragraphs describe various additional features and examples with reference to the accompanying drawings, where like symbols represent like elements, and directional descriptions are used to describe the illustrated embodiments, but like the illustrated embodiments, should not be used to limit the present disclosure. The elements included in the drawings may not be drawn to scale.

[0043] According to some examples of the present disclosure, Figure 11 is a schematic diagram depicting a computing environment 100 implementing a modular firmware component. Computing device 102 may be any suitable computing device, such as a personal computer, server, or other device. Computing device 102 may include a main processor 104 and, optionally, an independent processor 106. Main processor 104 may be any suitable processor, such as a CPU, or one or more cores of a CPU. Independent processor 106, when used, may be a microcontroller (e.g., a microcontroller built for a specific purpose), a processor separate from the CPU, or a core of a CPU, such as a secure core, such as a platform security processor implemented through a trusted execution environment. Computing device 102 may optionally include a management controller 158, such as a baseboard management controller (BMC). Computing device 102 may include local storage 108, across one or more storage devices, such as read-only memory, random access memory, and similar storage devices. Computing device 102 may include additional components, such as various additional hardware components, buses, peripherals, and the like.

[0044] When the computing device 102 is booted, certain firmware modules from a firmware package 116 stored in the local storage device 108 of the computing device 102 may be executed. The firmware package 116 includes platform-specific firmware 152, which is specific to the computing device 102 itself or to certain hardware components of the computing device 102. The execution of the platform-specific firmware 152 may enable the main processor 104 and / or the independent processor 106 to use certain components of the computing device 102, such as certain storage components, power components, or network components.

[0045] After executing the platform-specific firmware 152, the main processor 104 or the independent processor 106 may identify one or more additional modules to execute based on the module list in the platform-specific firmware 152. The module list may include selected modules of the module library 138. The module library 138 may be implemented locally, remotely, or a combination of local and remote. When implemented locally, the module library 138 may only include the module library component 178. The module library component 178 may be stored in the local storage 108, such as part of the firmware package 116. When implemented remotely, the module library 138 may only include the module library component 118, which is stored on the remote storage device 112 (such as a firmware server or a network addressable storage device). When implemented locally and remotely, the module library 138 may include both the module library component 178 and the module library component 118.

[0046] When at least some of the module repositories 138 are implemented remotely, the host processor 104 or the independent processor 106 can use a network interface 180 (e.g., a wired or wireless network interface) to access the remote storage device 112 via a network 110 (e.g., a local area network (LAN), a wide area network (WAN), a cloud network, or the Internet). When at least some of the module repositories 138 are implemented remotely, the host processor 104 or the independent processor 106 can search for a module in one location before searching another location. For example, when searching for a given module GUID, the module repositories component 178 can be searched before the module repositories component 118. Other orders can be used first, as well as predetermined orders.

[0047] like Figure 1 As depicted in FIG. 1 , computing environment 100 may include second computing device 114. Second computing device 114 may be the same as computing device 102, or may be similar to computing device 102, but with a different firmware suite 120. For purposes of illustration only, components of second computing device 114 are not depicted. Firmware suite 120 may include module library component 139, which is identical to module library component 178. Similarly, in the case where module library 138 is implemented in a combination of local and remote locations, module library 138 may be similarly defined as a combination of module library component 139 and module library component 118. At least some of the platform-specific firmware 153 of second computing device 114 is different from the platform-specific firmware 152 of computing device 102.

[0048] In one example, computing device 102 and second computing device 114 may both be the same device with the same hardware. The platform-specific firmware 152 and platform-specific firmware 153 of computing device 102 and second computing device 114, respectively, may be nearly identical, with the same code for initializing multiple components (e.g., hardware) that are used to read their respective module lists. In this example, only the module lists are different between platform-specific firmware 152 and platform-specific firmware 153. Therefore, when computing device 102 boots up, computing device 102 will execute firmware associated with the module list in its platform-specific firmware 152, thereby executing a specific set of firmware modules from module library 138 (e.g., from module library component 178). When second computing device 114 boots up, second computing device 114 will execute firmware associated with the module list in its platform-specific firmware 152, thereby executing a different set of firmware modules from module library 138 (e.g., from module library component 139). As such, the computing device 102 and the second computing device 114 may have different capabilities, states, or uses from each other.

[0049] In some cases, the second computing device 114 is a very different device from the computing device 102. For example, the computing device 102 may be a storage area network (SAN) storage device, and the second computing device 114 may be an application server. The hardware and specification requirements and applications used in the computing device 102 and the second computing device 114 may be different. However, the firmware suite 116 and the firmware suite 120 provided to each device may be nearly identical, with identical module library components 178 and module library components 139, but different platform-specific firmware 152 and platform-specific firmware 153. Due to the differences in platform-specific firmware 152 and platform-specific firmware 153, the computing device 102 and the second computing device 114 are able to properly initialize their respective hardware to read their respective module lists and then execute their respective selected modules from the module library 138. In this way, the computing device 102 can be properly initialized for use as a storage area network storage device, and the second computing device 114 can be properly initialized for use as an application server.

[0050] When any module in the module library 138 needs to be updated, such updates can be pushed out as a single module, or can be included in new firmware packages 116 and firmware packages 120, or can be automatically updated on the remote storage device 112. When it is desired to change the specific modules or settings used in the firmware of the computing device 102, the module list or other settings (e.g., configuration parameters) of the platform-specific firmware 152 can be updated.

[0051] In some cases, the computing environment 100 may include a management computing device 160. The management computing device 160 may be coupled to the network 110 to communicate with the computing device 102 to manage its firmware. The management computing device 160 may be used to make adjustments to the platform-specific firmware 152 (e.g., to change the module list, or to change configuration parameters or other settings), or to update some or all of the module library components 178, or to replace the firmware suite 116 entirely. The management computing device 160 may interact with the management controller 158 in the computing device 102, but this is not always necessary.

[0052] According to some examples of the present disclosure, Figure 2 2 is a schematic diagram depicting an initial firmware package 216 and an executable firmware package 240. The firmware package 216 may be any suitable firmware package, such as Figure 1 Firmware Suite 116. Figure 2, the entire module library 238 is shown as part of the firmware 216, however, this is not always necessary. In other cases, some or all of the module library 238 is located in a remote storage device, such as Figure 1 The remote storage device 112.

[0053] The firmware suite 216 includes platform specific firmware 252 and module library 238. The platform specific firmware 252 includes a primary module 222 and a secondary module 224. The primary module 222 includes a computing device (e.g. Figure 1 The main processor 104 or the independent processor 106 of the computing device 102 can execute basic code to initialize certain components (e.g., hardware) thereof, wherein the plurality of components (e.g., hardware) are used to access the secondary module 224, access the module library 238, and / or perform any other tasks required to access and execute a specific module from the module library 238.

[0054] The secondary modules 224 may include a module list 282 and optionally configuration parameters 256. The secondary modules 224 may be stored in a writable memory such as NVRAM, however this is not always necessary.

[0055] Module list 282 is a list of selected modules to be used in the boot process of a given computing device. In some cases, module list 282 is complete, but this is not always necessary because in some cases, other dependent modules can be automatically implemented without being included in module list 282 itself. Figure 2 , module list 282 identifies module A and module C to be included in firmware package 240. Although module list 282 is depicted as "A" and "C," module list 282 may include the GUIDs of the modules to be implemented. For example, rather than using "C" to indicate that module C 230 is to be implemented, module list 282 may include the GUID of module C 230 (e.g., B516efee-2a80-4c10-a976-ff453d6c4bf1, described in further detail herein). Modules may be organized in other ways. In addition, module list 282 may include additional information, such as alternative modules to use if available (e.g., alternative versions of a given module), comments, and other information.

[0056] Configuration parameters 256 may include variables or other settings used during the boot process. These parameters may be used to interpret module list 282 (e.g., to help identify which version of a given module to use), assemble firmware package 240, or execute one or more modules 227, modules 233, and modules 231 of firmware package 240. Configuration parameters 256 may be global parameters that are used continuously during the boot process, or global parameters that are used continuously during at least the execution of firmware package 240.

[0057] The module library 238 may include any number of modules, such as Figure 2 226 through module n 236 as depicted in FIG. 226. Module A 226, module B 228, module C 230, module D 232, module E 234, and module n 236 may be stored together, however this is not always necessary. Each module A 226, module B 228, module C 230, module D 232, module E 234, and module n 236 of module library 238 may be different. In some cases, multiple modules of module library 238 may implement similar functions (e.g., initializing the same portion of firmware), but implemented in different ways or with different results. In some cases, multiple modules of module library 238 may be used to achieve the same result, but may do so in different ways using different hardware.

[0058] For purposes of illustration, module C 230 is described in greater detail, however any other modules 226, 228, 232, 234, 236 of the module library 238 may include similar elements. Module C 230 may include module attributes 242 and module code 254. The module code 254 is the actual code that is implemented as part of the firmware package 240. The module attributes 242 may include a module GUID 244 and dependency information, such as a parent dependency GUID 246 and a child dependency GUID 248. For purposes of illustration, a full GUID (e.g., "B516efee-2a80-4c10-a976-ff453d6c4bf1") is depicted for the module GUID 244, but abbreviated versions of the GUID (e.g., "D", "A", "E") are depicted in the parent dependency GUID 246 and the child dependency GUID 248.

[0059] When assembling the firmware package 240, the module attributes 242 of each module in the module list 282 can be accessed to identify any potential dependency information. By using this dependency information, it can be determined whether any additional modules in the firmware package 240 must be used, and the order in which they are used.

[0060] exist Figure 2In the example depicted in FIG, the module list 282 in the secondary module 224 indicates that module A 226 and module C 230 are to be used. When the module properties 242 of module C 230 are accessed, it can be seen that module D 232 and module A 226 are both listed in the segment of the parent dependency GUID 246. Therefore, when assembling the firmware package 240, module A 226 and module D 232 are included and included before module C 230. More specifically, since module A 226 is already included in the module list 282, the dependency information will be used to ensure that module A 226 is included before module C 230 because module A 226 is the parent module of module C 230. However, module D 232 is not in the module list 282, so it will be newly included and included before module C 230.

[0061] In this example, module E 234 is listed in the sub-dependency GUID 248 segment of module C 230. In some cases, this sub-module will be automatically included in the firmware package 240 at a location after module C 231, but this is not always necessary. In some cases, if the module list 282 also includes this sub-module (such as module E 234), the sub-module will only be included in the firmware package 240, in which case the sub-module will be included after module C 231.

[0062] Whenever a module is added that is not on the module list 282 (e.g., module D 232), the module properties 242 of that module will be accessed to determine if there is any dependency information. If there is dependency information, that dependency information will be used to add additional modules and / or deploy the given modules into the correct order in the firmware package.

[0063] For illustration purposes, the firmware package 240 is depicted as a set of modules 227, modules 223, and modules 231. The firmware package 240 is composed of platform specific firmware 252 and module library 238. For illustration purposes, within the firmware package 240 itself, module A 226 is represented by module A 227, module D 232 is represented by module D 233, and module C 230 is represented by module C 231. Figure 2The modules 227, 233, and 231 depicted in the figure may be (i) copies of their respective modules 226, 232, and 230; (ii) copies of the module codes 254 of their respective modules 226, 232, and 230; (iii) pointers to their respective modules 226, 232, and 230, or GUIDs of their respective modules 226, 232, and 230; or (iv) pointers to the module codes 254 of their respective modules 226, 232, and 230.

[0064] Thus, in some cases, firmware package 240 may be an actual document containing code that is executed during the boot process. In some cases, firmware package 240 may be a document of a sequence of modules indicating which modules are to be accessed and executed. In such cases, firmware package 240 may be composed prior to execution, although this is not always necessary. In some cases, firmware package 240 may be an abstraction representative of the order in which the modules are to be executed, such as if the processor directly executes the modules during the process of composing firmware 240. In such a case, "composing" firmware package 240 includes sequentially executing each module to be executed.

[0065] According to some examples of the present disclosure, Figure 3 3 is a schematic diagram illustrating a general module library 338 used on a plurality of computing devices 360, 364, and 368. Module library 338 may be any suitable module library, such as Figure 2 Module library 238. Module library 338 may be part of firmware package 316 and may be stored together with platform-specific firmware 352 (e.g., continuously, either locally), or remotely. Module library 338 includes a plurality of modules, such as module 326, module 328, module 330, module 332, module 334, and module 336.

[0066] exist Figure 3 In the example of , computing device A 360, computing device B 364, and computing device C 368 each include identical hardware and each have an identical copy of firmware suite 316, including an identical copy of primary module 322, except for differences in their respective secondary modules 324. Secondary modules 324 of computing device A 360 include module list 362, representing module A 326 and module C 330; secondary modules 324 of computing device B 364 include module list 366, representing module A 326 and module E 334; and secondary modules 324 of computing device C 368 include module list 370, representing module B 328 and module C 330.

[0067] During the boot process of computing device A 360, its copy of main module 322 is executed, and then its module list 362 is accessed. Module list 362 represents module A 326 and module C 330. Thus, as if from Figure 2 The firmware package 372 will be composed from the module list 362. The firmware package 372 includes module A 326, module D 332, and module C 330. Although module D 332 is no longer on the module list 362, module D 332 is still added to the firmware package 372 because module D 332 is the parent dependent module of module C. Similarly, since both module A 326 and module D 332 are the parent dependent modules of module C 330, in the firmware package 372, both module A 326 and module D 332 appear before module C 330. The computing device A 360 executes each module of the firmware package 372 to complete its boot process.

[0068] During the boot process of computing device B 364, its copy of main module 322 is executed, and then its module list 366 is accessed. Module list 366 represents module A 326 and module E 334. Therefore, firmware package 374 is formed to include module A 326 and module E 334. In this example, neither module A 326 nor module E 334 includes any module dependencies. Computing device B 364 executes each module of firmware package 374 to complete its boot process.

[0069] During the boot process of computing device C 368, its copy of main module 322 is executed, and then its module list 370 is accessed. Module list 370 indicates module B 328 and module C 330. Therefore, firmware package 376 is composed to include module B 328 and module C 330. In this example, since module A 326 and module A 332 are parent dependencies of module C 330, they are also included in the composition of firmware package 376. In addition, in this example, module B 328 is a child dependency of module D 332. Therefore, since module D 332 and module B 328 are included in firmware package 376, module B 328 is included after module D 332. Computing device C 368 executes each module of firmware package 376 to complete its boot process.

[0070] Small changes to the minor modules 324, module lists 362, module lists 366, and module lists 370 of each computing device A 360, computing device B 364, and computing device C 368, cause each of these computing devices to boot up using different firmware modules. While conventional techniques would require the creation of new firmware images for each of these computing devices A 360, computing device B 364, and computing device C 368, certain examples of the present disclosure allow the use of a single firmware package 316 for all computing devices A 360, computing device B 364, and computing device C 368, with only small changes in the minor modules 324 that can be easily written.

[0071] In addition, if module A 326 needs to be updated (for example, to fix a bug or implement a new feature), the user can update only module A 326, and then provide the update to each computing device A 360, computing device B 364, and computing device C 368 to update module A 326 stored locally in its module library 338, or provide the update to a remote storage device to update module A 326 stored remotely in the module library 338.

[0072] Furthermore, while described in the first example as different computing devices with the same hardware, in the second example, computing device A 360, computing device B 364, and computing device C 368 may be different instances of a single computing device at different times (e.g., at a first time, a second time, and a third time, respectively). In this example, computing device B 364 may be computing device A 360 after updating module list 362 to module list 366 by removing module C 330 and adding module E 334. In this example, when the computing device boots up at the first time using module list 362, it will boot up using firmware package 472. However, after updating module list 362 to module list 366, that same computing device may boot up using firmware package 474 at the second time. Thus, simply by making changes to secondary module 324, a single computing device may be booted up using two different sets of firmware codes.

[0073] Each module 326, module 328, module 330, module 332, module 334, and module 336 may represent a unit of code that may be executed by a computing device during a boot process. In one example, some modules may represent code used to implement a system management specification or protocol, such as the Redfish standard. In this example, module C may represent Redfish version 1.5, and module E may represent Redfish version 1.1. Thus, slight differences in module lists 362 and module lists 366 may cause computing device A 360 and computing device B 364 to boot with different firmware packages 372 and firmware packages 374, respectively, leading to different implementations of the Redfish standard. In some cases, a single module list may list module C 330 as a preferred replacement for module E 334. In this case, module C 330 would be used if possible, but if module C 330 is not available or cannot be used, module E 334 may be used instead.

[0074] In some cases, computing device A 360, computing device B 364, and computing device C 368 may include different hardware. In this case, the firmware packages 372, 374, and 376 of computing device A 360, computing device B 364, and computing device C 368, respectively, may be used to initialize different hardware components. However, in some cases, different hardware may be used to access the secondary module 324, access the module library 338, or execute the firmware packages 372, 374, and 376 of computing device A 360, computing device B 364, and computing device C 368, respectively. In this case, computing device A 360, computing device B 364, and computing device C 368 may each use different primary modules instead of using the same primary module 322. Therefore, different codes in the primary modules of computing device A 360, computing device B 364, and computing device C 368 may be used to initialize their appropriate hardware components.

[0075] According to some examples of the present disclosure, Figure 4 is a flow chart depicting a process 400 for modularizing firmware. The process 400 may be implemented on any suitable computing device, such as Figure 1 The computing device 102.

[0076] At block 402, a firmware image may be accessed. Accessing the firmware image may include accessing a local memory containing the firmware image. Accessing the firmware image may include powering a computing device so that a processor (eg, a main processor or an independent processor) of the computing device accesses and begins executing the firmware image.

[0077] At block 404, a main module of the firmware image is executed. Execution of the main module may include initializing at least one hardware component of the computing device. The at least one hardware component may be a component used to implement one or more of blocks 406, 408, and 410, which are described in further detail below. For example, where the implementation of block 408 requires the use of a network interface, execution of the main module at block 404 may include initialization of the network interface.

[0078] At block 406, a module list may be accessed. The module list may represent a set of selected modules to be used in booting up a computing device implementing process 400. The module list accessed at block 406 may be user-modifiable, such as via a text editor or management interface. In some cases, the module list at block 406 may include one or more preferred alternative modules associated with a given module, although this is not always necessary. In some cases, the module list may be stored in a secondary module of the firmware image accessed at block 402, although this is not always necessary.

[0079] Configuration parameters may be accessed at optional block 424. Configuration parameters may be platform-specific and / or user-modifiable parameters used during process 400, such as during assembly of a firmware package at block 408, and / or during execution of one or more modules at block 420, which is described in further detail below.

[0080] At block 408, a firmware package may be assembled. A firmware package is a list of modules to be executed, a group of modules to be executed, or a representation of modules to be executed during boot-up of a computing device implementing process 400. The firmware package is based on the module list accessed at block 406. Assembling the firmware package at block 408 may include repeatedly stepping through each module of the group of selected modules identified in the module list. In the case where a preferred alternative module represents a given module, the given module may be skipped if the preferred alternative module is identified and used.

[0081] For each module selected from the module list identified in block 406, assembling the firmware package in block 408 may include accessing the module from a module repository in block 410. Accessing the module in block 410 may include placing the module in the module repository, such as using a GUID of the module. In some cases, accessing the module in block 410 may include accessing a module repository component stored on a local storage device in a computing device implementing the process 400. In some cases, accessing the module in block 410 may include accessing a module repository component stored on a remote storage device that is accessible via a network interface of the computing device implementing the process 400.

[0082] In some cases, assembling the firmware package at block 408 includes accessing dependency information for a given module (e.g., each module accessed at block 410) at block 412. Each module may include module dependency information that indicates a chain of dependencies or dependency relationships between the given module and one or more other modules. Accessing the module dependency information may include accessing parent dependency information (e.g., one or more parent dependency GUIDs) and / or accessing child dependency information (e.g., one or more child dependency GUIDs).

[0083] In some cases, the dependency information may be used at block 414 to arrange the modules of the module list (e.g., the set of selected modules) into a module sequence. Arranging the modules into the module sequence may include arranging the modules so that in the module sequence, each module appears after any of its parent dependent modules and before any of its child dependent modules. Thus, when the firmware package is executed at block 420, any parent module may be executed before modules that require the parent dependent module are executed.

[0084] In some cases, at block 416, the module dependency information may be used to identify additional modules to be added to the firmware package. In some cases, a parent or child dependency module may be indicated as optional or required, however this is not always necessary. In some cases, it may be assumed that any parent or child dependency module listed is required. When a required dependency module (e.g., a parent or child dependency module) is listed in the dependency information of a given module, but is not listed in the set of selected modules from the module list, forming the firmware package at block 408 may include adding the required dependency module to the firmware package at block 416 (e.g., adding the required dependency module to the module sequence in the correct order, such as with reference to block 414). Adding the required dependency module may include implementing all instances of block 408 on that module as if it were originally included in the module list, such as with reference to that module to implement blocks 410, 412, 414, and 416.

[0085] In some cases, such as when a single processor (e.g., a host processor) is used to implement the process 400, the firmware package may be organized as a sequence or set of modules at block 408. The firmware package may be executed at block 420. Execution of the firmware package may include executing each module of the firmware package organized at block 408, including each of the selected modules from the module list at block 106, and any additional modules added at block 416.

[0086] In some cases, such as when multiple processors are used to implement the process 400, assembling the firmware package at block 408 may include copying the given module to the system memory at block 418. In such cases, certain instances of the process 400 may be executed by an independent processor, leaving execution of the firmware package to the main processor at block 420. In such cases, assembling the firmware package at block 408 may be performed by the independent processor and may include copying the given module to the system memory at block 418. Copying the given module may include copying each module to be executed as part of the firmware package at block 408, including each of the selected modules from the module list at block 406, and any additional modules added at block 416. In some cases, copying the module may include using the module sequence of block 414 to copy the module in the order of the module sequence. In some cases, the module sequence of block 414 may be separately stored in a table accessible to the main processor (e.g., stored in the system memory). In some cases, copying the module to system memory at block 418 may include storing the memory settings in a table accessible to the host processor (eg, a table containing a sequence of modules, or another table stored in system memory).

[0087] When multiple processors are used, after the firmware package is assembled at block 408, the independent processor may transfer control to the main processor. At block 420, the main processor may then execute the firmware package. In this case, executing the firmware package may include accessing the firmware package stored in the system memory. In some cases, the main processor may further access other information, such as a table containing module sequences and / or memory settings, which can be used by the main processor to access and execute the firmware package.

[0088] In the case where configuration parameters are accessed at block 424 , the configuration parameters may be passed to one or more (eg, one, some, or all) modules executed at block 420 during execution of a given module.

[0089] After the firmware package has been executed at block 420, the computing device can optionally enter the operating system at block 422. In some cases, the modules executed at block 420 can assist or trigger the loading of the operating system.

[0090] Although the blocks of process 400 are depicted in a particular order, in some cases, the blocks of process 400 may occur in a different order, optionally including additional blocks and / or fewer blocks. In one example, in some cases when using an independent processor, accessing the module list at block 406 and assembling the firmware package at block 408 may occur before the main module is executed at block 404. In this case, when the independent processor has completed copying each module of the set of selected modules to system memory at block 418, the independent processor may transfer control to the main processor, which may then execute the main module at block 404 before executing the firmware package at block 420.

[0091] Figure 5 is to implement certain features and procedures of the present disclosure (such as reference Figure 4 The system architecture 500 may be used to implement a server, a user device, a computing device (e.g., Figure 1 The system architecture 500 may be implemented on any electronic device running a software application derived from compiled instructions, including but not limited to personal computers, servers, smart phones, electronic tablets, game consoles, email devices, and similar devices. In some implementations, the system architecture 500 may include one or more processors 502 (e.g., a main processor and optional independent processors), one or more input devices 504, one or more display devices 506, one or more network interfaces 508, and one or more computer-readable media. Each of these components may be coupled by a bus 512.

[0092] Display device 506 may be any known display technology, including but not limited to a display device using Liquid Crystal Display (LCD) or Light Emitting Diode (LED) technology. Processor 502 may use any known processor technology, including but not limited to a graphics processor and a multi-core processor. Input device 504 may be any known input device technology, including but not limited to a keyboard (including a virtual keyboard), a mouse, a trackball, and a touch-sensitive pad, or a display. In some cases, a voice input may be used to provide a voice signal, such as a voice signal of a person speaking. The bus 512 may be any known internal or external bus technology, including but not limited to industry standard architecture (ISA), extended industry standard architecture (EISA), peripheral component interconnect (PCI), peripheral component interconnect express (PCI Express), NoBus, universal serial bus (USB), serial advanced technology attachment (Serial ATA), or FireWire.

[0093] Computer readable medium 510 may be any medium that participates in providing instructions to processor 502 for execution, including but not limited to non-volatile storage media (e.g., optical disks, magnetic disks, flash drives, etc.) or volatile media (e.g., synchronous dynamic random access memory (SDRAM), read-only memory (ROM), etc.). For example, computer readable medium 510 (e.g., storage devices, media, and memory) may include cables, or wireless signals containing bit streams, and other similar media. However, when referred to, non-transitory computer readable storage media explicitly excludes media such as energy, carrier signals, electromagnetic waves, and signals themselves.

[0094] The computer-readable medium 510 may include various instructions to implement an operating system 514, and application programs 520, such as computer programs. The operating system 514 may be a multi-user, multiprocessing, multitasking, multithreading, real-time, and similar operating system. The operating system 514 performs basic tasks, including but not limited to: recognizing input from the input device 504; sending output to the display device 506; recording files or directories on the computer-readable medium 510; controlling peripheral devices (such as storage disks, interface devices, etc.) that can be directly controlled by the I / O controller; and managing traffic on the bus 512. The computer-readable medium 510 may include various instructions to implement a firmware program, such as a BIOS. In some cases, the computer-readable medium 510 may include a firmware suite, which includes a primary module, a secondary module, and any number of additional modules in a module library (such as Figure 2 The computer readable medium 510 may include various instructions to implement any of the procedures described herein, including but not limited to at least Figure 4 of procedure 400.

[0095] Memory 518 may include high-speed random access memory and / or non-volatile memory, such as one or more magnetic disk storage devices, one or more optical storage devices, and / or flash memory (e.g., NAND, NOR). Memory 518 (e.g., computer-readable storage devices, media, and memory) may include cables, or wireless signals containing bit streams, and similar media. However, when referred to, non-transitory computer-readable storage media explicitly excludes media such as energy, carrier signals, electromagnetic waves, and signals themselves. Memory 518 may be stored on an operating system such as Darwin, RTXC, LINUX, UNIX, OSX, WINDOWS, or an embedded operating system such as VxWorks. In some cases, examples of firmware suites according to certain examples of the present disclosure may be stored in memory 518.

[0096] The system controller 522 may be a service processor that operates independently of the processor 502. In some implementations, the system controller 522 may be a baseboard management controller (BMC).

[0097] Certain examples and features of the present disclosure may be advantageously implemented in one or more computer programs executable on a programmable system comprising at least one programmable processor coupled to receive data and instructions from and transmit data and instructions to a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that may be used, directly or indirectly, in a computing device to perform certain activities or cause certain results. A computer program may be written in any form of programming language (e.g., Objective C, Java), including compiled or interpreted languages, and may be deployed in any form, including as a standalone program, or as a module, component, subroutine, or other unit suitable for a computing environment.

[0098] Processors suitable for executing program instructions include, for example, both general purpose microprocessors and special purpose microprocessors, as well as a single processor or one of multiple processors or cores of any type of computing device. Generally, a processor receives instructions and data from a read-only memory or a random access memory or both. The essential elements of a computing device are a processor to execute instructions and one or more memories to store instructions and data. Generally, a computing device also includes one or more mass storage devices to store data files. Such devices include disks, such as internal hard disks and removable disks, magneto-optical disks, and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including, for example, semiconductor memory devices such as erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by or incorporated into an application specific integrated circuit (ASIC).

[0099] To provide interaction with a user, features may be implemented on a computing device having a display device, such as a cathode ray tube (CRT) or LCD screen, and a keyboard and pointing device to display information to the user, such as a mouse or trackball to allow the user to provide input to the computing device.

[0100] Certain examples of the present disclosure may be implemented in a computer system that includes back-end components (such as a data server), middleware components (such as an application server or an Internet server), front-end components (such as a client computing device with a graphical user interface or an Internet browser), or any combination thereof. The components of the system may be connected by any form or medium of digital data communication, such as a communication network. Examples of communication networks include, for example, a local area network (LAN), a wide area network (WAN), and the computers and networks that form the Internet.

[0101] A computing system may include clients and servers. A client and server are generally remote to each other and typically interact through a network. The relationship of client and server is established by computer programs running on the respective computers and having a client and server relationship to each other.

[0102] One or more features or steps of the disclosed embodiments may be implemented using an application programming interface (API). An API may define one or more parameters that are passed between a calling application and other software code (e.g., an operating system, a library routine, a function) that provides a service, provides data, or performs an operation or calculation. An API may be implemented as one or more calls in program code that send or receive parameters through a parameter list or other structure based on conventions defined in an API specification document. A parameter may be a constant, a key, a data structure, an object, an object class, a variable, a data type, a pointer, an array, a list, or another call. API calls and parameters may be implemented in any programming language. A programming language may define the vocabulary and calling conventions that a programmer may use to access API-supported functionality. In some implementations, an API call may report back to the application the capabilities of the device running the application, such as input capabilities, output capabilities, processing capabilities, power capabilities, communication capabilities, and the like.

[0103] The above description of the embodiments, including the illustrated embodiments, is presented only for the purpose of illustration and description, and is not intended to be exhaustive or limited to the exact form disclosed. For those of ordinary skill in the art, many modifications, adaptations and uses thereof will be apparent. Without departing from the spirit or scope of the present invention, many changes may be made to the disclosed embodiments according to the disclosure herein. Therefore, the breadth and scope of the present invention should not be limited to any of the above-described embodiments.

[0104] Although the present invention has been illustrated and described with reference to one or more implementations, equivalent alternatives and modifications will occur to or be known to those skilled in the art upon reading and understanding this specification and the accompanying drawings. In addition, although a particular feature of the present invention may have been disclosed with reference to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired or advantageous for any given particular application.

[0105] The terms used herein are for the purpose of describing specific embodiments only and are not intended to limit the present invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms, unless the context clearly indicates otherwise. In addition, if the words "including," "having," "with," or variations thereof, are used in the embodiments and / or claims, such words are intended to be included in a manner similar to the word "comprising."

[0106] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by a person of ordinary skill in the art. In addition, terms such as those defined in commonly used dictionaries should be interpreted as having the same meaning as they are in the context of the relevant technology, and unless explicitly defined as such herein, the multiple terms will not be interpreted as idealized or overly formal concepts.

[0107] [Explanation of symbols]

[0108] 100: Computing Environment

[0109] 102: Computing Devices

[0110] 104: Processor

[0111] 106: Independent processor

[0112] 108: Local storage device

[0113] 110: Network

[0114] 112: Remote storage device

[0115] 114: Second computing device

[0116] 116: Firmware Suite

[0117] 118: Module library components

[0118] 120: Firmware Kit

[0119] 138: Module Library

[0120] 139: Module Library Components

[0121] 152: Platform Specific Firmware

[0122] 153: Platform Specific Firmware

[0123] 158: Management Controller

[0124] 160: Manage computing devices

[0125] 178: Module library components

[0126] 180: Network interface

[0127] 216: Firmware Suite

[0128] 222: Main modules

[0129] 224: Minor modules

[0130] 226: Module A

[0131] 227: Module A (copy)

[0132] 228: Module B

[0133] 230: Module C

[0134] 231: Module C (copy)

[0135] 232: Module D

[0136] 233: Module D (copy)

[0137] 234: Module E

[0138] 236: Module n

[0139] 238: Module Library

[0140] 240: Firmware package

[0141] 242: Module attributes

[0142] 244: Module GUID

[0143] 246: Parent dependency GUID

[0144] 248: Sub-dependency GUID

[0145] 252: Platform specific firmware

[0146] 254: Module code

[0147] 256: Configuration parameters

[0148] 282: Module List

[0149] 316: Firmware Suite

[0150] 322: Main modules

[0151] 324: Minor modules

[0152] 326: Module A

[0153] 328: Module B

[0154] 330: Module C

[0155] 332: Module D

[0156] 334: Module E

[0157] 336: Module n

[0158] 338: Module Library

[0159] 352: Platform Specific Firmware

[0160] 360: Computing Device A

[0161] 362: Module list

[0162] 364: Computing Device B

[0163] 366: Module List

[0164] 368: Computing Device C

[0165] 370: Module List

[0166] 372,374,376: Module packages

[0167] 400: Program

[0168] 402-424: Block

[0169] 500: System Architecture

[0170] 502: Processor

[0171] 504: Input device

[0172] 506: Display device

[0173] 508: Network interface

[0174] 510: Computer readable media

[0175] 512: Bus

[0176] 514: Operating System

[0177] 518: Memory

[0178] 520: Applications

[0179] 522: System Controller

Claims

1. A method for composing modular firmware, comprising: accessing, during each boot-up of a computing device, a firmware image from a local storage device of the computing device, the firmware image comprising a main module, a module list, and a module library in a single file, the computing device comprising a main processor and an independent platform security processor; executing the main module by the independent platform security processor, wherein executing the main module includes initializing one or more hardware resources of the computing device; Accessing, by the independent platform security processor, during each boot-up of the computing device, the module list associated with the firmware image, wherein the module list includes unique identification information associated with a set of selected modules of the module library, wherein the module library includes a plurality of executable modules, the module library includes the set of selected modules and one or more unselected modules, the set of selected modules and the one or more unselected modules being part of a single file of the firmware image; composing, by the independent platform security processor, a firmware package based on the set of selected modules during each boot of the computing device, wherein composing the firmware package includes accessing each module of the set of selected modules; accessing, by the independent platform security processor, a plurality of configuration parameters from the firmware image and storing the plurality of configuration parameters in a system memory, the plurality of configuration parameters including an indication of a module firmware version to be used; storing, by the independent platform security processor, a module sequence in the system memory, wherein the module sequence indicates an order in which modules of the firmware package are executed; as well as The firmware package is executed by the main processor and the computing device is started, wherein executing the firmware package further includes executing each module of the firmware package in the order indicated by the module sequence, and wherein executing the firmware package further includes selecting a version from multiple available versions for at least one module of the firmware package using the multiple configuration parameters.

2. The method according to claim 1, wherein forming the firmware package further comprises: accessing dependency information associated with at least one module of the set of selected modules; using the dependency information to identify an additional module, wherein the additional module is not included in the set of selected modules; and Add the additional module to the firmware package.

3. The method according to claim 1, wherein forming the firmware package further comprises: accessing dependency information associated with at least one module of the set of selected modules, wherein the dependency information identifies a parent module and a child module; as well as The module sequence is generated using the dependency information, wherein generating the module sequence includes deploying the parent module in the module sequence before the child module.

4. The method according to claim 1, wherein forming the firmware package further comprises copying each module of the set of selected modules into a system memory accessible to the host processor; and Wherein executing the firmware package includes accessing the firmware package from the system memory.

5. The method according to claim 1, further comprising: updating the module list to generate an updated module list having a set of updated selected modules, wherein the set of updated selected modules is different from the set of selected modules; restarting the computing device; Based on the set of updated selected modules, forming an updated firmware package; as well as Execute the updated firmware package.

6. A computer program product, tangibly embodied in one or more non-transitory machine-readable storage media, comprising a plurality of instructions configured to cause one or more processors to implement the method of claim 1.

7. A computing device comprising modular firmware, comprising: A first hardware device and a second hardware device; Main processor; Independent platform security processor; as well as One or more non-transitory computer-readable storage media including first instructions and second instructions, Wherein, when the first instruction is executed on the independent platform security processor, the independent platform security processor is caused to perform a first operation, including: During each boot of the computing device, accessing a firmware image, the firmware image including a main module, a module list, and a module library in a single file; Executing the main module, wherein executing the main module includes initializing the first hardware device; During each boot of the computing device, accessing the module list associated with the firmware image, wherein the module list includes unique identification information associated with a set of selected modules of the module library, wherein the module library includes a plurality of executable modules, the module library includes the set of selected modules and one or more unselected modules, the set of selected modules and the one or more unselected modules being part of a single file of the firmware image; composing a firmware package based on the set of selected modules during each boot of the computing device, wherein composing the firmware package includes accessing each module of the set of selected modules; accessing a plurality of configuration parameters from the firmware image and storing the plurality of configuration parameters in a system memory, the plurality of configuration parameters including an indication of a module firmware version to use; storing a module sequence in the system memory, wherein the module sequence indicates an order in which modules of the firmware package are executed; and Wherein, when the second instruction is executed on the main processor, the main processor is caused to perform a second operation, including: Executing the firmware package and starting the computing device, wherein executing the firmware package includes initializing the second hardware device, wherein executing the firmware package further includes executing each module of the firmware package in an order indicated by the module sequence, and wherein executing the firmware package further includes selecting a version from a plurality of available versions for at least one module of the firmware package using the plurality of configuration parameters.

8. The computing device of claim 7, further comprising a network interface, wherein accessing each module of the set of selected modules comprises accessing at least one module of the set of selected modules from a remote storage device via the network interface.

9. The computing device according to claim 7, wherein forming the firmware package further comprises copying each module of the set of selected modules into a system memory accessible to the host processor; and Wherein executing the firmware package includes accessing the firmware package from the system memory.

Images