What have you found as the most appropriate mechanism for keeping the firmware and driver in sync?
In the past I have hardcoded the firmware image into the driver and had the driver perform the firmware update if the expected version doesn’t match. This works well when (a) the update is fast (b) doesn’t require a system reset for the new firmware to load.
I have also had my installer run a firmware updater utility at the end of installation to check for any hardware that needs firmware updates in order for the newly installed driver to work. This works well if the hardware is attached at the time of installation, but does nothing for a software only installation.
Its a USB Device ? Try read the DFU spec for some ideas :
http://www.usb.org/developers/docs/devclass_docs/DFU_1.1.pdf
I don’t think that keeping the firmware image within the driver is a good
idea :
a. It put your driver in a very strange state of handling the downloading
of the firmware while stay “unplugged”
b. it will require a re-testing for WHQL each firmware.
c. the driver may run early and you may not be able to indicate the user
that a firmware update is in progress (maybe the user doesn’t want to
update its hardware ?)
Having said that, I really think the best ideas is to fetch firmwares from
your website and try to upgrade the firmware from a stand-alone
service/application providing full user interaction (if needed) that will
solve problem b and c.
DFU idea is to switch the device into a firmware upgrade state which then
the hardware is identify by a different device instance. Letting you
install a “DFU driver” that only expose the DFU interface. that solves
problem a.
My 2 cents
On Wed, Feb 4, 2015 at 3:12 AM, wrote:
> What have you found as the most appropriate mechanism for keeping the
> firmware and driver in sync?
>
> In the past I have hardcoded the firmware image into the driver and had
> the driver perform the firmware update if the expected version doesn’t
> match. This works well when (a) the update is fast (b) doesn’t require a
> system reset for the new firmware to load.
>
> I have also had my installer run a firmware updater utility at the end of
> installation to check for any hardware that needs firmware updates in order
> for the newly installed driver to work. This works well if the hardware is
> attached at the time of installation, but does nothing for a software only
> installation.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Another answer of “it depends”, I’m afraid.
Your solution of “build the driver with the firmware and push the firmware if it’s newer” is a good one… for the cases you mentioned.
To ME, the main question is whether the system can boot with a mismatch between your driver and the firmware version (in either direction). If the answer is yes, then your life is sooo much easier.
IMHO, firmware and drivers should always be “backwards compatible”… that is, a newer firmware version should always be able to accommodate an older driver version. When that’s NOT the case, change the REV number of the device. And newer drivers should always be able to accommodate older firmware.
So the “it’s broken, the system won’t boot” problem is fixed… NOW you just need to worry about features and fixes.
The question HERE becomes how you let the user know that there’s a newer firmware or driver version. A helper service can be your savior here.
Just some random thoughts…
Peter
OSR
@OSRDrivers
@Elad
In this case I’m actually referring to a PCI device. Yes you are correct, if we were WHQL testing the device it would require a retest for each firmware change.
I think implementing configuration over protocol would simplify a lot of these problems, but we haven’t implemented that in our hardware at this point.
@Peter
The system can boot just fine with a mismatch of driver and firmware. I can choose to either fail my driver load if a mismatch is detected, or automatically program the firmware with the hardcoded image in the driver. Failing driver load means the user has to do some troubleshooting to figure out why their device isn’t working. Automatically programming the firmware makes the user vulnerable if they reset power during the process (which can take 30 seconds). If a system reset happens before the firmware is updated, the PCI device is bricked and requires reprogramming at the factory. Worse yet, with supplementing the driver with some utility, I have no way to inform the user that a firmware update is in progress and they need to hang tight. I hate to install yet another service to their system that runs dormant for 99.9% of it’s life just for the sake of managing firmware updates more gracefully.
Regarding the firmware/driver being backwards compatible, this specific situation is to add a new feature. The firmware has to implement the feature and the driver has expose a new way to enable/disable the feature. Functionality of the device is still maintained for everything but the new feature should a firmware/driver mismatch occur.