Firmware component with self-describing compliance information

Abstract

Embodiments of a semiconductor package device can include techniques to determine version information for a new firmware component, read compliance information corresponding to the firmware component, and determine whether compliance is satisfied between the new firmware component and one or more other firmware components based on the version information and the compliance information of the new firmware component. Other embodiments are disclosed and claimed.

Description

TECHNICAL FIELD

[0001] Embodiments relate generally to data processing systems. More particularly, embodiments relate to firmware components with self-describing compliance information. BACKGROUND

[0002] An electronic processing system can include a basic input / output system (BIOS) and an operating system (OS). Firmware can be control code included in various components of the electronic processing system or in devices attached to the electronic processing system. BRIEF DESCRIPTION OF DRAWINGS

[0003] Various advantages of embodiments will become apparent to those of ordinary skill in the art, upon reading the following detailed description and upon reference to the following drawings in which:

[0004] Figure 1 is a block diagram of an example of an electronic processing system according to an embodiment;

[0005] Figure 2 is a block diagram of an example of a semiconductor package device according to an embodiment;

[0006] Figures 3A to 3C is a flow diagram of an example of a method of firmware compliance checking according to an embodiment;

[0007] Figure 4 is a block diagram of an example of a firmware updater device according to an embodiment;

[0008] Figure 5 is a block diagram of another example of an electronic processing system according to an embodiment;

[0009] Figure 6 is a flow diagram of an example of a method of self-describing firmware updating and compliance checking according to an embodiment;

[0010] Figure 7A and 7B is a block diagram of an example of a firmware updater device according to an embodiment;

[0011] Figure 8 is a block diagram of an example of a processor according to an embodiment; and

[0012] Figure 9 is a block diagram of an example of a system according to an embodiment. DETAILED DESCRIPTION

[0013] Turning now to Figure 1In some embodiments, the electronic processing system 10 can include a processor 11, a memory 12 communicatively coupled to the processor 11, and logic 13 communicatively coupled to the processor 11 that determines version information for a new firmware component, reads compliance information corresponding to the firmware component, and determines whether compliance is satisfied between the new firmware component and one or more other firmware components based on the version information and the compliance information for the new firmware component. In some embodiments, the logic 13 can be configured to store self-describing compliance information corresponding to the new firmware component. For example, the self-describing compliance information can include one or more categories of firmware components to which the new firmware component is compliant, and a range of compatible versions for each of the one or more categories of firmware components. In some embodiments, the logic 13 can be configured to determine whether compliance is satisfied between the new firmware component and all other related firmware components based on the version information and the compliance information for the new firmware component. For example, the logic 13 can also be configured to update firmware with the new firmware component if compliance is satisfied between the new firmware component and all other related firmware components, and / or provide the compliance information to an operating system (e.g., an operating system of the electronic processing system 10).

[0014] Embodiments of each of the above-described processor 11, memory 12, logic 13, and other system components can be realized in hardware, software, or any suitable combination thereof. For example, a hardware implementation can include a configurable logic such as a programmable logic array (PLA), field programmable gate array (FPGA), complex programmable logic device (CPLD), or fixed-functionality logic hardware using circuit technology such as application specific integrated circuit (ASIC), complementary metal oxide semiconductor (CMOS), or transistor-transistor logic (TTL) technology, or any combination of these.

[0015] Alternatively, or additionally, all or some parts of these components can be implemented in one or more modules as a set of logic implemented in a machine or computer readable storage medium such as random access memory (RAM), read only memory (ROM), programmable ROM (PROM), firmware, flash memory, etc., executable by a machine or computer processor. For example, computer program code to carry out operations of the components can written in any combination of one or more operating systems (OS), suitable programming languages used to implement them in object oriented or procedural programming languages such as PYTHON, PERL, JAVA, SMALLTALK, C++, C#, etc., or conventional procedural programming languages such as the "C" programming language or similar programming languages. For example, memory 12, persistent storage, or other system memory can store a set of instructions that, when executed by processor 11, cause system 10 to implement one or more components, features, or aspects of system 10 (e.g., logic 13, determining version information for a new firmware component based on corresponding self-describing dependency information for the new firmware component based on firmware, reading dependency information corresponding to the firmware component, determining whether a dependency is satisfied between the new firmware component and one or more other firmware components based on the version information and the dependency information, etc.).

[0016] Turning now to Figure 2 , embodiments of semiconductor package 20 can include a substrate 21 and logic 22 coupled to substrate 21, where logic 22 is implemented at least partially in one or more of configurable logic and fixed function hardware logic. Logic 22 coupled to substrate 21 can be configured to determine version information for a new firmware component based on corresponding self-describing dependency information for the new firmware component based on firmware, read dependency information corresponding to the firmware component, and determine whether a dependency is satisfied between the new firmware component and one or more other firmware components based on the version information and the dependency information for the new firmware component. In some embodiments, logic 22 can be configured to store self-describing dependency information corresponding to the new firmware component. For example, the self-describing dependency information can include one or more categories of firmware components to which the new firmware component is dependent, and a range of compatible versions for each of the one or more categories of firmware components. In some embodiments, logic 22 can be configured to determine whether a dependency is satisfied between the new firmware component and all other related firmware components based on the version information and the dependency information for the new firmware component. For example, logic 22 can also be configured to update firmware with the new firmware component if the dependency is satisfied between the new firmware component and all other related firmware components, and / or provide the dependency information to an operating system.

[0017] Embodiments of logic 22 and other components of apparatus 20 can be implemented in hardware, software, or any combination thereof, including at least partial implementation in hardware. For example, a hardware implementation can include a configurable logic such as a PLA, FPGA, CPLD, or fixed function logic hardware with circuit technology such as ASIC, CMOS, or TTL, or any combination of these. In addition, some portions of these components can be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium such as a RAM, ROM, PROM, firmware, flash memory, etc., to be executed by a processor or computing device. For example, computer program code to carry out operations of components can be written in any combination of one or more OS applicable / appropriate programming languages, including object-oriented programming languages such as PYTHON, PERL, JAVA, SMALLTALK, C++, C#, etc., as well as conventional procedural programming languages, such as the "C" programming language or similar programming languages.

