BACKGROUND

[0001 ] A computing system may include several components, which are controlled via firmware, a type of software that provides control, monitoring and data manipulation of the components of the computing system. The firmware may be held in non-volatile memory. A user of the computing system may update the firmware.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The following detailed description references the drawings, wherein:

[0003] FIG. 1 is a conceptual diagram of an example of a firmware package hierarchy;

[0004] FIG. 2 is a conceptual diagram of an example of a firmware package hierarchy and corresponding computing devices;

[0005] FIG. 3 is a flowchart of an example method for storing firmware of a computing system;

[0006] FIG. 4 is a block diagram of an example system for managing firmware of a computing system.

DETAILED DESCRIPTION

[0007] Computing systems include many different devices. Such devices may include: field programmable gate arrays, microcontrollers, management hardware, embedded devices, unified extensible firmware interface (UEFI), and other configuration code. The firmware may be stored on non-volatile memory, such as electrically erasable programmable read-only memory (EEPROM), flash memory, or the like. [0008] Traditionally, firmware updates for a computing system have been managed in monolithic binary "blobs." A user may download or obtain the blob file that contains firmware updates for every component of a computing system having a firmware update. Finer-grained control over individual firmware updates is not generally available.

[0009] The techniques of this disclosure introduce fine-grained, hierarchical binary packages of firmware updates. The package hierarchy may have a treelike structure, with a single package at the root of the tree. Below the root level of the package, there may be nested level of packages of firmware updates. Each package of the firmware hierarchy may correspond to one or more hardware and/or software component of the computing system.

[0010] According to this disclosure, each package of firmware updates may comprise a binary file system that is mountable at a directory as a file system by an operating system. The file system, when mounted, includes tools for updating (e.g., flashing) firmware, binary firmware files, and/or configuration files. An operating system may execute a package management system to handle updating, installing, configuring, versioning, dependency management, checksumming, and verification of the firmware packages.

[001 1 ] FIG. 1 is a conceptual diagram of an example firmware package hierarchy. FIG. 1 includes a package hierarchy 100, which includes a firmware image 102. Firmware image 102 further includes firmware image 1 10. Package hierarchy 100 may further include nested firmware packages 104, 106. Nested firmware package 104 may be included within firmware image 1 10. Nested firmware package may further include nested firmware package 106, and nested firmware image 108. Each of firmware image 1 10 and nested firmware image 108 may comprise mountable file systems that are mountable by operating system 120 at mount point 122 as file systems.

[0012] Although firmware package hierarchy 100 is illustrated as having three levels, any number of levels is possible within the firmware package hierarchy. For example, nested firmware image 108 may further comprise any number of additional nested firmware packages and/or nested firmware images. [0013] In the example of FIG. 1 , operating system 120 may execute a package management system to determine the structure of hierarchy 100. In some examples, a user may execute the package management system, which may download via the internet, and store a repository of packages that includes some or all of the packages of package hierarchy 100. In other examples, a user may supply physical media to a computing system which includes a repository of packages that further include package hierarchy 100.

[0014] Responsive to storing package hierarchy 100, a user may select one or more packages to install from package hierarchy 100 using the package management system. In various examples, the package management system may comprise a software package management system, such as Red Hat package management system (RPM), tgz (tar and gzip), Debian package management system (dpkg), python eggs, Synaptic package management system, or the like. Such package management systems provide for checksumming, versioning, install verification, and dependency management, as will be described in greater detail below.

[0015] In accordance with the techniques of this disclosure, system 100 may comprise a package of firmware updates that includes an optionally nested package of firmware updates. The package of firmware updates and the nested package of firmware updates comprise binary images that are mountable as file systems at a mount point of an operating system.

[0016] FIG. 2 is an example of a package hierarchy and corresponding computing devices. FIG. 2 includes a firmware package hierarchy 200. Package hierarchy includes firmware image package 102, nested firmware packages 104, 106, and nested firmware image 108. Firmware image 210 may include the contents of nested firmware packages 104, 106, and nested firmware image 108, in various examples. Firmware package 102 further includes firmware image 210. FIG. 2 further includes package management system 224, which may manage the installation, verification, checksumming, and/or delta encoding of firmware package hierarchy 200. Operating system 120 may execute package management system 224. [0017] In addition to package management system 224, various firmware packages, e.g. firmware image 210, and nested firmware image 108, may each include their own package management systems, e.g. package management system 210, and 214. Package management systems 212, 214, included in each firmware package or firmware image may be the same or different from each other. Each package management system included within a firmware package or firmware image may be particular to one or more devices or components with which the package management is associated. In this manner, the nested package management systems (e.g., 212, 214) may enable component-specific control over firmware updates. Additionally, there may be different user permissions associated with package management systems 212, 214, and 224. The different permissions may allow superusers to control certain firmware updates, while allowing non-superusers (e.g., regular users) to control other firmware updates.

