On Thu, 27 Jun 2013 21:36:09 +0000 (UTC), Tormod Volden wrote: Hi Tormod,
> Lukasz Majewski writes: > > > > This commit fixes problems with some non-standard requests send with > > device address instead of interface address > > (bmRequestType.Receipent field). > > > > This happens with dfu-util (debian version: 0.5), which address non > > standard requests (like w_value=0x21 and bRequest=GET_DESCRIPTOR) > > to device. > > > Dear u-boot developers, > > The above comment seems to imply that dfu-util is sending non-standard > requests. For the record, that would be wrong. dfu-util is sending a > standard "get descriptor" request. These always go to the device, not > to an interface. The descriptor it is asking for is, although not > mandatory per the core USB standard, a class-specific descriptor > which is part of the DFU 1.0 standard. So this is all standard. > > While on this topic, I would recommend that you include this > descriptor in the configuration descriptor set, that is, in the > complete configuration descriptor that the host OS usually requests > during enumeration. Also this class-specific descriptor belongs here. > In that case, the OS and libusb will keep a copy of this descriptor, > and dfu-util will not have to send an explicit request (through > libusb_get_descriptor()) to retrieve it. Thanks for explanation. The commit about which we are discussing was a (reasonable) fix for the problem. I need to look into this and came up with proper solution. > > > > Without this fix, the above request is STALLED, and hence causes > > dfu-util to assume some standard configuration (packet size = 1024B > > instead of 4096B) > > Note that this number is the "Maximum number of bytes that the device > can accept per control-write transaction." I need to check this, but AFAIR there was a problem with dfu-util (and probably libusb under the hood) version 0.1 (shipped with "ancient" old stable debian) and 0.5 which is currently in use. > > The DFU transactions should work fine if a smaller packet size is > used - as long as it is larger or equal to the bMaxPacketSize0. Of > course, smaller packets will cause more overhead and be less > efficient, but you must make sure that your device can handle this. I > am not sure from these comments whether the smaller packet size > caused errors in your implementation, or if the problem was just > reduced performance. The change was driven by the need to improve performance, when downloading large files (with roofts) and to silent warning on the dfu-util side. > > Best regards, > Tormod Volden > > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot