DFU compliance and dfu-util « LeafLabs Garden

DFU compliance and dfu-util

(16 posts) (5 voices)

Started 3 years ago by tormod
Latest reply from mbolivar

tormod
Member

Hi Maple developers,

I came across this issue with Maple and latest dfu-util http://forums.leaflabs.com/topic.php?id=1369. It turns out the Maple firmware declares itself as a DFU 1.1a device, which is not true. Our latest release dfu-util 0.5 includes support for DFU 1.1a (DfuSe), and will now fail to work with Maple.

I have sent patches to your info@ address to correct the version (to 1.1) in your firmware. However, we know there are so many Maple devices out there with the broken version, and we can not expect everybody to upgrade the bootloader since it is a bit more complicated than a normal "sketch" upload. So we would like to make amendments (quirks) to dfu-util to handle these devices as the 1.1 devices they really are. To avoid issues with future firmware revisions that might be 1.1a for real, I have also suggested a follow-up patch to bump the bcdDevice value of the firmware, so that our quirks can be limited to the old bcdDevice value.

Have these patches been received by the right developers? Are there any mailing list where patches can be sent for (hopefully public) review?

We want to support as many DFU compliant devices as possible, and especially a cool project like the Maple, so we look forward to working with you to make all Maple DFU devices work flawlessly with dfu-util. If someone among you would be willing to test our development versions, especially before releases, on your Maple devices that would be particularly helpful.

Best regards,
Tormod

Posted 3 years ago #
tormod
Member

Some questions relevant for our dfu-util quirk:
I see in the maple-bootloader git repo that the same version error exist in many different devices. Will product ID 0003 cover them all? Are they all currently at bcdDevice 2.00?

BTW has your vendor ID 1eaf been registered? It does not show up on e.g. http://www.linux-usb.org/usb.ids

Posted 3 years ago #
tonghuix
Member

When I upgrade to Ubuntu 12.04 I have the same question about dfu-util. So please correct it more soon, because it will release by the end of April.

By now, I should remove dfu-util 0.5 every time and install 0.3 instead.

Posted 3 years ago #
tormod
Member

Due to lack of follow-up from LeafLabs (they only responded once to an e-mail a month ago and said they would try it out) this could not be fixed in time for Ubuntu 12.04. For now we have made a quirk in (upstream) dfu-util for product ID 0003. We hope this will help, although a clarification from LeafLabs would be nice. This is included in dfu-util 0.6, about to be announced. For Ubuntu (10.04 or later) you can get an unofficial package from my PPA at https://launchpad.net/~tormodvolden/+archive/ppa

Posted 3 years ago #

tormod
Member

It seems very difficult to communicate with LeafLabs, so I will post the patch for the Maple firmware here also. Seeing in recent threads that other developers want to base their bootloaders on the Maple code, it would be good to have these bugs fixed.

In lack of attachment features on this forum I will try to inline the patch:

From: Tormod Volden <debian.tormod@gmail.com>
Date: Thu,  1 Mar 2012 23:05:40 +0100
Subject: [PATCH 1/2 maple-bootloader] Correct bcdDFUVersion and wDetachTimeOut in DFU functional descriptor

The firmware matches pretty much the DFU 1.1 specification.

This is a follow up of 95e1150ddcbb6e0e4c4e2ff9f85a0e6d9d620407
which only changed the separately defined u8_usbFunctionalDescriptor
but not the one included in the configuration descriptor. And which
also got it wrong (0.1).

(Ideally the code should be cleaned up to only specify this in one place)

Also fix the detach timeout which was set to 64 seconds. I believe
the intended value was 255 ms like stated in the comment. Since the
Maple devices are not detached (transition between run-time mode and
DFU mode, issued over the DFU interface), this is not used anyway.

Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
---

 usb_descriptor.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/usb_descriptor.c b/usb_descriptor.c
index e88efe8..8e001e2 100644
--- a/usb_descriptor.c
+++ b/usb_descriptor.c
@@ -71,10 +71,10 @@ u8 u8_usbFunctionalDescriptor[9] =
     0x21,   /* DFU Functional Descriptor*/
     0x01,   /*bmAttribute, can only download for now */
     0xFF,   /*DetachTimeOut= 255 ms*/
-    0xFF,
+    0x00,
     (wTransferSize & 0x00FF),
     (wTransferSize & 0xFF00) >> 8, /* TransferSize = 1024 Byte*/
-    0x1A,                          /* bcdDFUVersion*/
+    0x10,                          /* bcdDFUVersion = 1.1 */
     0x01
   };

@@ -129,11 +129,11 @@ u8 u8_usbConfigDescriptorDFU[36] =
     0x21,   /* DFU Functional Descriptor*/
     0x01,   /*bmAttribute, can only download for now */
     0xFF,   /*DetachTimeOut= 255 ms*/
-    0xFF,
+    0x00,
     (wTransferSize & 0x00FF),
     (wTransferSize & 0xFF00) >> 8, /* TransferSize = 1024 Byte*/
-    0x01,                          /* bcdDFUVersion*/
-    0x00
+    0x10,                          /* bcdDFUVersion = 1.1 */
+    0x01
     /***********************************************************/
     /*36*/
   };
--
1.7.0.4

Posted 3 years ago #

tormod
Member

And this is the suggested follow-up patch:

From: Tormod Volden <debian.tormod@gmail.com>
Date: Thu,  1 Mar 2012 23:05:41 +0100
Subject: [PATCH 2/2] Bump the bcdDevice to 2.01 now that the DFU descriptor is fixed

To let DFU programmers such as dfu-util know that they can trust
the DFU functional descriptor on this device.

Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
---

This will make it possible for us to include a quirk in dfu-util
to override the reported DFU version if bcdDevice == 2.00. From
bcdDevice 2.01 on, we will believe the device :)

 usb_descriptor.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/usb_descriptor.c b/usb_descriptor.c
index 8e001e2..34140d2 100644
--- a/usb_descriptor.c
+++ b/usb_descriptor.c
@@ -50,7 +50,7 @@ u8 u8_usbDeviceDescriptorDFU[18] =
     PROD_ID0,   /* idProduct (0x1001 or 1002) */
     PROD_ID1,

-    0x00,   /* bcdDevice*/
+    0x01,   /* bcdDevice*/
     0x02,
     0x01,   /* iManufacturer : index of string Manufacturer  */
     0x02,   /* iProduct      : index of string descriptor of product*/
--
1.7.0.4

Posted 3 years ago #

mbolivar
LeafLabs

hey, sorry! thank you very much for your work. will apply.

edit: tested this today (5/15/2012); will commit the patches to each board's branch

edit 2: pushed. while this is too late for the most recent batch of boards (we apologize!), i'll stick a note in the command-line toolchain docs saying "either use an old dfu-util or re-flash the bootloader". thanks again!

https://github.com/leaflabs/maple-bootloader/compare/b19de99d59...6a47cf0c4f
https://github.com/leaflabs/maple-bootloader/compare/d329633e1c...c86a46008c
https://github.com/leaflabs/maple-bootloader/compare/f159a9012f...83bd6a4b48
https://github.com/leaflabs/maple-bootloader/compare/a718e0805c...70dc66ec41

Posted 3 years ago #
tormod
Member

Great! Not sure why you changed the patch authorship to yourself though.

Please say in the docs to use the newest dfu-util. Version 0.6 includes a quirk for the broken firmware. The next version will have the same quirk, but only apply it when bcdDevice == 2.00.

Posted 3 years ago #
ala42
Member

Version 0.6 did not work with the maple boot loader in my test.
It did work with the STM32F4 built in boot loader, but the command line reset option did not reset the CPU. Can not tell if this is a problem of V0.6 or the boot loader.

Posted 3 years ago #
tormod
Member

ala42, please run dfu-util with -v -v -v so that we can see what "did not work".

The STM32F4 built-in loader is using DfuSe (1.1a). I would not be surprised if the reset option did not work on it. Some DfuSe devices simply cannot reset themselves from DFU mode, and I am not sure the dfu-util tries hard enough either.

Posted 3 years ago #
ventosus
Member

I switched from version 0.3 to 0.6 and can confirm that the quirks in version 0.6 work fine with a Maple Mini r3, which has the unfixed firmware and did not run with version 0.5.

Posted 3 years ago #
mbolivar
LeafLabs

Great! Not sure why you changed the patch authorship to yourself though.

Please say in the docs to use the newest dfu-util. Version 0.6 includes a quirk for the broken firmware. The next version will have the same quirk, but only apply it when bcdDevice == 2.00.

I committed them myself since they were provided as raw patch files. You'll notice that the Signed-off-by: lines are still yours; I've only added Acked-by: lines for myself. According to my interpretation of the DCO, a sign-off can be used to convey authorship.

Reading the manpage for git commit, I see now that I can provide author information on a per-commit basis. This was an honest mistake, and I do apologize. I've added a CREDITS file attributing the DFU fixes to you:

https://github.com/leaflabs/maple-bootloader/commit/cb8b7abfa059c7266bb6e023fe0c22342cbb0e01

Thanks again for the patches!

Edit: I've added warnings to the docs telling users they need recent versions of dfu-util:

https://github.com/leaflabs/leaflabs-docs/commit/70a209816930cb920a2071081931db37c60f5725

These have been pushed to the current command line toolchain quickstart:

http://leaflabs.com/docs/unix-toolchain.html

Posted 3 years ago #
tormod
Member

If you use "git am" you will preserve author and author date. That works even if you copy the above patches from the forum post and paste it to "git am". Or from mail, just pipe the message to git am, or save the "Show original" text in a file and use git am on it.

In the docs you say "uploads" but it is really "downloads". You download to a device from a computer.

Posted 3 years ago #
mbolivar
LeafLabs

If you use "git am" you will preserve author and author date. That works even if you copy the above patches from the forum post and paste it to "git am". Or from mail, just pipe the message to git am, or save the "Show original" text in a file and use git am on it.

Thanks. I'm unfamiliar with Git's email/patch features, but I will use this in the future.

In the docs you say "uploads" but it is really "downloads". You download to a device from a computer.

I agree that the distinction between uploading and downloading can be ambiguous in situations like this, but "upload" is correct here, at least according to Wikipedia: "Technically, if the user uses the receiving device to initiate the transfer, then it would be a download and if they used the sending device to initiate, it would be an upload."

http://en.wikipedia.org/wiki/Uploading_and_downloading#Sideload

Posted 3 years ago #
tormod
Member

For DFU there is no ambiguity :)

http://www.usb.org/developers/devclass_docs/usbdfu10.pdf

Posted 3 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.