microsoft / CFU

Component Firmware Update
MIT License
59 stars 27 forks source link

error when running FwUpdateCfu.exe version #39

Closed lgdacunha closed 5 years ago

lgdacunha commented 5 years ago

The keyboard ids of my Microsoft Surface Book Gen 1 matchs the example configuration with VID=045e and PID=07cd I tried FwUpdateCfu.exe version with the configuration example on this Microsoft Surface Book Gen 1 , but I am getting "Error Device not found or not working". What steps I am missing to get the FwUpdateCfu.exe version to run?

fwupdatecfu_outputwin

chboro commented 5 years ago

Thank you for your question. I'm unsure of which collection and usage you are trying to communicate with however it looks as if you are attempting to address the HID Keyboard Device instead of 'Vendor Defined Device'. Can you post the protocolCfg file you are using please?

The process is designed to talk to vendor specific utility collections and each vendor can and will assign different usage pages and usages to implement the CFU protocol. If you are attempting to open the collection that contains the Keyboard specific usages (and therefore not Vendor Defined), cfu will not be implemented on these usages.

Additionally HID protects certain usages from allowing shared handles. This is true in the case of keyboards and other input devices to prevent applications without focus from reading the keyboard input and stealing confidential information such as passwords.

lgdacunha commented 5 years ago

I am trying the default configuration with no changes that is in: https://github.com/Microsoft/CFU/blob/master/Tools/ComponentFirmwareUpdateStandAloneToolSample/protocolCfgExample.cfg and on: https://github.com/Microsoft/CFU/blob/master/Tools/ComponentFirmwareUpdateStandAloneToolSample/README.md

Here is the configuration for your reference: VID,0x045e,#mandatory (each vendor must maintain their own Vendor defined Utility Page collections) PID,0x07cd,#optional USAGEPAGE,0xFF07,#mandatory (each vendor must maintain their own Vendor defined Utility Page collections) USAGECOLLECTION,0x31,#optional (if you don't specify, the tool will attempt to talk to all devices with matching UsagePage/Vid/Pid on the usages specified below) VERSION_FEATURE_USAGE,0x62,#mandatory for all procedures CONTENT_OUTPUT_USAGE,0x61,#mandatory for fwUpdate procedure CONTENT_RESPONSE_INPUT_USAGE,0x66,#mandatory for fwUpdate procedure OFFER_OUTPUT_USAGE,0x8e,#mandatory for fwUpdate procedure OFFER_RESPONSE_INPUT_USAGE,0x8a,#mandatory for fwUpdate procedure

This default configuration seems to be a perfect match to the Surface Keyboard.

You mean I have to change the Keyboard driver stack to get it work with CFU or that Keyboards will not work with CFU?

NathanS-Microsoft commented 5 years ago

Also, each vendor must also use their own vendor ID, not 045E. That's ours.

Get Outlook for Androidhttps://aka.ms/ghei36


From: lgdacunha notifications@github.com Sent: Friday, February 15, 2019 11:15:52 AM To: Microsoft/CFU Cc: Subscribed Subject: Re: [Microsoft/CFU] error when running FwUpdateCfu.exe version (#39)

I am trying the default configuration with no changes that is in: https://github.com/Microsoft/CFU/blob/master/Tools/ComponentFirmwareUpdateStandAloneToolSample/protocolCfgExample.cfghttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FCFU%2Fblob%2Fmaster%2FTools%2FComponentFirmwareUpdateStandAloneToolSample%2FprotocolCfgExample.cfg&data=02%7C01%7Cnathans%40microsoft.com%7Cfa305118e20247d901fb08d6937a009e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636858549535292319&sdata=ka0sqNDHqXzXM%2FyL8jRrBF5Kl4D5Z%2BNsTx2tysCGSVc%3D&reserved=0 and on: https://github.com/Microsoft/CFU/blob/master/Tools/ComponentFirmwareUpdateStandAloneToolSample/README.mdhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FCFU%2Fblob%2Fmaster%2FTools%2FComponentFirmwareUpdateStandAloneToolSample%2FREADME.md&data=02%7C01%7Cnathans%40microsoft.com%7Cfa305118e20247d901fb08d6937a009e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636858549535292319&sdata=7tivI909urPIu3UHlyGshTUEatm4RfUhkqWkkw0v1%2Fs%3D&reserved=0

Here is the configuration for your reference: VID,0x045e,#mandatory (each vendor must maintain their own Vendor defined Utility Page collections) PID,0x07cd,#optional USAGEPAGE,0xFF07,#mandatory (each vendor must maintain their own Vendor defined Utility Page collections) USAGECOLLECTION,0x31,#optional (if you don't specify, the tool will attempt to talk to all devices with matching UsagePage/Vid/Pid on the usages specified below) VERSION_FEATURE_USAGE,0x62,#mandatory for all procedures CONTENT_OUTPUT_USAGE,0x61,#mandatory for fwUpdate procedure CONTENT_RESPONSE_INPUT_USAGE,0x66,#mandatory for fwUpdate procedure OFFER_OUTPUT_USAGE,0x8e,#mandatory for fwUpdate procedure OFFER_RESPONSE_INPUT_USAGE,0x8a,#mandatory for fwUpdate procedure

This default configuration seems to be a perfect match to the Surface Keyboard.

You mean I have to change the Keyboard driver stack to get it work with CFU or that Keyboards will not work with CFU?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2FCFU%2Fissues%2F39%23issuecomment-464166355&data=02%7C01%7Cnathans%40microsoft.com%7Cfa305118e20247d901fb08d6937a009e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636858549535302316&sdata=5V1NAZrt3hI1E5nLWCNN6sGub%2FJb3LyFP1NTovNmed8%3D&reserved=0, or mute the threadhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAqMLeiuDPnLKrlQbmMcyVTBjwlqxquodks5vNwdogaJpZM4a4N_-&data=02%7C01%7Cnathans%40microsoft.com%7Cfa305118e20247d901fb08d6937a009e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636858549535302316&sdata=BqoCDmQQSx8YPr9PjwHGmq63fvvzH8gAfIej%2FktJtSQ%3D&reserved=0.

chboro commented 5 years ago

The configuration file exists to define the specific items that the FW device has implemented. Just because a device has a Vendor Defined Usage Page FF07, doesn't actually mean that it has implemented CFU.

Your job as the system designer is to reserve usage pages and usages that don't have collisions with any other devices from your Vendor ID (such as 0x045E always representing a Microsoft device). Once you have a unique Usage page for your device or family of devices, you can decide which usage top level collection to assign to different functionality, and which usages each of those usages perform. For example vendor XYZ might reserve FF17:15 to their Gadget Q for the purposes of CFU. Instead of usage 0x61, 62, 66, 8e, 8a they might have chosen 1, 2, 3, 4, 5. FF17:16 TLC might do all of their debug logging protocol. FF17:17 might be all of their custom command and control interface.

So in this example, you have found a device exposing usage page FF07 from Microsoft (0x045e) and it has exposed some usages. But you don't know what those usages actually expose (could be command and control, or CFU, or debugging, or something entirely different).

You can potentially iterate through the other vendor defined hid devices and see what usage pages they expose and change your settings in the cfg to match. You might even find one that responds 'correctly' to usage 0x62 as a feature report that has the correct payload length. That data might come back as something that looks reasonable and looks like a version number. However it could also just be a different usage that represents 60 bytes of payload for serial number or state of charge or .....

Does this clear things up or muddy it up more?

lgdacunha commented 5 years ago

It didn't clear things up except maybe that CFU may apply to a very specific subset of devices. Can you point me to the fundametal specifications that the devices that will be supported by CFU must adere? Is it USB, I2C, what else?

Is there any CFU example code that is ready to run, that I can check the user/administrator experience it will provide?

chboro commented 5 years ago

I cannot provide you any documentation other than the one provided here at this time:

https://github.com/Microsoft/CFU/blob/master/Documentation/CFU-Protocol/Component%20Firmware%20Update%20Protocol%20Specification.docx

Theoretically however the protocol can be applied to many transports including USB, i2c, Bluetooth, etc.

Do you mean FW side CFU example code? No we do not have an ready to go samples. The sample code would not be portable because it has to be custom to the transport, processor arch, memory constraints, scheduler concerns, operating system (if any), frameworks (if any), etc.

It could apply to all FW update processes however it doesn't. Each vendor creating their FW update process can choose to go this route or any other route that meets their requirements and system design.

pankajbharti commented 5 years ago

lgdacunha,

Kindly look at the video on Component Firmware Update here -- https://developer.microsoft.com/en-us/windows/hardware/events

I suspect the source of the confusion is that you are assuming that you can talk to any HID TLD device for CFU purposes.

The device that you are trying to talk to using the CFU tool needs to be CFU aware. That means, that the device has to expose a HID TLC specifically for CFU purposes. Let me call it CFU TLC. The CFU TLC would be different than a TLC for keyboard functionality. The CFU tool could only talk to CFU TLC. You as a device manufacturer would provide your own vendor specific UP / U to that TLC.

I think the video link i shared should help you understand this.

Thanks, Pankaj Gupta

lgdacunha commented 5 years ago

Thanks Pankaj,

The video was very insightful!