[0018] Turning now to FIG. 3, an embodiment of a method 30 of firmware dependency checking can include the operations of determining version information for a new firmware component at block 31, reading dependency information corresponding to the firmware component at block 32, and determining whether a dependency is satisfied between the new firmware component and one or more other firmware components based on the version information and the dependency information at block 33. Some embodiments of method 30 can include the operation of storing self-describing dependency information corresponding to the new firmware component at block 34. For example, the self-describing dependency information can include one or more categories of firmware components to which the new firmware component depends, and a range of compatible versions for each of the one or more categories of firmware, at block 35. Some embodiments of method 30 can include the operations of determining whether a dependency is satisfied between the new firmware component and all other related firmware components based on the version information and the dependency information at block 36, and updating firmware with the new firmware component if the dependency is satisfied between the new firmware component and all other related firmware components at block 37. For example, method 30 can also include the operation of providing the dependency information to an operating system at block 38.

[0019] Embodiments of the method 30 can be implemented in systems, apparatuses, computers, devices, etc., such as those described herein. More specifically, hardware implementations of the method 30 can include configurable logic such as PLA, FPGA, CPLD, or fixed-functionality logic hardware utilizing circuitry technologies such as ASIC, CMOS, or TTL, or any combination of these. Alternatively or additionally, the method 30 can be implemented in one or more modules as a set of logic instructions, stored in a machine- or computer-readable storage medium such as RAM, ROM, PROM, firmware, flash memory, etc., which can be executed by a processor or computing device. For example, the computer program code to carry out operations of the components can be written in any combination of one or more OS-appropriate / appropriate programming languages, including object- oriented programming languages, such as PYTHON, PERL, JAVA, SMALLTALK, C++, C#, etc., as well as conventional procedural programming languages, such as the "C" programming language or similar programming languages.

[0020] For example, the method 30 can be implemented on a computer-readable medium, as described below in connection with examples 19-24. Embodiments or portions of the method 30 can be implemented in firmware, an application (e.g., through an application programming interface (API)), or in driver software running on a BIOS or OS.

[0021] Some embodiments can be physically or logically implemented as one or more modules or components. Turning now to Figure 4Embodiments of the firmware updater device 40 can include a firmware scanner 41, a dependency checker 42, and an updater 43. The firmware scanner 41 can be configured to determine version information for a new firmware component of the firmware based on the respective self-describing dependency information of the new firmware component, and to read the dependency information corresponding to the firmware component. The dependency checker 42 can be configured to determine whether dependency is satisfied between the new firmware component and one or more other firmware components based on the version information and the dependency information of the new firmware component. In some embodiments, the device 40 and / or the new firmware component can store self-describing dependency information corresponding to the new firmware component. For example, the self-describing dependency information can include one or more categories of firmware components to which the new firmware component depends, and a range of compatible versions for each of the one or more categories of firmware components. In some embodiments, the dependency checker 42 can be configured to determine whether dependency is satisfied between the new firmware component and all other relevant firmware components based on the version information and the dependency information of the new firmware component. For example, the updater 43 can be configured to update the firmware with the new firmware component if dependency is satisfied between the new firmware component and all other relevant firmware components. In some embodiments, the firmware scanner 41 can also be configured to provide the dependency information to the operating system.

[0022] Embodiments of the firmware scanner 41, the dependency checker 42, the updater 43, and other components of the firmware updater device 40 can be implemented in hardware, software, or any combination thereof, including at least partial implementation in hardware. For example, a hardware implementation can include configurable logic such as PLA, FPGA, CPLD, or fixed-functionality logic hardware using circuit technology such as ASIC, CMOS, or TTL, or any combination of these. Moreover, some portions of these components can be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium such as a RAM, ROM, PROM, firmware, flash memory, etc., to be executed by a processor or computing device. For example, computer program code to carry out operations of the components can be written in any combination of one or more OS applicable / appropriate programming languages, including an object-oriented programming language such as PYTHON, PERL, JAVA, SMALLTALK, C++, C#, etc., as well as conventional procedural programming languages, such as the "C" programming language or similar programming languages.

[0023] Some embodiments can advantageously provide a system and / or method to support multi-firmware component updates with self-describing dependency expressions. An extensible firmware interface (EFI) can provide an interface between firmware and an OS. Firmware can provide control / communication code between hardware components / devices and the EFI. The Unified Extensible Firmware Interface (UEFI) specification can define a software interface between an operating system and platform firmware (e.g., UEFI Specification Version 2.7, published May 2017 at www.uefi.org / sites / default / files / resources / UEFI_Spec_2_7.pdf). In some systems, UEFI can replace the BIOS firmware interface (e.g., most UEFI firmware implementations provide legacy support for BIOS services). Some implementations of UEFI can support remote diagnosis and repair even without an operating system installed. In some systems, the UEFI EFI System Resource Table (ESRT) can include a globally unique identifier (GUID) for each updatable component. Some firmware elements on a platform can have dependencies on other firmware elements. Some embodiments can provide a means to express these dependencies and build on existing standards to provide a solution for platforms with many updatable elements. Such updatable elements can include, for example, management engine (ME) firmware, converged security manageability engine (CSME) firmware, core microcode, INTEL firmware support package, and modular host UEFI firmware (e.g., which can have a large number of separate binary modules).

[0024] Turning now to Figure 5An embodiment of an electronic processing system can include an OS (e.g., such as WINDOWS, REDHAT, etc.). The firmware resource table 51 can provide GUIDs, version information, and dependency information for a number of devices / components connected to the OS (e.g., camera 52, G-sensor / accelerometer 53, other system components 54 with their own firmware, etc.). For example, the firmware resource table 51 can be similar to a UEFI ESRT (e.g., or the UEFI standard can be extended to accommodate version dependency information). The firmware management protocol (FMP) capsule 55 can provide routing information, post-update data, and / or post-update drivers (e.g., a UEFI FMP capsule providing post-update UEFI drivers) as part of a firmware update. For example, the OS can read the dependency information corresponding to a new firmware component based on the respective self-describing dependency information of the new firmware component, and determine whether dependencies are satisfied between the new firmware component and one or more other firmware components based on the version information and dependency information of the new firmware component.

[0025] Security or other issues can prompt a firmware update (e.g., even in ME or CSME firmware). However, an end user or original equipment manufacturer (OEM) can not want a component provider to unilaterally update a binary module without verifying and delivering this update through a full BIOS update by the OEM or end user. Updating ME or other firmware without an associated BIOS reference code update can cause problems for other system components, for example. The same problem can occur for core microcode, as some microcode patches can bring up new hardware like model specific registers (MSRs), and the associated host firmware / BIOS can need to be updated consistently. Some systems can have many firmware elements that can be updated. Some component providers can publish a set of firmware elements that must be updated together (e.g., as a best known configuration (BKC)).

[0026] Some embodiments can support the dependencies between elements being expressed in a software-visible manner by the updater. Such dependencies can even be exposed to the OS updater, such as a capsule updater. For example, WINDOWS can provide MODEL BASED SERVICE (MBS) for firmware updates. LINUX can advance firmware update project (FWUPD), and can provide LINUX VENDOR FIRMWARE SERVICE (LVFS). Such projects and / or services can benefit from exposing dependencies to the OS as described herein according to some embodiments.

[0027] Some embodiments can help alleviate OEM concerns with component-based updates, and help remove friction for pushing updates in response to product response team (PRT) actions, whether functional or security-based, by providing a means to support secure updates of dependency modules on a platform. Some embodiments can provide robust field-updatable hardware to avoid recalls, but also support rapid fixes to avoid exposing customers to security risks.

[0028] Firmware updates can be an important feature in some electronic systems / platforms. Some industry standards can describe firmware update procedures and / or security requirements. For example, the UEFI specification can define an EFI_SYSTEM_RESOURCE_TABLE to identify system firmware and device firmware to the operating system. The data structure can be represented as follows:

[0029] typedef struct{

[0030] UINT32 FwResourceCount;

[0031] UINT32 FwResourceCountMax;

[0032] UINT64 FwResourceVersion;

[0033] / / EFI_SYSTEM_RESOURCE_ENTRY Entries[];

[0034] } EFI_SYSTEM_RESOURCE_TABLE;

[0035] typedef struct{

[0036] EFI_GUID FwClass;

[0037] UINT32 FwType;

[0038] UINT32 FwVersion;

[0039] UINT32 LowestSupportedFwVersion;

[0040] UINT32 CapsuleFlags;

[0041] UINT32 LastAttemptVersion;

[0042] UINT32 LastAttemptStatus;

[0043] } EFI_SYSTEM_RESOURCE_ENTRY;

[0044] An OS can utilize the EFI_SYSTEM_RESOURCE_TABLE to manage firmware of a system(s) and allow a provider and / or user to perform firmware updates. Problems can occur in some systems if the utilization of the EFI_SYSTEM_RESOURCE_TABLE assumes that firmware identified can be updated independently. However, in some systems there can be multiple firmware components on a platform that can have some dependencies between each other. For example, a system BIOS can need to work with a particular version of microcode. A client system BIOS can need to work with a particular version of ME firmware and a particular version of embedded controller (EC) firmware. A server system BIOS can need to work with a particular version of baseboard management controller (BMC) firmware. A system BIOS can need to work with a particular version of wireless network interface card (NIC) microcode or BLUETOOTH LOW ENERGY (BLE) firmware. If an error occurs, or otherwise breaks the dependencies, the system can fail to boot, or experience other problems, and it can be difficult to detect the problem.

[0045] For security reasons, there can be situations where an end user can need or prefer to update only one of the firmware components. However, the end user can not know if it is appropriate to update only one of the firmware components, or if different firmware components need to be updated together. Some providers can recommend that the end user always update all firmware on their system, or can hardcode some dependency checks in the firmware code. Updating all firmware can avoid dependency issues between new firmware, but can cause problems if the old platform cannot work with all the new firmware. Hardcoding some dependency checks can avoid some dependency issues, but the dependency information remains hidden and hardcoding is not flexible for further extensions / updating. The hard coded dependency checks can only occur after an update, requiring the end user to roll back the firmware after receiving an error.

[0046] Some embodiments can advantageously provide a way to clearly describe firmware version dependencies and expose this information to the OS. Commercial OSs can present this information to the end user. Pre-checks can be performed when the user wishes to update firmware in the OS environment, advantageously ensuring that dependencies are met before the firmware is updated. Some embodiments can provide an architectural way to report firmware dependencies in addition to firmware versions. Some embodiments can pass the dependency information to the OS and display this information to the end user. Some embodiments can advantageously prohibit or prevent user / provider errors at very early stages to maintain the system / platform in a healthy state.

[0047] Some embodiments can provide a self-describing firmware dependency definition as an extension to a data structure. Version dependency information can be reported by each firmware component. In some embodiments, the data structure can be represented as follows:

[0048] typedef struct{

[0049] UINT32 FwVersionBegin;

[0050] UINT32 FwVersionEnd;

[0051] } EFI_SYSTEM_FIRMWARE_VERSION_RANGE;

[0052] typedef struct{

[0053] EFI_GUID FwClass;

[0054] UINT32 VersionRangeCount;

[0055] EFI_SYSTEM_FIRMWARE_VERSION_RANGE

[0056] VersionRange[VersionRangeCount];

[0057] }EFI_SYSTEM_FIRMWARE_DEPENDENCY;

[0058] typedef struct{

[0059] EFI_GUID FwClass;

[0060] UINT32 FwVersion;

[0061] UINT32 DependencyCount;

[0062] EFI_SYSTEM_FIRMWARE_DEPENDENCY

[0063] Dependency[DependencyCount];

[0064] }EFI_SYSTEM_RESOURCE_DEPENDENCY;

[0065] For example, if the current BIOS firmware (FwClassBios, version 21) is dependent on ME firmware (FwClassMe, version 32 and above) and EC firmware (FwClassEc, between versions 56 and 59, or between versions 61 and 68), then in some embodiments the dependency structure can be represented as follows:

[0066] EFI_SYSTEM_RESOURCE_DEPENDENCY BiosEntry={

[0067] .FwClass = FwClassBios;

[0068] .FwVersion=21;

[0069] .DependencyCount = 2;

[0070] .Dependency[0].FwClass=FwClassMe;

[0071] .Dependency[0].VersionRangeCount=1;

[0072] .Dependency[0].VersionRange[0].FwVersionBegin=34;

[0073] .Dependency[0].VersionRange[0].FwVersionEnd = 0xFFFFFFFF;

[0074] .Dependency[1].FwClass = FwClassEc;

[0075] .Dependency[1].VersionRangeCount = 2;

[0076] .Dependency[1].VersionRange[0].FwVersionBegin = 56;

[0077] .Dependency[1].VersionRange[0].FwVersionEnd = 59;

[0078] .Dependency[1].VersionRange[1].FwVersionBegin = 61 ;

[0079] .Dependency[1].VersionRange[1].FwVersionEnd = 68;

[0080] }

[0081] If the current ME firmware (FwClassMe, version 34) depends on the BIOS (FwClassBios, version >= 19), then in some embodiments the dependency structure can be represented as follows:

[0082] EFI_SYSTEM_RESOURCE_DEPENDENCY MeEntry = {

[0083] .FwClass = FwClassMe;

[0084] .FwVersion = 34;

[0085] .DependencyCount = 2;

[0086] .Dependency[0].FwClass = FwClassBios;

[0087] .Dependency[0].VersionRangeCount = 1;

[0088] .Dependency[0].VersionRange[0].FwVersionBegin = 19;

[0089] Dependency[0].VersionRange[0].FwVersionEnd = 0xFFFFFFFF;

[0090] }

[0091] Turning now to Figure 6 , an embodiment of the method 60 of self-describing firmware update and compliance checking can include scanning each firmware in the new BIOS capsule at block 61, obtaining the new firmware version at block 62, scanning each firmware component in the current boot environment at block 63, obtaining the current firmware version at block 64, comparing each new and current firmware component in the same firmware class at block 65, and obtaining the highest version firmware in the same class at block 66. The method 60 can then review the compliance described in each firmware resource at block 67, and determine if the compliance is satisfied at block 68, until all firmware components have been checked at block 69. If any compliance is not satisfied at block 68, the check can fail at block 70. The failure can be reported and the firmware update can be aborted. If all firmware compliances pass the compliance check at block 69, the method 60 can then report that the compliance check passed at block 71, and proceed with the firmware update at block 72.

[0092] For example, if the new firmware capsule update image has the following representative structure:

[0093] EFI_SYSTEM_RESOURCE_DEPENDENCY BiosEntry = {

[0094] .FwClass = FwClassBios;

[0095] .FwVersion = 24;

[0096] .DependencyCount = 2;

[0097] .Dependency[0].FwClass = FwClassMe;

[0098] .Dependency[0].VersionRangeCount = 1;

[0099] .Dependency[0].VersionRange[0].FwVersionBegin = 34;

[0100] .Dependency[0].VersionRange[0].FwVersionEnd = 0xFFFFFFFF;

[0101] .Dependency[1].FwClass = FwClassEc;

[0102] .Dependency[1].VersionRangeCount = 2;

[0103] .Dependency[1].VersionRange[0].FwVersionBegin = 56;

[0104] .Dependency[1].VersionRange[0].FwVersionEnd = 59;

[0105] .Dependency[1].VersionRange[1].FwVersionBegin = 61 ;

[0106] .Dependency[1].VersionRange[1].FwVersionEnd = 68;

[0107] }

[0108] EFI_SYSTEM_RESOURCE_DEPENDENCY MeEntry = {

[0109] .FwClass = FwClassMe;

[0110] .FwVersion = 49;

[0111] .DependencyCount = 2;

[0112] .Dependency[0].FwClass = FwClassBios;

[0113] .Dependency[0].VersionRangeCount = 1;

[0114] .Dependency[0].VersionRange[0].FwVersionBegin = 26;

[0115] .Dependency[0].VersionRange[0].FwVersionEnd = 0xFFFFFFFF;

[0116] }

[0117] Then the new ME firmware will not be updated because its BIOS dependency (version 26) cannot be satisfied.

[0118] If the new firmware capsule update image has the following representative structure:

[0119] EFI_SYSTEM_RESOURCE_DEPENDENCY BiosEntry = {

[0120] .FwClass = FwClassBios;

[0121] .FwVersion = 27;

[0122] .DependencyCount = 2;

[0123] .Dependency[0].FwClass = FwClassMe;

[0124] .Dependency[0].VersionRangeCount = 1;

[0125] .Dependency[0].VersionRange[0].FwVersionBegin = 40;

[0126] .Dependency[0].VersionRange[0].FwVersionEnd = 0xFFFFFFFF;

[0127] .Dependency[1].FwClass = FwClassEc;

[0128] .Dependency[1].VersionRangeCount = 2;

[0129] .Dependency[1].VersionRange[0].FwVersionBegin = 56;

[0130] .Dependency[1].VersionRange[0].FwVersionEnd = 59;

[0131] .Dependency[1].VersionRange[1].FwVersionBegin = 61;

[0132] .Dependency[1].VersionRange[1].FwVersionEnd = 68;

[0133] }

[0134] EFI_SYSTEM_RESOURCE_DEPENDENCY MeEntry = {

[0135] .FwClass = FwClassMe;

[0136] .FwVersion = 49;

[0137] .DependencyCount = 2;

[0138] .Dependency[0].FwClass = FwClassBios;

[0139] .Dependency[0].VersionRangeCount = 1;

[0140] .Dependency[0].VersionRange[0].FwVersionBegin = 26;

[0141] .Dependency[0].VersionRange[0].FwVersionEnd = 0xFFFFFFFF;

[0142] }

[0143] Then both the BIOS and the ME will be updated, as the dependency is satisfied.

[0144] Figure 7A A firmware updater device 132 (132a-132c) is shown that can implement one or more aspects of the method 30 ( Figures 3A to 3C ) and / or the method 60 ( Figure 6 ). The firmware updater device 132, which can include logic instructions, configurable logic, fixed function hardware logic, can readily replace the logic 13 ( Figure 1 ), the logic 22 ( Figure 2 ), or the firmware updater device 40 ( Figure 4 ) already discussed. The firmware scanner 132a can be configured to determine version information for a new firmware component of the firmware based on respective self-describing dependency information of the new firmware component, and to read dependency information corresponding to the firmware component. The dependency checker 132b can be configured to determine whether a dependency is satisfied between the new firmware component and one or more other firmware components based on the version information and the dependency information of the new firmware component. In some embodiments, the device 132 and / or the new firmware component can store self-describing dependency information corresponding to the new firmware component.

[0145] For example, the self-describing dependency information can include one or more categories of firmware components to which the new firmware component depends, and a range of compatible versions for each of the one or more categories of firmware components. In some embodiments, the dependency checker 132b can be configured to determine whether dependency is satisfied between the new firmware component and all other related firmware components based on the version information of the new firmware component and the dependency information. For example, the updater 132c can be configured to update the firmware with the new firmware component if dependency is satisfied between the new firmware component and all other related firmware components. In some embodiments, the firmware scanner 132a can also be configured to provide the dependency information to the operating system.

[0146] Turning now to Figure 7B , a firmware updater device 134 (134a, 134b) is shown, in which logic 134b (e.g., transistor arrays and other integrated circuit / IC components) is coupled to a substrate 134a (e.g., silicon, sapphire, gallium arsenide). The logic 134b can generally implement one or more aspects of the method 30 Figures 3A to 3C ) and / or the method 60 Figure 6 ). Thus, the logic 134b can determine version information for a new firmware component of a firmware based on respective self-describing dependency information for the new firmware component, read dependency information corresponding to firmware components, and determine whether dependency is satisfied between the new firmware component and one or more other firmware components based on the version information of the new firmware component and the dependency information. In some embodiments, the logic 134b can store self-describing dependency information corresponding to the new firmware component. For example, the self-describing dependency information can include one or more categories of firmware components to which the new firmware component depends, and a range of compatible versions for each of the one or more categories of firmware components. In some embodiments, the logic 134b can determine whether dependency is satisfied between the new firmware component and all other related firmware components based on the version information of the new firmware component and the dependency information. For example, the logic 134b can also update the firmware with the new firmware component if dependency is satisfied between the new firmware component and all other related firmware components, and / or provide the dependency information to an operating system. In one example, the device 134 is a semiconductor die, chip, and / or package.

[0147] Figure 8 A processor core 200 is illustrated in accordance with one embodiment. The processor core 200 can be a core for any type of processor (e.g., a microprocessor, an embedded processor, a digital signal processor (DSP), a network processor, or other device that executes codes). Although only one processor core 200 is illustrated in Figure 8 , a processing element can instead include more than one processor core 200. Figure 8The processor core 200 is shown in more detail in FIG. 2. The processor core 200 can be a single-threaded core, or for at least one embodiment, the processor core 200 can be multi-threaded in that it can include more than one hardware thread context (or "logical processor") per core.

[0148] Figure 8 Also shown is a memory 270 coupled to the processor core 200. The memory 270 can be any of various memories known to those of skill or otherwise available, including various levels of a memory hierarchy. The memory 270 can include one or more code 213 instructions to be executed by the processor core 200, where the code 213 can implement one or more aspects of the method 30( Figures 3A to 3C ) and / or the method 60( Figure 6 ) already discussed. The processor core 200 follows a program sequence of instructions indicated by the code 213. Each instruction can pass through the front end portion 210 and be processed by one or more decoders 220. The decoders 220 can generate, as their output, a micro operation such as a fixed width micro op of a predetermined format, or other instruction, microinstruction, or control signal that reflects the original code instruction. The illustrated front end portion 210 also includes register renaming logic 225 and scheduling logic 230, which are generally responsible for assigning resources and queuing the various operations comprising the micro ops in a way that will cause the processor core 200 to perform the instructions of code 213.

[0149] The processor core 200 is shown as including execution logic 250 having a set of execution units 250-1 through 250-N. Some embodiments can include a set of execution units devoted to specific functions or sets of functions. Other embodiments can include only one execution unit or can include an execution unit that performs specific functions in addition to other functions. The illustrated execution logic 250 performs the operations specified by code instructions.

[0150] After the operations specified by the code instructions are completed, the back end logic 260 retires the instructions of the code 213. In one embodiment, the processor core 200 allows out of order execution but requires in order retirement. Retirement logic 265 can take many forms as known to those of skill. In this manner, the processor core 200 is transformed during execution of the code 213, at least in terms of the output generated by the decoders, the hardware registers and table

