[PATCH dfu-util] dfuse_mem.c: Add reference to relevant ST document

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PATCH dfu-util] dfuse_mem.c: Add reference to relevant ST document

Tormod Volden
From: Tormod Volden <[hidden email]>

Also remove unused debug code.

Signed-off-by: Tormod Volden <[hidden email]>
---

Hi,

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

Regards,
Tormod



 src/dfuse_mem.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/dfuse_mem.c b/src/dfuse_mem.c
index 379d6fd..395070b 100644
--- a/src/dfuse_mem.c
+++ b/src/dfuse_mem.c
@@ -76,6 +76,9 @@ void free_segment_list(struct memsegment *segment_list)
  free(segment_list);
 }
 
+/* Parse memory map from interface descriptor string
+ * encoded as per ST document UM0424 section 4.3.2.
+ */
 struct memsegment *parse_memory_layout(char *intf_desc)
 {
 
@@ -90,9 +93,6 @@ struct memsegment *parse_memory_layout(char *intf_desc)
  struct memsegment *segment_list = NULL;
  struct memsegment segment;
 
-#ifdef DEBUG_DRY
- intf_desc = "@fake /0x08000000/12*001Ka,11*001Kg,9*2Ka,24*4Kg";
-#endif
  name = malloc(strlen(intf_desc));
  if (!name) {
  fprintf(stderr, "Error: Cannot allocate memory\n");
--
1.7.5.4


_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH dfu-util] dfuse_mem.c: Add reference to relevant ST document

Stefan Schmidt-2
Hello.

On Mon, 2011-12-19 at 00:07, Tormod Volden wrote:
> From: Tormod Volden <[hidden email]>
>
> Also remove unused debug code.
>
> Signed-off-by: Tormod Volden <[hidden email]>

Applied and pushed this one.

> 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. :)

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.

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.

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
these tasks in separate calls.

regards
Stefan Schmidt

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH dfu-util] dfuse_mem.c: Add reference to relevant ST document

Tormod Volden
On Mon, Dec 19, 2011 at 3:37 PM, Stefan Schmidt
<[hidden email]> wrote:

> Hello.
>
> On Mon, 2011-12-19 at 00:07, Tormod Volden wrote:
>> From: Tormod Volden <[hidden email]>
>>
>> Also remove unused debug code.
>>
>> Signed-off-by: Tormod Volden <[hidden email]>
>
> 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
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH dfu-util] dfuse_mem.c: Add reference to relevant ST document

Stefan Schmidt-2
Hello.

On Mon, 2011-12-19 at 23:38, Tormod Volden wrote:

> On Mon, Dec 19, 2011 at 3:37 PM, Stefan Schmidt
> <[hidden email]> wrote:
> >
> >> 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 :)

:)

Lets see that we get it sorted out then. :)

> > 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.

You hit the nail here. :)

I tested it with with the U-Boot implementation and other devices that
seem to implement the reset in DFU mode. Not really was thinking about
the spec here that does not specify this. My bad. :)

I'm checking with a bluetooth dongle now and will apply your patch
then. Thanks for taking the time and patience to explain this.

> > 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.

OK. We agree that we don't want any mode transition without explicit
user request. The rest is real misunderstanding, indeed. :)

> 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).

Correct. The usual behaviour.

> 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.

Ah, ok. It lists the alternate settings only in DFU mode when now
argument is given for -a. Makes sense. Will test and apply.

> > 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.

Agreed. I just tested it and it worked with some
devices/implementations but it slipped my mind that it is not
guaranteed/designed by the spec. Thus your solution makes more sense
here.

regards
Stefan Schmidt

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
Loading...