Windows Update Firmware

0 views
Skip to first unread message

Sadie

unread,
Jul 25, 2024, 12:19:24 AM7/25/24
to rufchiepaha

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.

windows update firmware


Download Zip 🆗 https://urllie.com/2zMChE



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.

Also no one can tell you if it is safe for you to update the BIOS to vF.27 now, unless someone read this discussion that has the same model notebook as yours, has already successfully or not successfully installed the update and can report the results.

Personally, I don't like the new method of these BIOS updates being given to us automatically, but I have to accept that as the new way of doing business, because you do not receive any release notes regarding the BIOS update like you get on the PC's support page.

I have tried to install BIOS update 1.26.0 via Windows Update in December 2023. The installation do not succeed properly, when I restart my HP Elite X2 G4, updating system appeared on the boot screen, then after booted, Windows 11 notified that the system needed to be restarted.

i have check this firmware 1.37.0 bot on Windows Update Catalog and HP support site, firmware 1.27.0.0 is not available on both sites. So I afraid that th3 updat3 will not run properly from what offered from Windows Update. I may haveto wail until HP release this BIOS 2.37.0.0 on HP download site.

after completed the installati9n, I open Windows Update - Advance Option, then select HP Inc. - Firmware - 1.27.0.0 to install it. Windows Update download and install the update,then show install completed.

i updated it and now i am suffering from booting problem, since that update my laptop cant restart immediately after a shutdown nor it can restart which is basically also a shutdown and restart and also whenever it goes to sleep mode it won't wake up, all i can see is capslock blinking and black screen with cooling fan running can you help me with that? can i downgrade successfully or should i wait for an other firmware update which might fix this problem. rightnow i am afraid to give it any bios update because any update will ask for a restart which i cant provide and interrenting bios with a restart problem can cause my bios to currept

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.

4a15465005
Reply all
Reply to author
Forward
0 new messages