[0151] Although in Figure 8The processing elements are not shown in FIG. 1, but the processing elements can include other elements on the chip with the processor core 200. For example, the processing elements can include memory control logic with the processor core 200. The processing elements can include I / O control logic and / or can include I / O control logic integrated with the memory control logic. The processing elements can also include one or more caches.

[0152] Referring now to the drawings, in which is shown a block diagram of a system 1000 according to an embodiment. Figure 9 The system 1000 is shown as a point-to-point interconnect system, wherein the first processing element 1070 and the second processing element 1080 are coupled via a point-to-point interconnect 1050. It should be appreciated that any or all of the interconnects illustrated in FIG. 1 can be implemented as a multi-drop bus rather than a point-to-point interconnect. Figure 9 The system 1000 is shown as a point-to-point interconnect system, wherein the first processing element 1070 and the second processing element 1080 are coupled via a point-to-point interconnect 1050. It should be appreciated that any or all of the interconnects illustrated in FIG. 1 can be implemented as a multi-drop bus rather than a point-to-point interconnect.

[0153] The system 1000 is shown as a point-to-point interconnect system, wherein the first processing element 1070 and the second processing element 1080 are coupled via a point-to-point interconnect 1050. It should be appreciated that any or all of the interconnects illustrated in FIG. 1 can be implemented as a multi-drop bus rather than a point-to-point interconnect. Figure 9 Any or all of the interconnects illustrated in FIG. 1 can be implemented as a multi-drop bus rather than a point-to-point interconnect.

[0154] As shown in FIG. 1, each of the processing elements 1070 and 1080 can be a multi-core processor including first and second processor cores (i.e., processor cores 1074a and 1074b and processor cores 1084a and 1084b). Such cores 1074a, 1074b, 1084a, 1084b can be configured to execute instruction code in a similar manner as described above in connection with the core 1040. Figure 9 Figure 8

[0155] Each processing element 1070, 1080 can include at least one shared cache 1896a, 1896b (e.g., static random access memory / SRAM). The shared cache 1896a, 1896b can store data (e.g., objects, instructions) utilized by one or more components of the processor (e.g., cores 1074a, 1074b and 1084a, 1084b, respectively). For example, the shared cache 1896a, 1896b can store data stored in the local cache memories 1032, 1034 for more rapid access by components of the processor. In one or more embodiments, the shared cache 1896a, 1896b can include one or more intermediate level caches, such as a level 2 (L2), a level 3 (L3), a level 4 (4), or other level cache, a last level cache (LLC), and / or a combination of these.

[0156] ​​While shown with only two processing elements 1070, 1080, it is to be understood that the scope of the embodiments is not so limited. In other embodiments, one or more additional processing elements can be present in a given processor. Alternatively, one or more of processing elements 1070, 1080 can be an element other than a processor, such as an accelerator or a field programmable gate array. For example, the additional processing element(s) can include an additional processor(s) identical to the first processor 1070, an additional processor(s) heterogeneous or asymmetric to the first processor 1070, an accelerator such as a graphics accelerator or a digital signal processor (DSP) unit, a field programmable gate array, or any other processing element. There can be a variety of differences between the processing elements 1070, 1080 in terms of a spectrum of metrics, including architectural, microarchitectural, thermal, power consumption characteristics, and the like.

[0157] The first processing element 1070 also can include memory controller logic (MC) 1072 and a point-to-point (P-P) interface 1076 and 1078. Similarly, the second processing element 1080 can include MC 1082 and a P-P interface 1086 and 1088. As shown in Figure 9 The MCs 1072 and 1082 couple the processors to respective memories, namely memory 1032 and memory 1034, which can be portions of main memory attached to the respective processors by the MCs 1072 and 1082. While MCs 1072 and 1082 are shown as integrated into processing elements 1070, 1080, for alternate embodiments, the MC logic can be discrete logic separate from the processing elements 1070, 1080.

[0158] The first processing element 1070 and the second processing element 1080 can be coupled to an I / O subsystem 1090 via P-P interconnects 1076, 1086, respectively. As shown in Figure 9 The I / O subsystem 1090 includes a TEE 1097 (e.g., a security controller) and P-P interfaces 1094 and 1098, as shown in

[0159] Further, I / O subsystem 1090 can be coupled to first bus 1016 via an interface 1096. In one embodiment, first bus 1016 can be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another third generation I / O interconnect bus, although the scope of the embodiments is not so limited.

[0160] As shown in Figure 9 various I / O devices 1014 (e.g., camera, sensors) can be coupled to first bus 1016, as well as a bus bridge 1018 that can couple first bus 1016 to a second bus 1020. In one embodiment, second bus 1020 can be a low pin count (LPC) bus. Various devices can be coupled to second bus 1020, including a keyboard / mouse 1012, network controller / communication device(s) 1026 (which in turn can communicate with a computer network), and a data storage unit 1019, such as a disk drive or other mass storage device, which in one embodiment can include code 1030. Code 1030 can include instructions for performing embodiments of one or more methods described above. Thus, the illustrated code 1030 can implement one or more aspects of method 30( Figures 3A to 3C ) and / or method 60( Figure 6 ) that have been discussed, and can be similar to code 213( Figure 8 ) that has been discussed. Additionally, audio I / O 1024 can be coupled to second bus 1020.

[0161] Note that other embodiments are contemplated. For example, instead of a point-to-point architecture of Figure 9 , a system can implement a multi-drop bus or another such communication topology.

[0162] Additional notes and examples:

[0163] Example 1 can include an electronic processing system comprising a processor, a memory communicatively coupled to the processor, and logic communicatively coupled to the processor, the logic to determine version information for a new firmware component of firmware based on respective self-descriptive compliance information of the new firmware component, read compliance information corresponding to the firmware component, and determine whether a compliance is satisfied between the new firmware component and one or more other firmware components based on the version information of the new firmware component and the compliance information.

[0164] Example 2 can include the system of example 1, wherein the logic is further to store self- descriptive compliance information corresponding to the new firmware component.