[0018] Each of firmware package 102, nested firmware package 104, 106, and 108 are associated with a particular software and/or hardware device or component in FIG. 2 or multiple devices or components. The device or component associated with each firmware package or firmware image is illustrated using a dashed line. It should be understood that the device or component illustrated as being associated with each firmware package or image is for the purpose of example, and any device or component may be associated with any level, package, or image within package hierarchy 200.

[0019] In the example of FIG. 2, firmware image 210 may be associated with embedded hardware device(s) 202. Additionally, nested firmware package 104 may be associated with management hardware controller (MHC) 204, e.g., a baseboard management controller (BMC), and may include utilities for updating the same. Nested firmware package 106 is associated with field programmable gate array (FPGA) 206, and nested firmware image 108 is associated with microcontroller 208.

[0020] Responsive to selecting a package to install, package management system 224 package management system 212, and/or package management system 210 may copy the package to a local directory, and mount the file system of the firmware image at a specific directory of the file system. For example, the package management system may store firmware image 210, and nested firmware packages 104, 106, at /opt/images, and may mount the file system, i.e. a firmware image, of nested firmware package 104 at /usr/local/, or another directory in various examples. To mount nested firmware package 104, package management system 224 and/or another package management system may update a file system table, e.g. the /etc/fstab file of a Unix system. By mounting a firmware image at a mount point, e.g. mount point 122, a package management system may install the contents of a firmware update without having to reboot the computing system.

[0021 ] The mounted file systems of nested firmware packages 104, 106, 108 (i.e. the mounted firmware images) may be located in a directory below mount point 122 of firmware image 210. Responsive to mounting the file systems associated with firmware image 210, and nested firmware packages 104, 106, certain devices, e.g. FPGA 206, may have to be disabled for a firmware update to proceed. In some cases, a restart may be used to install the firmware update 206. At power-on, the computing system, e.g. operating system 120 may detect that a different version of nested firmware package 106 at the mount point associated with nested firmware package 106, and install (e.g., flash) the firmware stored from the file system to FPGA 206 using the utilities included within nested firmware package 106.

[0022] In addition to performing the firmware updates, package management system 224 may also provide other functionality. For example, package management system 224 may calculate a checksum based on the contents of firmware image 210. Package management system 224 may determine whether the checksum matches a pre-computed checksum associated with the package to ensure that a particular version of a package is installed when updating a dependent firmware package. Additionally, package management system 224 or another package management system may periodically compare the checksums to ensure that a firmware package has not been modified by malware, for example. [0023] Package management system 224 may also enable a user to quickly and easily switch between different versions of a firmware package, e.g. firmware nested firmware package 104. As an example, a user may issue an input or a command to install a different firmware version, and thereby to replace a previously-installed version of firmware nested firmware package 104. Responsive to the user input or command, package management system 224 may unmount a previously-installed version of nested firmware package 104, and may mount a different version of a firmware image contained within nested firmware package 104. A binary tool of firmware nested firmware package 104 may execute to replace the previously-installed version of firmware nested firmware package 104 with the different version of nested firmware package 104.

[0024] In various example, package management system 224, 212, or 214 may also perform dependency management for firmware packages. For example, there may be different versions of a particular package or nested firmware package, e.g. nested firmware package 104. One of the versions may depend on having a specific version of another package, referred to as a "dependency." For example, nested firmware package 104 may depend on a particular version of nested firmware package 106 or firmware image 210 or vice versa. A user may select a version of nested firmware package 104 to install that depends on particular versions of nested firmware package 106 and image 210. Package management system 224 may obtain the correct version of nested firmware package 106 and image 210, and may install the version of nested firmware package 106 and image 210 upon which nested firmware package 104 depends.

[0025] Package management system 224 may also enable fine-grained control over user permissions in order to restrict which components of a computing system that an ordinary user may install. For example, the computing system of FIG. 2 may include and execute a firmware image of embedded hardware device(s) 202. To ensure that the firmware of the embedded hardware device(s) cannot be modified by an ordinary user of computing system 220, firmware package 202, firmware image 210 and/or package manage system 212 associated with embedded hardware device(s) 202, may have access permissions set such that a superuser, e.g. a root user, may update or change firmware image 210, while a regular user cannot update or change firmware image 210.

[0026] Similarly, an ordinary user may modify the firmware associated with other components of firmware package hierarchy 200, e.g. nested firmware packages 104, 106, and 108. The ability to modify the firmware associated with devices 224, 206, and 204 may be based on Unix file system permissions, for example. More particularly, various mount points for particular firmware packages may have different permissions thereby permitting different levels of user access to modifying the firmware associated with each mount point.

[0027] Package management system 224 may also reduce the amount of bandwidth and/or storage used for package hierarchy 200. More particularly, package management system 224 may use delta encoding to reduce space when downloading or storing two different versions of a firmware package. As an example, if a user has a version of nested firmware package 104 installed, and decides to download another version of nested firmware package 104 using package management system 224, package management system 224 may download files that were not in the previously-installed version of nested firmware package 104, and may not download files that were in a previously-installed version of nested firmware package 104.

