[PATCH 4/4 dfu-util] main: Always retrieve the DFU functional descriptor

Tormod Volden lists.tormod at gmail.com
Mon Sep 19 20:51:39 CEST 2011


On Mon, Sep 19, 2011 at 6:58 PM, Stefan Schmidt wrote:
>> Thanks for testing! Interesting. So they do not provide a functional
>> descriptor at all? Can you please send me the sudo lsusb -v output
>> from these devices? Do you have access to their firmware code?
>
> lsusb output is attched.

Thanks! Interestingly, the device does have a functional descriptor
and the OS is able to read it. Maybe it truncates the complete
configuration descriptor and this is why our code fails. Can you
please breakpoint after libusb_get_descriptor() and see what it
returned (ret and cbuf)?

It is possible that libusb already has the descriptor cached so we do
not even have to request it from the device. We will have to look
through the *extra field in the libusb_interface_descriptor. I can try
to cook up a patch for this.

> Its the Openmoko Freerunner again. Source for the DFU u-boot
> implementation is available but device owners are not likely to
> upgrade their bootloaders in the field. Smeels like we need to add
> another quirk for this device.

Yes, we can not rely on updated firmware. We can add a quirk, as small
as possible.

> Having this fixed in the U-boot implemtation is needed as well. I'm
> working on getting a fully working DFU implementation into U-boot
> mainline, but so far I'm only testing it with a beagleboard as
> Freerunner support in mainline U-boot is pretty poor. Maybe we can
> bring this back later...
>
> The u-boot source with dfu for the freerunner can be found here
> (Yeah, a bit of strange git usage in this repo...):
> http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=refs/heads/mokopatches
>
> As for the second version of the patch I gave it a fast test and it
> still fails here:
>
> Opening DFU USB device... ID 1d50:5119
> Warning: failed to retrieve complete configuration descriptor
> Error obtaining DFU functional descriptor
> Warning: Assuming DFU version 1.0
> Run-time device DFU version 100
> Claiming USB DFU Runtime Interface...
> Cannot set alt interface
>

So it seems like just trying to retrieve the functional descriptor
makes its USB stack stale so it can not set the alt interface later?
If we can get the cached descriptor from libusb it would help for
this. On the other hand I do not think we need to (or even should) set
the alternate setting for the run-time device. But it would then
probably still break at the next USB transfer.

> You don't have the Openmoko Freerunner so I need to dig into this
> myself. I'm still short on time on doing so. Hopefully at the weekend.

> Interesting I thought the bitWillDetach was the only addition in the
> 1.1 spec. Seems I have to read it again to fresh up knowledge about
> it. :)

There is not really much to it, it is the class and protocol fields,
which you already have noted in the SPEC-differences.txt file.

>
>> On the other hand, I don't see any way to read the run-time/dfu state
>> from the 1.0 descriptor set, so there is not much we can do about it
>> except making the code acknowledge this incapability and not confuse
>> someone reading the code or using it.
>>
>> In fact there is not much difference between 1.0 and 1.1 so we can
>> safely say we support both. There is the added bitWillDetach in 1.1
>> that we might want to incorporate, by extending or replacing the
>> final_reset option handling at the end of main(). Our handling of the
>> "Manifestation phase" could generally be improved, but it is not
>> critical, as long as the actual flash writing is successful and the
>> device can be reset by hand. I guess this is a weak point in most
>> device implementations as well.
>
> Agreed. Manual reset is not to bad, but we should honor and implement
> bitWillDetach later on. Still some other bugs to get fixed before
> this. :)

I just really want the functional descriptor for now. Then I can add
the DfuSe implementation which I have otherwise finished and don't
want to sit on forever. And it should be time for 0.5 by then.

BTW, it would be great to have a record of lsusb output (and dfu-util
-v -v output) for all the devices we support. Maybe we could add this
to a branch in git?

Regards,
Tormod



More information about the devel mailing list