[0165] Example 3 can include the system of example 2, wherein the self-describing dependency information includes one or more categories of firmware components to which the new firmware component depends, and a range of compatible versions for each of the one or more categories of firmware components.

[0166] Example 4 can include the system of example 1, wherein the logic is further to determine whether dependency is satisfied between the new firmware component and all other related firmware components based on the version information of the new firmware component and the dependency information.

[0167] Example 5 can include the system of example 4, wherein the logic is further to update the firmware with the new firmware component if dependency is satisfied between the new firmware component and all other related firmware components.

[0168] Example 6 can include the system of any of examples 1 to 5, wherein the logic is further to provide the dependency information to an operating system.

[0169] Example 7 can include a semiconductor package device comprising a substrate, and logic coupled to the substrate, wherein the logic is implemented at least in part in one or more of configurable logic and fixed function hardware logic, the logic coupled to the substrate to determine version information for a new firmware component of a firmware based on respective self-describing dependency information for the new firmware component, read dependency information corresponding to the firmware component, and determine whether dependency is satisfied between the new firmware component and one or more other firmware components based on the version information of the new firmware component and the dependency information.

[0170] Example 8 can include the device of example 7, wherein the logic is further to store self-describing dependency information corresponding to the new firmware component.

[0171] Example 9 can include the device of example 8, wherein the self-describing dependency information includes one or more categories of firmware components to which the new firmware component depends, and a range of compatible versions for each of the one or more categories of firmware components.

[0172] Example 10 can include the device of example 7, wherein the logic is further to determine whether dependency is satisfied between the new firmware component and all other related firmware components based on the version information of the new firmware component and the dependency information.

[0173] Example 11 can include the device of example 10, wherein the logic is further to update the firmware with the new firmware component if dependency is satisfied between the new firmware component and all other related firmware components.

[0174] Example 12 can include the apparatus of any of Examples 7 to 11, wherein the logic is further to provide the compliance information to an operating system.

[0175] Example 13 can include a method of firmware compliance checking, comprising determining version information for a new firmware component of a firmware based on corresponding self-describing compliance information for the new firmware component, reading compliance information corresponding to the firmware component, and determining whether compliance is satisfied between the new firmware component and one or more other firmware components based on the version information for the new firmware component and the compliance information.

[0176] Example 14 can include the method of Example 13, further comprising storing self- describing compliance information corresponding to the new firmware component.

[0177] Example 15 can include the method of Example 14, wherein the self-describing compliance information comprises one or more categories of firmware components to which the new firmware component is compliant, and a range of compatible versions for each of the one or more categories of firmware components.

[0178] Example 16 can include the method of Example 13, further comprising determining whether compliance is satisfied between the new firmware component and all other related firmware components based on the version information for the new firmware component and the compliance information.

[0179] Example 17 can include the method of Example 16, further comprising updating the firmware with the new firmware component if compliance is satisfied between the new firmware component and all other related firmware components.

[0180] Example 18 can include the method of any of Examples 13 to 17, further comprising providing the compliance information to an operating system.

[0181] Example 19 can include at least one computer-readable medium comprising a set of instructions, which when executed by a computing device, cause the computing device to determine version information for a new firmware component of a firmware based on corresponding self-describing compliance information for the new firmware component, read compliance information corresponding to the firmware component, and determine whether compliance is satisfied between the new firmware component and one or more other firmware components based on the version information for the new firmware component and the compliance information.

[0182] Example 20 can include the at least one computer-readable medium of Example 19, comprising another set of instructions, which when executed by the computing device, cause the computing device to store self-describing compliance information corresponding to the new firmware component.

[0183] Example 21 can include the at least one computer readable medium of example 20, wherein the self-describing dependency information includes one or more categories of firmware components to which the new firmware component depends, and a range of compatible versions for each of the one or more categories of firmware components.

[0184] Example 22 can include the at least one computer readable medium of example 19, including another set of instructions, which when executed by the computing device, cause the computing device to determine whether dependency is satisfied between the new firmware component and all other related firmware components based on the version information of the new firmware component and the dependency information.

[0185] Example 23 can include the at least one computer readable medium of example 22, including another set of instructions, which when executed by the computing device, cause the computing device to update the firmware with the new firmware component if dependency is satisfied between the new firmware component and all other related firmware components.

[0186] Example 24 can include the at least one computer readable medium of any of examples 19 to 23, including another set of instructions, which when executed by the computing device, cause the computing device to provide the dependency information to an operating system.

[0187] Example 25 can include a firmware dependency checker apparatus, comprising means for determining version information for a new firmware component of firmware based on corresponding self-describing dependency information for the new firmware component, means for reading dependency information corresponding to the firmware component, and means for determining whether dependency is satisfied between the new firmware component and one or more other firmware components based on the version information of the new firmware component and the dependency information.

[0188] Example 26 can include the apparatus of example 25, further comprising means for storing self-describing dependency information corresponding to the new firmware component.

[0189] Example 27 can include the apparatus of example 26, wherein the self-describing dependency information includes one or more categories of firmware components to which the new firmware component depends, and a range of compatible versions for each of the one or more categories of firmware components.

[0190] Example 28 can include the apparatus of example 25, further comprising means for determining whether dependency is satisfied between the new firmware component and all other related firmware components based on the version information of the new firmware component and the dependency information.

[0191] Example 29 can include the apparatus of example 28, further comprising means for updating the firmware with the new firmware component if compliance is satisfied between the new firmware component and all other related firmware components.

[0192] Example 30 can include the apparatus of any of examples 25 to 29, further comprising means for providing the compliance information to an operating system.

