[PATCH 4/4 dfu-util] main: Always retrieve the DFU functional descriptor
stefan at datenfreihafen.org
Tue Sep 20 09:17:23 CEST 2011
On Mon, 2011-09-19 at 20:51, Tormod Volden wrote:
> 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.
Will test your patch and if that does not work dig deeper at the
> > 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.
OK, lets see what we can do to get the issue sorted out to have a
clean path to get the Dfuse support merged in. Everything else can
> 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?
Good idea. I will put together the log and put them into the repo.
Also at the weekend. (Sorry, real no time before for dfu-util work)
More information about the devel