Hello. 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 weekend. > > 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. Agreed. > > 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 wait. > 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) regards Stefan Schmidt _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