[0193] Embodiments are applicable for use with all manner of semiconductor integrated circuit ("IC") chips. Examples of these IC chips include but are not limited to processors, controllers, chipset components, programmable logic arrays (PLAs), memory chips, network chips, systems on chips (SoCs), SSD / NAND controller ASICs, and the like. In some of the drawings, signal conductor lines are represented with lines having arrows indicating the intended direction of signal flow. Some of the drawing lines can be different, to indicate more than one signal flow pathway, some can be numbered, to indicate the number of signal paths, and others can have arrows indicating the principal signal flow direction. However, these are merely for purposes of illustration and do not limit the scope of the subject matter described herein. In fact, many of the signal lines can be adapted, in various embodiments, to carry one or more different signals, under the control of the logic of the system. More specifically, use of the terms "signal", "channel", and / or "line" in this description should not be confused with an actual buses, lines, or signals in the system.

[0194] Example sizes / models / values / ranges can have been given, although embodiments are not limited to the same. As manufacturing techniques (e.g., photolithography) mature over time, it is expected that devices of smaller size could be manufactured. In the future, such devices can be manufactured, packaged, tested and sold in a more cost effective manner. In addition, the example values given for angles, dimensions, and so forth are intended to serve as examples. In some embodiments, the actual values can be different depending on the specific design and / or manufacturing process / experimentation used. In some embodiments, the dimensions and / or values can be chosen to achieve the benefits described herein while remaining within the scope of the embodiments. Moreover, to the extent that the terms "front", "back", "top", "bottom", "over", "under", and the like can be used in this description and / or in the appended drawings, these terms are used for purposes of illustration and / or discussion and do not necessarily indicate the relative position(s) of the referenced item(s) in the system.

[0195] The term "coupled" can be used herein to refer to any type of relationship between the coupled components, whether that is direct or indirect, and can apply to electrical, mechanical, fluid, optical, electromagnetic, or other connections. Moreover, the terms "first", "second", etc. can be used herein only to facilitate discussion, and do not necessarily have specific time or order meanings.

[0196] As used in this application and the claims, a list of items joined by the term "at least one of" can mean any combination of the listed terms. For example, the phrases "at least one of A, B, and C" and "at least one of A, B, or C" each can mean: A; B; C; A and B; A and C; B and C; or A, B, and C.

[0197] Those skilled in the art will appreciate from the foregoing description that the broad techniques of the embodiments can be implemented in a variety of forms. Therefore, although the embodiments have been described in connection with particular examples thereof, the true scope of the embodiments should not be limited so much as other modifications will be apparent to those skilled in the art upon reading the specification, particularly when viewed in conjunction with the drawings and the appended claims.

Claims

1. An electronic processing system, comprising: processor; Memory communicatively coupled to the processor; as well as Logic communicatively coupled to the processor, which is used for: Based on the corresponding self-describing compliance information of the new firmware component, version information is determined for the new firmware component, wherein the self-describing compliance information includes one or more categories of firmware components to which the new firmware component depends, and a range of compatible versions for each of the one or more categories of firmware components. Read the compliance information corresponding to the firmware component. Based on the version information and compliance information of the new firmware component, it is determined whether a compliance condition is met between the new firmware component and all other related firmware components. If a dependency is satisfied between the new firmware component and all other relevant firmware components, the firmware is updated using the new firmware component.

2. The system of claim 1, wherein the logic is further configured to: Store the self-describing compliance information corresponding to the new firmware component.

3. The system of any one of claims 1 to 2, wherein the logic is further configured to: The compliance information is provided to the operating system.

4. A semiconductor packaging apparatus, comprising: Substrate; as well as Logic coupled to the substrate, wherein the logic is at least partially implemented in one or more of configurable logic and fixed-function hardware logic, the logic coupled to the substrate is used for: Based on the corresponding self-describing compliance information of the new firmware component, version information is determined for the new firmware component, wherein the self-describing compliance information includes one or more categories of firmware components to which the new firmware component depends, and a range of compatible versions for each of the one or more categories of firmware components. Read the compliance information corresponding to the firmware component. Based on the version information and compliance information of the new firmware component, it is determined whether a compliance condition is met between the new firmware component and all other related firmware components. If a dependency is satisfied between the new firmware component and all other relevant firmware components, the firmware is updated using the new firmware component.

5. The apparatus of claim 4, wherein the logic is further configured to: Store the self-describing compliance information corresponding to the new firmware component.

6. The apparatus of any one of claims 4 to 5, wherein the logic is further configured to: The compliance information is provided to the operating system.

7. A method for firmware compliance checking, comprising: Based on the corresponding self-describing compliance information of the new firmware component, version information is determined for the new firmware component, wherein the self-describing compliance information includes one or more categories of firmware components to which the new firmware component is subject, and a range of compatible versions for each of the one or more categories of firmware components. Read the compliance information corresponding to the firmware component; Based on the version information and the compliance information of the new firmware component, determine whether the compliance is satisfied between the new firmware component and all other related firmware components; and If a dependency is satisfied between the new firmware component and all other relevant firmware components, the firmware is updated using the new firmware component.

8. The method of claim 7, further comprising: Store the self-describing compliance information corresponding to the new firmware component.

9. The method of any one of claims 7 to 8, further comprising: The compliance information is provided to the operating system.

10. A firmware compliance checker device, comprising: A means for determining version information for a new firmware component based on corresponding self-describing compliance information, wherein the self-describing compliance information includes one or more categories of firmware components to which the new firmware component conforms, and a range of compatible versions for each of the one or more categories of firmware components. A means for reading compliance information corresponding to the firmware component; A means for determining, based on the version information and the compliance information of the new firmware component, whether a compliance is satisfied between the new firmware component and all other related firmware components; as well as A means for updating firmware using the new firmware component if a dependency is satisfied between the new firmware component and all other related firmware components.

11. The apparatus of claim 10, further comprising: A means for storing self-describing compliance information corresponding to the new firmware component.

12. The apparatus of any one of claims 10 to 11, further comprising: A means for providing the compliance information to the operating system.

Images