Download Firmware Windows 10
Hans Dagenais
This article describes how to update a removable or in-chassis device's firmware using the Windows Update (WU) service. For information about updating system firmware, see Windows UEFI firmware update platform.
To do this, you'll provide a device driver that includes the firmware payload. If you provide a function driver for your device, you can add the firmware update logic and payload to the existing driver, or you can provide a separate firmware update driver package. If your device uses a Microsoft-supplied driver, you must provide a separate firmware update driver package. In both cases, the firmware update driver package must be Universal.
Alternatively, if you want to update the function driver and the firmware update driver separately, create a second device node, on which you'll install the firmware update driver. The following diagram shows how one device can have two separate device nodes:
There are a couple ways to create a second device node. Certain device types have the ability to expose a second device node on one physical device, such as USB. You can use this functionality to create a device node targetable by WU, and install a firmware update driver on it. Many device types, however, don't allow a single physical device to enumerate more than one device node.
In this case, use an extension INF that specifies the AddComponent directive to create a device node that can be targeted by Windows Update and install the firmware update driver on it. The following snippet from an INF file shows how you can do this:
In the above INF sample, ComponentIDs = ComponentDeviceId indicates that the child device will have a hardware ID of SWC\ComponentDeviceId. When installed, this INF creates the following device hierarchy:
To locate another device node, the firmware driver should walk the device tree relative to itself, not by enumerating all device nodes for a match. A user may have plugged in multiple instances of the device, and the firmware driver should only update the device with which it's associated. Typically, the device node to be located is the parent or sibling of the device node on which the firmware driver is installed. For example, in the diagram above with two device nodes, the firmware update driver can look for a sibling device to find the function driver. In the diagram immediately above, the firmware driver can look for the parent device to find the primary device with which it needs to communicate.
The driver should be robust to multiple instances of the device being on the system, possibly with multiple different firmware versions. For example, there may be one instance of the device that has been connected and updated several times; a brand new device may then be plugged in which is several firmware versions old. This means that state (such as current version) must be stored against the device, and not in a global location.
The property fields in Device manager may cut off characters if too many are present with both the SSD part number and firmware revision displayed. For example, an MX500 running firmware revision M3CR023 will appear as "CT500MX500SSD1M3CR."
An alternative to Device Manager is to check the firmware revision installed on the SSD by downloading our free Storage Executive software (compatible with Windows 7 and newer versions and supports Crucial MX-series, BX-series, M550, and M500 SSDs).
2019 Micron Technology, Inc. All rights reserved. Information, products, and/or specifications are subject to change without notice. Neither Crucial nor Micron Technology, Inc. is responsible for omissions or errors in typography or photography. Micron, the Micron logo, Crucial, and the Crucial logo are trademarks or registered trademarks of Micron Technology, Inc. Windows is a trademark of Microsoft Corporation in the U.S. and/or other countries. Mac is a trademark of Apple, Inc., registered in the United States and/or other countries. All other trademarks and service marks are the property of their respective owners.
Each of those mechanisms have its own advantages. Stand-alone tools can support component-specific protocols but require the user to find and download the tools and find out if an update is available and applicable. UEFI UpdateCapsule drivers can be pushed through Windows Update but can only update components during boot-time when components may not be available or may not be attached. The most flexible mechanism is the component-specific firmware update driver, which can support component-specific protocols and can run whenever the device is enumerated on the system.
Writing a firmware update driver for each component-specific protocol can become a burden, so we defined the Component Firmware Update (CFU) standard protocol for use in our firmware update drivers and components. The protocol permits us to use a standardized driver and protocol to deliver firmware to any component that supports CFU.
Due to architectural differences, third-party firmware, or other issues, many of our components cannot support CFU. We designed CFU to allow a CFU-compatible component to receive firmware by using the CFU protocol and forward it to other components using their specific protocols. Thus, only one component in a collection of components needs to be CFU-compatible. The CFU driver delivers sub-component firmware to the primary component for forwarding to non-CFU components.
As part of our open-source effort, we are sharing the CFU protocol, driver sample, firmware sample code, and tool sample. This aims at enabling the system and peripheral developers to leverage this protocol, support their development, easily and automatically push firmware updates to Windows Update for many of their firmware components.
In CFU, a primary component is a device that understands the CFU protocol. This component can receive firmware from a CFU driver for itself or for the sub-components to which the component is connected. The CFU driver (host) is created by the component or device manufacturer and delivered through Windows Update. The driver is installed and loaded when the device is detected by Windows.
A CFU-compatible system uses a hierarchical concept of a primary component and sub-components. A primary component is a device that implements the device side of the CFU protocol and can receive updates for itself or its sub-components directly from the CFU driver. A primary component and sub-components can be internal or detachable. A device may have multiple primary components, with or without sub-components, each with its own CFU driver.
Sub-components are updated by the component after receiving a CFU firmware image that is targeted for the sub-component. The mechanism that the component uses to update its sub-components is implementation specific between the sub-component and the primary component and is beyond the scope of the CFU specification.
A package within the host comprises an offer and a payload or image and other information necessary for the driver to load. The offer contains enough information about the payload to allow the primary component to decide if it is an acceptable payload. Offer information includes a CFU protocol version, component ID (and sub-component ID if applicable), firmware version, release vs. debug status, and other information. For some devices, downloading and flashing new firmware is expensive for battery life and other reasons. By issuing an offer, the CFU protocol avoids downloading or flashing firmware that would be rejected based on versioning and other platform policies.
An offer can also be rejected if the primary component has accepted a download but must be restarted. In this case the component can reboot itself, if the user disruption is minimal, or the update can remain pending until the next system reboot. The host restarts the offer cycle after the reboot or component reset.
Consider an example of a device that has four components: one primary component and three sub components. Offers are made in no specific order within a cycle. Here is a representation of a possible host offer cycle:
After seeing all the offers, the primary component determines that sub-component 1 must be updated before sub-component 3, and that the order of the primary component and sub-component 2 does not matter. The component sets sub-component 3 as lower priority than sub-component 1.
So, this mechanism permits ordering of updates, even to the same entity. For example, if a component cannot receive version Y until it has version X due to some breaking change, both versions could be included, and version Y could be skipped until version X has been applied.
It is important to note that the host does not have to make any decisions based on content of the offers or payloads. It simply sends the offers down and sends down the payloads that are accepted. It does not have to have any logic about what it is offering. This permits it to be reused for diverse components and sub-components by changing only the offers and payloads it contains, and the component that the driver loads on.
The host does know the standard format of the offers to send the offer command. The host needs to understand the standard format of the payloads so that it can break them into addresses and bytes to deliver to the primary component. In the payload, the host does not need to know what data those fields contain.
After an offer has been accepted, the CFU Driver (the host) proceeds to download the firmware image, or Payload. The primary component may prepare itself to receive it upon accepting the offer, or it may wait for the download to commence before making any changes. The primary component may optionally cache the offer to check it against the payload after the payload is delivered but if possible, must evaluate the payload on its own merit, regardless of the offer.
The Payload, in simplest terms, is a set of addresses and fixed-size arrays of bytes, for example Address 0x0000 0000 and 16 associated bytes, then Address 0x0000 0010 and 16 more bytes. These are turned into write requests, one per address in the set, with its associated bytes.
d3342ee215