On Mon, Dec 19, 2011 at 3:37 PM, Stefan Schmidt <ste...@datenfreihafen.org> wrote: > Hello. > > On Mon, 2011-12-19 at 00:07, Tormod Volden wrote: >> From: Tormod Volden <debian.tor...@gmail.com> >> >> Also remove unused debug code. >> >> Signed-off-by: Tormod Volden <debian.tor...@gmail.com> > > Applied and pushed this one.
Thanks! > >> This patch, and two patches previously posted, >> main: List alternate interfaces in DFU mode >> main: Simplify --detach handling by reusing existing code >> are also available on >> https://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util/commits/master-patches > > I think we can both agree that I was to slow on these. :) Yes, one problem is that I meanwhile forget what these patches are about :) > > I had another look and tested them. Sadly the simplify detch handling > code works only from run to dfu and not from dfu to run mode. It was > quite handy to have both transistions with the original approach. "Detach" is to transition from run-time mode to DFU mode. There simply is no "detach" from DFU mode to run-time mode. You want a command to toggle between these two modes? Well, some devices can (from DFU mode) reset themselves (and thus end up in run-time mode) in the manifestation. However I am not sure a device can enter manifestation state without doing some downloading. Please see the state diagram on page 28 of the DFU 1.1 specification. On what kind of device were you toggling back and forth between DFU to run-time? It must be the result of some non-conformance or accidental side effect. > > For the other patch I'm a bit unclear what benefit it brings over just > doing the list mode in DFU. Having the full list when doing list in > run time mode would be handy but involves a mode transition I'm not > suere I'm happy to do without explicit user request. You would like to do the list mode only in DFU mode? That would mean a mode transition (assuming the device is in run-time mode), which I, like you also express in your last phrase, would not be happy about. A user probing the device using the -l option should not force any device transition IMO. But I don't think we understand each other here :) Let's talk about user cases, to make it clear what we want to do. One example would be a device, that follows the DFU specification and in run-time mode, lists one DFU interface with alternate setting zero. The spec says it must be zero in run-time (Table 4.1). However, in DFU mode it lists one DFU interface with several alternate settings, one for each memory bank or something like that (Table 4.4). The user will try to download a firmware image. He first runs dfu-util -l and sees one DFU interface (with the single zero alternate setting). So he does not specify -a. However, after detaching to DFU mode, the device presents all alternate settings. Since dfu-util sees several possibilities, and the user did not specify with -a, it will with my patch, display the list of alternate settings and quit. Then the user can rerun dfu-util, now with the -a setting of his choice. The device is now already in DFU mode but that is not a problem, since dfu-util detects the mode and skips the detach sequence. The selected alternate setting is used and the correct memory bank/etc is programmed. > > Doing a detach, a list of available alt interfaces and then a switch > back to run-time might be doable but so far I was happy with having This is not easily doable, and might even impossible as I explain above, at least for standard DFU devices. > these tasks in separate calls. > > regards > Stefan Schmidt Cheers, Tormod _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