[0028] For individual files, package management system 224 may store differences between individual files using delta encoding. For example, if a first version of a file within nested firmware package 106 includes additional data relative to second version of nested firmware package 106, package management system 224 may store the first file and the difference between the first version of the file and the second version of the file instead of storing the both the first and second versions of the file.

[0029] FIG. 3 is a flowchart of an example method for storing firmware of a computing system. Method 300 may be described below as being executed or performed by a system, for example, system 100 of FIG. 1 . Other suitable systems and/or computing devices may be used as well. Method 300 may be implemented in the form of executable instructions stored on at least one machine-readable storage medium of the system and executed by at least one processor of the system. Alternatively or in addition, method 300 may be implemented in the form of electronic circuitry (e.g., hardware). In alternate examples of the present disclosure, one or more blocks of method 300 may be executed substantially concurrently or in a different order than shown in FIG. 3. In alternate examples of the present disclosure, method 300 may include more or fewer blocks than are shown in FIG. 3. In some examples, one or more of the blocks of method 300 may, at certain times, be ongoing and/or may repeat.

[0030] Method 300 may start at block 302 and continue to block 304, where the system may store a firmware package comprising a firmware update. The firmware package may include a nested firmware package comprising a nested firmware update. In various examples, the nested firmware package, the firmware package, and/or the nested firmware update may correspond to a hardware component of a computing device. The firmware package may comprise a first binary image, and the nested firmware package may comprise a second binary image. The first binary image and the second binary image are mountable as file systems at a mount point of an operating system in various examples.

[0031 ] At block 306, the system may mount the binary image of the nested package. At block 308, the system may install the nested firmware update of the nested firmware package. Method 300 may continue to block 310, where the system may restart a component affected by installing the at least one of the firmware package or the nested package.

[0032] At block 312, the system may calculate a checksum for the nested package. The system may execute block 314 to verify that the calculated checksum matches a pre-computed checksum for the nested package after the package of firmware updates has been installed Method 300 may continue to block 314, at which point method 300 may stop.

[0033] In some examples, method 300 may include additional blocks, which are not pictured. In various examples of the method, the computing system may determine whether a user has access permissions for a file system associated with the nested firmware package, and responsive to determining that the user has access permissions for the file system associated with the nested firmware packages, may install the nested firmware package.

[0034] In various examples of method 300, the computing system may determine a dependency comprising a nested firmware package upon which the firmware package depends. The computing system may install the dependency, and responsive to installing the dependency, install the firmware package.

[0035] In yet some other examples, the computing system may determine a difference between a first version of the nested package and a second version of the nested package, and store the first version of the nested package and the difference between the first version and the second version of the nested package.

[0036] FIG. 4 is a block diagram of an example system for managing firmware of a computing system. In the example of FIG. 4, system 400 includes a processor 410 and a machine-readable storage medium 420. Although the following descriptions refer to a single processor and a single machine-readable storage medium, the descriptions may also apply to a system with multiple processors and multiple machine-readable storage mediums. In such examples, the instructions may be distributed (e.g., stored) across multiple machine-readable storage mediums and the instructions may be distributed (e.g., executed by) across multiple processors.

[0037] Processor 410 may be one or more central processing units (CPUs), microprocessors, and/or other hardware devices suitable for retrieval and execution of instructions stored in machine-readable storage medium 420. In the particular example shown in FIG. 4, processor 41 0 may fetch, decode, and execute instructions 422, 424, 426 to manage firmware of computing system 400. As an alternative or in addition to retrieving and executing instructions, processor 410 may include one or more electronic circuits comprising a number of electronic components for performing the functionality of one or more of the instructions in machine-readable storage medium 420. With respect to the executable instruction representations (e.g., boxes) described and shown herein, it should be understood that part or all of the executable instructions and/or electronic circuits included within one box may, in alternate examples, be included in a different box shown in the figures or in a different box not shown.

[0038] Machine-readable storage medium 420 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. Thus, machine-readable storage medium 420 may be, for example, Random Access Memory (RAM), an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disc, and the like. Machine-readable storage medium 420 may be disposed within system 400, as shown in FIG. 4. In this situation, the executable instructions may be "installed" on the system 400. Alternatively, machine-readable storage medium 420 may be a portable, external or remote storage medium, for example, that allows system 400 to download the instructions from the portable/external/remote storage medium. As described herein, machine- readable storage medium 420 may be encoded with executable instructions for injecting a memory failure pattern using post-package repair.

[0039] Referring to FIG. 4, package management system instructions 422, when executed by a processor (e.g., 410), may cause system 400 to execute a package management system, e.g. package management system 224. The instructions that cause the at least one processor to execute package management system 224 may further cause the at least one processor to execute instructions 424, and 426. Package storing instructions pattern instructions 424, when executed by a processor (e.g., 410), may cause system 410 to store a package of firmware updates that includes a nested package of firmware updates. Package mounting instructions 426, when executed by a processor (e.g., 410), may cause system 400 to mount the package of firmware updates and the nested package of firmware updates as file systems at a directory of an operating system. In various examples, the package management system may be included within at least one of the package of firmware updates or the nested package of firmware updates.