Microsoft has today announced Component Firmware Update (CFU), a new open source model for Windows systems developers. Developers can leverage CFU to implement firmware updates through Windows Update.
In a blog post today, the Microsoft Devices Team explains firmware updates have three main delivery methods: These are component-specific updates, Windows UEFI UpdateCapsule drivers, and stand-alone tools.
The company says each mechanism can be useful:
- 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.
However, writing firmware updates for each individual component protocol is time consuming. Microsoft decided to create Component Firmware Update as a standard protocol. It can be users in all the company’s update drivers and components with CFU support.
Only a single component in a group need to be compatible with CFU for the protocol to work. That’s because CFU pushes subcomponent firmware to be spread from the primary component to non-CFU components.
Open Source
Microsoft is continuing its push towards open source solutions. Redmond is sharing CFU, its driver sample, firmware sample, and tool sample codes. The company wants developers to use the protocol to manage easier firmware update to Windows Update.
In its blog post, Microsoft explained the tenents it used when developing CFU:
- Update must occur with little or no user disruption – no “update mode” that requires the user to wait or even be aware that an update is taking place.
- Update must be delivered through Windows Update drivers.
- The update must be able to wait to update a device until it becomes available.
- Drivers must not have to “know” specifics of any update package other than which component device to send it to.
- Evaluation of the appropriateness of the update lies with the component receiving it, not in the driver.
- Target must be able to reject firmware before it is downloaded if it is inappropriate.
- Update must permit third-party versioning schemes to be mapped to a standardized versioning scheme.
