dfu-util: Support for DFU ST extensions (DfuSe)

[Tormod Volden]

Hi,

The code for supporting ST Microelectronics DFU extensions (DfuSe) is
now ready. It can be found in the dfuse-libusb-1.0 branch of
https://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util - I
recommend fetching it and viewing it with for instance "git instaweb"
instead of reading the commits on gitorious because they list the
commits out of commit order (I think they appear by author date and I
did some rebasing).

The code has been tested on several devices:
- DSO Nano pocket oscilloscope, whose IAP loader is based on STM32 USB
FS Device Library 1.0.
This was my original target application and many DSO Nano owners on
Linux or Mac have happily been using the early code. ST only provides
their own Windows loader application...
- Custom device using the DFU example in STM32 USB FS Device Library 3.1.0.
- STM32F107 which has a DFU boot loader in ROM (thanks Uwe Bonnes for
testing this!)
- STM32F105 was tested on an earlier version of the code (thanks
Sebastian Pfeiffer)

One question is if you prefer to merge my tree or just add the final
files (there are just small changes to main.c the rest is separate
files). My git history reflects the development from early hacks and
some back and forth changes and parallel development with master and
libusb-1.0 branches over time so they will mess up the "main" history.
On the other hand there is some explanations in the commit logs that
might help people understand things - ideally the code would be
self-explaining though. I am not sure what is the best way, I
originally thought I would submit the final files, but merging is part
of the power of git also...

My branch does not include updated documentation and man pages, I can
add this after the merge. I can also add more inline code
documentation at a later point.

Finally there are some outstanding patches that I have submitted for
the master branch. These are not needed for the DfuSe merge, but the
last in the list will currently not merge cleanly against the DfuSe
branch, so it should either be refreshed and applied after merging, or
I am happy to rebase the DfuSe branch after the patch has been applied
to master, to avoid merge conflicts. Actually, since that patch might
need some testing, I'd suggest to put it on hold. The rest is
relatively safe to apply.

55ae521 main: Make descriptor helper functions more generic
3d60f5b dfu-util.1: --device option never needed hex prefix
5d6e5a8 main: Move DFU state transition blocks together

Looking forward to your comments and to finally make the DfuSe support
"official"!

Cheers,
Tormod

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

[Stefan Schmidt-2]

Hello.

On Wed, 2011-10-05 at 21:52, Tormod Volden wrote:
>
> The code for supporting ST Microelectronics DFU extensions (DfuSe) is
> now ready. It can be found in the dfuse-libusb-1.0 branch of
> https://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util - I
> recommend fetching it and viewing it with for instance "git instaweb"
> instead of reading the commits on gitorious because they list the
> commits out of commit order (I think they appear by author date and I
> did some rebasing).

Many many thanks for this. I will review this in the week after the
20th. I'm finishing my diploma thesis right now and barely have spare
cycles to read mail. But be assured that this and your other patches
are on my high priority list after the thesis drop off. :)

> The code has been tested on several devices:
> - DSO Nano pocket oscilloscope, whose IAP loader is based on STM32 USB
> FS Device Library 1.0.
> This was my original target application and many DSO Nano owners on
> Linux or Mac have happily been using the early code. ST only provides
> their own Windows loader application...
> - Custom device using the DFU example in STM32 USB FS Device Library 3.1.0.
> - STM32F107 which has a DFU boot loader in ROM (thanks Uwe Bonnes for
> testing this!)
> - STM32F105 was tested on an earlier version of the code (thanks
> Sebastian Pfeiffer)
>
> One question is if you prefer to merge my tree or just add the final
> files (there are just small changes to main.c the rest is separate
> files). My git history reflects the development from early hacks and
> some back and forth changes and parallel development with master and
> libusb-1.0 branches over time so they will mess up the "main" history.
> On the other hand there is some explanations in the commit logs that
> might help people understand things - ideally the code would be
> self-explaining though. I am not sure what is the best way, I
> originally thought I would submit the final files, but merging is part
> of the power of git also...
>
> My branch does not include updated documentation and man pages, I can
> add this after the merge. I can also add more inline code
> documentation at a later point.
>
> Finally there are some outstanding patches that I have submitted for
> the master branch. These are not needed for the DfuSe merge, but the
> last in the list will currently not merge cleanly against the DfuSe
> branch, so it should either be refreshed and applied after merging, or
> I am happy to rebase the DfuSe branch after the patch has been applied
> to master, to avoid merge conflicts. Actually, since that patch might
> need some testing, I'd suggest to put it on hold. The rest is
> relatively safe to apply.
>
> 55ae521 main: Make descriptor helper functions more generic
> 3d60f5b dfu-util.1: --device option never needed hex prefix
> 5d6e5a8 main: Move DFU state transition blocks together
>
> Looking forward to your comments and to finally make the DfuSe support
> "official"!
>
> Cheers,
> Tormod

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

[Stefan Schmidt-2]

Hello.

On Thu, 2011-10-06 at 13:29, Stefan Schmidt wrote:

> On Wed, 2011-10-05 at 21:52, Tormod Volden wrote:
> >
> > The code for supporting ST Microelectronics DFU extensions (DfuSe) is
> > now ready. It can be found in the dfuse-libusb-1.0 branch of
> > https://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util - I
> > recommend fetching it and viewing it with for instance "git instaweb"
> > instead of reading the commits on gitorious because they list the
> > commits out of commit order (I think they appear by author date and I
> > did some rebasing).
>
> Many many thanks for this. I will review this in the week after the
> 20th. I'm finishing my diploma thesis right now and barely have spare
> cycles to read mail. But be assured that this and your other patches
> are on my high priority list after the thesis drop off. :)

Its done and I finally have time at hand again. :)

I'm going to review and test your patches the next days. I would be
grateful if you could point out any missing patches I may have missed.
What I have scheduled for review right now is the patch adding 1.1
features and the patchset for Dfuse support. Anything else I'm
missing?

regards
Stefan Schmidt

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

[Tormod Volden]

On Mon, Oct 24, 2011 at 12:05 PM, Stefan Schmidt
<[hidden email]> wrote:

> Hello.
>
> On Thu, 2011-10-06 at 13:29, Stefan Schmidt wrote:
>> On Wed, 2011-10-05 at 21:52, Tormod Volden wrote:
>> >
>> > The code for supporting ST Microelectronics DFU extensions (DfuSe) is
>> > now ready. It can be found in the dfuse-libusb-1.0 branch of
>> > https://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util - I
>> > recommend fetching it and viewing it with for instance "git instaweb"
>> > instead of reading the commits on gitorious because they list the
>> > commits out of commit order (I think they appear by author date and I
>> > did some rebasing).
>>
>> Many many thanks for this. I will review this in the week after the
>> 20th. I'm finishing my diploma thesis right now and barely have spare
>> cycles to read mail. But be assured that this and your other patches
>> are on my high priority list after the thesis drop off. :)
>
> Its done and I finally have time at hand again. :)

Hi Stefan,
Congratulations for having your thesis done :)

> I'm going to review and test your patches the next days. I would be
> grateful if you could point out any missing patches I may have missed.
> What I have scheduled for review right now is the patch adding 1.1
> features and the patchset for Dfuse support. Anything else I'm
> missing?

Right, there is the DfuSe support in the dfuse-libusb-1.0 branch
(updated since), then there are three patches in master-patches
branch:

    main: Make descriptor helper functions more generic

    dfu-util.1: --device option never needed hex prefix

    main: Move DFU state transition blocks together

As I wrote on the list, this last one above could need some testing. I
do not know if there was a reason for this status check block to be
placed after the descriptor retrieval and is necessary for some device
or it is just the code that grew like that. IMO if some device need it
this order, it needs to be documented so we do not carry cargo cult.
Therefore I will suggest to go on and applying it if there is no
problem with the devices that we can test, and then deal with any bug
report if it comes along.

Then finally the DFU 1.1 patch which I haven't pushed yet but was
posted on the ML.

Cheers,
Tormod


>
> regards
> Stefan Schmidt
>

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

[Stefan Schmidt-2]

Hello.

On Mon, 2011-10-24 at 12:56, Tormod Volden wrote:

> On Mon, Oct 24, 2011 at 12:05 PM, Stefan Schmidt
> <[hidden email]> wrote:
> > Hello.
> >
> > On Thu, 2011-10-06 at 13:29, Stefan Schmidt wrote:
> >> On Wed, 2011-10-05 at 21:52, Tormod Volden wrote:
> >> >
> >> > The code for supporting ST Microelectronics DFU extensions (DfuSe) is
> >> > now ready. It can be found in the dfuse-libusb-1.0 branch of
> >> > https://gitorious.org/~tormod/unofficial-clones/dfuse-dfu-util - I
> >> > recommend fetching it and viewing it with for instance "git instaweb"
> >> > instead of reading the commits on gitorious because they list the
> >> > commits out of commit order (I think they appear by author date and I
> >> > did some rebasing).
> >>
> >> Many many thanks for this. I will review this in the week after the
> >> 20th. I'm finishing my diploma thesis right now and barely have spare
> >> cycles to read mail. But be assured that this and your other patches
> >> are on my high priority list after the thesis drop off. :)
> >
> > Its done and I finally have time at hand again. :)
>
> Congratulations for having your thesis done :)

Thnaks :)

> > I'm going to review and test your patches the next days. I would be
> > grateful if you could point out any missing patches I may have missed.
> > What I have scheduled for review right now is the patch adding 1.1
> > features and the patchset for Dfuse support. Anything else I'm
> > missing?
>
> Right, there is the DfuSe support in the dfuse-libusb-1.0 branch
> (updated since), then there are three patches in master-patches
> branch:
>
>     main: Make descriptor helper functions more generic
>
>     dfu-util.1: --device option never needed hex prefix
>
>     main: Move DFU state transition blocks together

OK, all three are already in my local repo and I will test them later
today or tomorrow. They rae fine froma review point of view. Only
testing from my side is missing.

> As I wrote on the list, this last one above could need some testing. I
> do not know if there was a reason for this status check block to be
> placed after the descriptor retrieval and is necessary for some device
> or it is just the code that grew like that. IMO if some device need it
> this order, it needs to be documented so we do not carry cargo cult.
> Therefore I will suggest to go on and applying it if there is no
> problem with the devices that we can test, and then deal with any bug
> report if it comes along.

Thats fine with me.

> Then finally the DFU 1.1 patch which I haven't pushed yet but was
> posted on the ML.

I picked that one from the ml as well. Will be in the testing lot like
the others above.

For the DfuSe branch I need a bit more toime to review it and make my
mind up on the best approach for merging it. Hopefully still this week
though.

regards
Stefan Schmidt

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

[Tormod Volden]

On Mon, Oct 24, 2011 at 1:23 PM, Stefan Schmidt
<[hidden email]> wrote:

>> Right, there is the DfuSe support in the dfuse-libusb-1.0 branch
>> (updated since), then there are three patches in master-patches
>> branch:
>>
>>     main: Make descriptor helper functions more generic
>>
>>     dfu-util.1: --device option never needed hex prefix
>>
>>     main: Move DFU state transition blocks together
>
> OK, all three are already in my local repo and I will test them later
> today or tomorrow. They rae fine froma review point of view. Only
> testing from my side is missing.

Did you pull them in now or many weeks ago? In the latter case please
re-pull just in case I did some polishing on them and
rebased/repushed, I cannot tell right now.

> For the DfuSe branch I need a bit more toime to review it and make my
> mind up on the best approach for merging it. Hopefully still this week
> though.

Great! If you decide to apply "main: Move DFU state transition blocks
together" beforehand, let me know and I will update the
dfuse-libusb-1.0 branch accordingly.

Cheers,
Tormod

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

[Stefan Schmidt-2]

Hello.

On Mon, 2011-10-24 at 13:45, Tormod Volden wrote:

> On Mon, Oct 24, 2011 at 1:23 PM, Stefan Schmidt
> <[hidden email]> wrote:
> >> Right, there is the DfuSe support in the dfuse-libusb-1.0 branch
> >> (updated since), then there are three patches in master-patches
> >> branch:
> >>
> >>     main: Make descriptor helper functions more generic
> >>
> >>     dfu-util.1: --device option never needed hex prefix
> >>
> >>     main: Move DFU state transition blocks together
> >
> > OK, all three are already in my local repo and I will test them later
> > today or tomorrow. They rae fine froma review point of view. Only
> > testing from my side is missing.
>
> Did you pull them in now or many weeks ago? In the latter case please
> re-pull just in case I did some polishing on them and
> rebased/repushed, I cannot tell right now.

Two of them some weeks ago. And the other two, deatch and transisition
block patches, today. Will re-pull the first two again.

> > For the DfuSe branch I need a bit more toime to review it and make my
> > mind up on the best approach for merging it. Hopefully still this week
> > though.
>
> Great! If you decide to apply "main: Move DFU state transition blocks
> together" beforehand, let me know and I will update the
> dfuse-libusb-1.0 branch accordingly.

Will let you know. Actually it is very likely that it will go in
before. Just need to pass testing.

regards
Stefan Schmidt

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

[Stefan Schmidt-2]

Hello.

On Mon, 2011-10-24 at 13:45, Tormod Volden wrote:
>
> Great! If you decide to apply "main: Move DFU state transition blocks
> together" beforehand, let me know and I will update the
> dfuse-libusb-1.0 branch accordingly.

No problems showed up during my tests. All four patches have been
applied and pushed.

That only leaves the DfuSe branch outstanding for now. I peaked into
it but did not really started reviewing yet. While git would be fine
mering the branch I'm not going to do this. With the complete
development history and merges it would mess up the history of the
main branch to much. I really see value in keeping a developer history
but in this case I value a sane history on the master branch more.

I hope you understand this. If you want to squash the changes together
into several patches kind of reflecting the history I would be fine
with that. Rebased on current master that is. The other option is to
add the files directly and make it all into one commit. That does not
feel really fair given the amount of work you did put into it though.
Disadvantages for all ways out here it seems.

In my opinion it might be best to squatch the changes into 5 or 10
patches that as a compromise between full history and a signle commit.
What way do you prefer?

regards
Stefan Schmidt

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

[Tormod Volden]

On Mon, Oct 24, 2011 at 6:42 PM, Stefan Schmidt
<[hidden email]> wrote:
> No problems showed up during my tests. All four patches have been
> applied and pushed.

Thanks for testing and applying!

> That only leaves the DfuSe branch outstanding for now. I peaked into
> it but did not really started reviewing yet. While git would be fine
> mering the branch I'm not going to do this. With the complete
> development history and merges it would mess up the history of the
> main branch to much. I really see value in keeping a developer history
> but in this case I value a sane history on the master branch more.

Yes, I agree. An important value of the git history is the possibility
of doing git bisecting if a regression is found. This would be more
complicated if my work is merged as-is. Bisecting the development of
my dfuse work is not so useful, I am pretty confident there are no
regressions, and if there are some today, they can be bisected on my
branch (which will be put to rest, but will stay archived on
gitorious).

> I hope you understand this. If you want to squash the changes together
> into several patches kind of reflecting the history I would be fine
> with that. Rebased on current master that is. The other option is to

I tried squashing some changes together but cannot get it to work. I
wonder if and how I can do this in git:

I started my topic branch at M, and regularly pulled in master (in P and S):

A---B---C---D---E---F---G
 \           \           \
  M---N---O---P---Q---R---S

Now if O is just a fixup of N I would like to squash them, same for Q and R:

A---B---C---D---E---F---G
 \           \           \
  M---N'------P'---Q'-----S'

I have tried with git rebase -p but it did not work, I got merge conflicts.

Any git experts around who can advice me on this?

> add the files directly and make it all into one commit. That does not
> feel really fair given the amount of work you did put into it though.
> Disadvantages for all ways out here it seems.

What about a squashed merge? Please see my master-patches branch where
I tried exactly this. All my work is added in one commit in the master
branch, but the commit description lists all of my original commits.
These commits are also included in the git repo so they can be
referenced by their commit ID. git blame will give me my fair share of
credit as well :)

Still I would have preferred to squash some of these commits, since
they are fix-ups or back-and-forth trials, and only makes the
development difficult to follow.

I also changed some more code at some point (e.g. in dfuload.c) which
I later reverted to make the dfuse addition cleaner, but there was
some merges in between so these can not be easily squashed away even
if I got the above git voodoo to work. Anyway, this is an example of
something that could be useful to keep in (some) history - some day
someone might look at these functions in dfuload.c and dfuse.c and
think they can be merged with a few changes in dfuload.c - then my
older code shows an example of this.

A full rebase (for instance to current master HEAD) is too difficult.
My branch synced with master and libusb branches many times and some
of my work was done in parallel in master along the development. It is
interesting to look at with "gitk" :)

>
> In my opinion it might be best to squatch the changes into 5 or 10
> patches that as a compromise between full history and a signle commit.
> What way do you prefer?

To sum it up, I think a squashed merge will be suitable, but I would
have liked to clean up some of my commits if I only knew how.

Cheers,
Tormod


>
> regards
> Stefan Schmidt

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

[Stefan Schmidt-2]

Hello.

On Tue, 2011-10-25 at 10:55, Tormod Volden wrote:

> On Mon, Oct 24, 2011 at 6:42 PM, Stefan Schmidt <[hidden email]> wrote:
>
> > That only leaves the DfuSe branch outstanding for now. I peaked into
> > it but did not really started reviewing yet. While git would be fine
> > mering the branch I'm not going to do this. With the complete
> > development history and merges it would mess up the history of the
> > main branch to much. I really see value in keeping a developer history
> > but in this case I value a sane history on the master branch more.
>
> Yes, I agree. An important value of the git history is the possibility
> of doing git bisecting if a regression is found. This would be more
> complicated if my work is merged as-is. Bisecting the development of
> my dfuse work is not so useful, I am pretty confident there are no
> regressions, and if there are some today, they can be bisected on my
> branch (which will be put to rest, but will stay archived on
> gitorious).

Sounds good.

> > I hope you understand this. If you want to squash the changes together
> > into several patches kind of reflecting the history I would be fine
> > with that. Rebased on current master that is. The other option is to
>
> I tried squashing some changes together but cannot get it to work. I
> wonder if and how I can do this in git:
>
> I started my topic branch at M, and regularly pulled in master (in P and S):
>
> A---B---C---D---E---F---G
>  \           \           \
>   M---N---O---P---Q---R---S
>
> Now if O is just a fixup of N I would like to squash them, same for Q and R:
>
> A---B---C---D---E---F---G
>  \           \           \
>   M---N'------P'---Q'-----S'
>
> I have tried with git rebase -p but it did not work, I got merge conflicts.
>
> Any git experts around who can advice me on this?

With the explanation below about the merges and work in parallel on
master and the dfuse branch it really looks like git will not be happy
to manually rebase this into a nice patchset.

> > add the files directly and make it all into one commit. That does not
> > feel really fair given the amount of work you did put into it though.
> > Disadvantages for all ways out here it seems.
>
> What about a squashed merge? Please see my master-patches branch where
> I tried exactly this. All my work is added in one commit in the master
> branch, but the commit description lists all of my original commits.
> These commits are also included in the git repo so they can be
> referenced by their commit ID. git blame will give me my fair share of
> credit as well :)

This is actually the first time I hear about a squashed-merge. I
looked at your master-patches branch and it did not look to bad. Sure
the the commitlog is a bit long but the information in there is kept
and the one commit is good for bisection.

> Still I would have preferred to squash some of these commits, since
> they are fix-ups or back-and-forth trials, and only makes the
> development difficult to follow.
>
> I also changed some more code at some point (e.g. in dfuload.c) which
> I later reverted to make the dfuse addition cleaner, but there was
> some merges in between so these can not be easily squashed away even
> if I got the above git voodoo to work. Anyway, this is an example of
> something that could be useful to keep in (some) history - some day
> someone might look at these functions in dfuload.c and dfuse.c and
> think they can be merged with a few changes in dfuload.c - then my
> older code shows an example of this.
>
> A full rebase (for instance to current master HEAD) is too difficult.
> My branch synced with master and libusb branches many times and some
> of my work was done in parallel in master along the development. It is
> interesting to look at with "gitk" :)

Hmm, to bad. Would have been nice to bring this over in nice pieces
while keeping commitlog informations and bisection available but
throwing out test and debug commits.

> > In my opinion it might be best to squatch the changes into 5 or 10
> > patches that as a compromise between full history and a signle commit.
> > What way do you prefer?
>
> To sum it up, I think a squashed merge will be suitable, but I would
> have liked to clean up some of my commits if I only knew how.

Di you try to do a git rebase -i on the branch and remove or squash
some of the commits you want to get rid of? Due to the merges and your
other changes I expect not all of the rebases will work. Maybe some
will work out easily though.

I don't want to put to much work on you for merging this in (you did
already enough with implementing it). I find the problem interesting
though and would like to play with it myself a bit. How about this?
You try some rebase interactive if you are in the mood and I will also
play with your original branch at the weekend. If nothing better shows
up I will just merge you squashed merge from master-patches on sunday.

regards
Stefan Schmidt

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

[Tormod Volden]

On Thu, Oct 27, 2011 at 12:38 AM, Stefan Schmidt
<[hidden email]> wrote:
> Di you try to do a git rebase -i on the branch and remove or squash
> some of the commits you want to get rid of? Due to the merges and your
> other changes I expect not all of the rebases will work. Maybe some
> will work out easily though.

I have tried and using -p, I still have to redo every merge conflict
resolve I had done in the original merges. Which I was hoping to
avoid, since squashing two commits does not change any code from there
on. Maybe "git rerere" is the answer? But it still requires me to redo
the merge conflict resolves once?

> I don't want to put to much work on you for merging this in (you did
> already enough with implementing it). I find the problem interesting
> though and would like to play with it myself a bit. How about this?
> You try some rebase interactive if you are in the mood and I will also
> play with your original branch at the weekend. If nothing better shows
> up I will just merge you squashed merge from master-patches on sunday.

I spent some hours without luck, let's see if you get any further.
Otherwise, yes, let's use my squashed merge and move on.

Cheers,
Tormod


>
> regards
> Stefan Schmidt
>

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

[Stefan Schmidt-2]

Hello.

On Sat, 2011-10-29 at 11:35, Tormod Volden wrote:

> On Thu, Oct 27, 2011 at 12:38 AM, Stefan Schmidt
> <[hidden email]> wrote:
> > Di you try to do a git rebase -i on the branch and remove or squash
> > some of the commits you want to get rid of? Due to the merges and your
> > other changes I expect not all of the rebases will work. Maybe some
> > will work out easily though.
>
> I have tried and using -p, I still have to redo every merge conflict
> resolve I had done in the original merges. Which I was hoping to
> avoid, since squashing two commits does not change any code from there
> on. Maybe "git rerere" is the answer? But it still requires me to redo
> the merge conflict resolves once?

I've given up after an hour as well. :(

This remembers me why I normally have only short term branches and do
even rebasing on them. Of course this has other disadvantages like
loosing history. :(

> > I don't want to put to much work on you for merging this in (you did
> > already enough with implementing it). I find the problem interesting
> > though and would like to play with it myself a bit. How about this?
> > You try some rebase interactive if you are in the mood and I will also
> > play with your original branch at the weekend. If nothing better shows
> > up I will just merge you squashed merge from master-patches on sunday.
>
> I spent some hours without luck, let's see if you get any further.
> Otherwise, yes, let's use my squashed merge and move on.

Agreed. It might still be possible to get this sorted out, but after
both of us spending time on it I think it is not worth the effort.
Better use the time for more productive things. :)

Now for the review. I'm hapopy to see that they at least have choosen
a different DFU version to distinguish DfuSe from standard DFU. I
still need to get out the spec from the windows driver package to read
up on it, but I trust you on this part anyway. I'm also happy to see
how minimal the impact in main.c is to support this extension. (Thanks
to all the ground work you did earlier).

So, all in all I'm happy to get this merged. Test with my devices
showed up no regressions. I pulled it into master and if no problems
show up the next days will make a new release later this week. Thanks
again for this major contribution!

I wonder what would be the cheapest/easiast available device using DfuSe and
being compatible with your implementation. A full pocket oscilloscope might
be a bit overkill for playing with it. Any cheap devel board available
having the DfuSe enabled bootloader installed?

regards
Stefan Schmidt

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

[David Morris-3]

Unsubscribe

Sent from my mobile


On 31 Oct 2011, at 09:09, Stefan Schmidt <[hidden email]> wrote:

> Hello.
>
> On Sat, 2011-10-29 at 11:35, Tormod Volden wrote:
>> On Thu, Oct 27, 2011 at 12:38 AM, Stefan Schmidt
>> <[hidden email]> wrote:
>>> Di you try to do a git rebase -i on the branch and remove or squash
>>> some of the commits you want to get rid of? Due to the merges and your
>>> other changes I expect not all of the rebases will work. Maybe some
>>> will work out easily though.
>>
>> I have tried and using -p, I still have to redo every merge conflict
>> resolve I had done in the original merges. Which I was hoping to
>> avoid, since squashing two commits does not change any code from there
>> on. Maybe "git rerere" is the answer? But it still requires me to redo
>> the merge conflict resolves once?
>
> I've given up after an hour as well. :(
>
> This remembers me why I normally have only short term branches and do
> even rebasing on them. Of course this has other disadvantages like
> loosing history. :(
>
>>> I don't want to put to much work on you for merging this in (you did
>>> already enough with implementing it). I find the problem interesting
>>> though and would like to play with it myself a bit. How about this?
>>> You try some rebase interactive if you are in the mood and I will also
>>> play with your original branch at the weekend. If nothing better shows
>>> up I will just merge you squashed merge from master-patches on sunday.
>>
>> I spent some hours without luck, let's see if you get any further.
>> Otherwise, yes, let's use my squashed merge and move on.
>
> Agreed. It might still be possible to get this sorted out, but after
> both of us spending time on it I think it is not worth the effort.
> Better use the time for more productive things. :)
>
> Now for the review. I'm hapopy to see that they at least have choosen
> a different DFU version to distinguish DfuSe from standard DFU. I
> still need to get out the spec from the windows driver package to read
> up on it, but I trust you on this part anyway. I'm also happy to see
> how minimal the impact in main.c is to support this extension. (Thanks
> to all the ground work you did earlier).
>
> So, all in all I'm happy to get this merged. Test with my devices
> showed up no regressions. I pulled it into master and if no problems
> show up the next days will make a new release later this week. Thanks
> again for this major contribution!
>
> I wonder what would be the cheapest/easiast available device using DfuSe and
> being compatible with your implementation. A full pocket oscilloscope might
> be a bit overkill for playing with it. Any cheap devel board available
> having the DfuSe enabled bootloader installed?
>
> regards
> Stefan Schmidt
>
> _______________________________________________
> devel mailing list
> [hidden email]
> https://lists.openmoko.org/mailman/listinfo/devel

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

[linvnguyen]

Unsubscribe

Sent from my iPod

On 31-10-2011, at 20:56, David Morris <[hidden email]> wrote:

> Unsubscribe
>
> Sent from my mobile
>
>
> On 31 Oct 2011, at 09:09, Stefan Schmidt <[hidden email]> wrote:
>
>> Hello.
>>
>> On Sat, 2011-10-29 at 11:35, Tormod Volden wrote:
>>> On Thu, Oct 27, 2011 at 12:38 AM, Stefan Schmidt
>>> <[hidden email]> wrote:
>>>> Di you try to do a git rebase -i on the branch and remove or squash
>>>> some of the commits you want to get rid of? Due to the merges and your
>>>> other changes I expect not all of the rebases will work. Maybe some
>>>> will work out easily though.
>>>
>>> I have tried and using -p, I still have to redo every merge conflict
>>> resolve I had done in the original merges. Which I was hoping to
>>> avoid, since squashing two commits does not change any code from there
>>> on. Maybe "git rerere" is the answer? But it still requires me to redo
>>> the merge conflict resolves once?
>>
>> I've given up after an hour as well. :(
>>
>> This remembers me why I normally have only short term branches and do
>> even rebasing on them. Of course this has other disadvantages like
>> loosing history. :(
>>
>>>> I don't want to put to much work on you for merging this in (you did
>>>> already enough with implementing it). I find the problem interesting
>>>> though and would like to play with it myself a bit. How about this?
>>>> You try some rebase interactive if you are in the mood and I will also
>>>> play with your original branch at the weekend. If nothing better shows
>>>> up I will just merge you squashed merge from master-patches on sunday.
>>>
>>> I spent some hours without luck, let's see if you get any further.
>>> Otherwise, yes, let's use my squashed merge and move on.
>>
>> Agreed. It might still be possible to get this sorted out, but after
>> both of us spending time on it I think it is not worth the effort.
>> Better use the time for more productive things. :)
>>
>> Now for the review. I'm hapopy to see that they at least have choosen
>> a different DFU version to distinguish DfuSe from standard DFU. I
>> still need to get out the spec from the windows driver package to read
>> up on it, but I trust you on this part anyway. I'm also happy to see
>> how minimal the impact in main.c is to support this extension. (Thanks
>> to all the ground work you did earlier).
>>
>> So, all in all I'm happy to get this merged. Test with my devices
>> showed up no regressions. I pulled it into master and if no problems
>> show up the next days will make a new release later this week. Thanks
>> again for this major contribution!
>>
>> I wonder what would be the cheapest/easiast available device using DfuSe and
>> being compatible with your implementation. A full pocket oscilloscope might
>> be a bit overkill for playing with it. Any cheap devel board available
>> having the DfuSe enabled bootloader installed?
>>
>> regards
>> Stefan Schmidt
>>
>> _______________________________________________
>> devel mailing list
>> [hidden email]
>> https://lists.openmoko.org/mailman/listinfo/devel
>
> _______________________________________________
> devel mailing list
> [hidden email]
> https://lists.openmoko.org/mailman/listinfo/devel

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

[Michael 'Mickey' Lauer-2]

> Unsubscribe

ERROR 42: This is a mailing list for humans, not a listserver.

Please read the footer of this E-Mail, it contains information
about how to unsubscribe.

Cheers,

:M:


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

[Tormod Volden]

On Mon, Oct 31, 2011 at 10:09 AM, Stefan Schmidt wrote:

> Now for the review. I'm hapopy to see that they at least have choosen
> a different DFU version to distinguish DfuSe from standard DFU. I
> still need to get out the spec from the windows driver package to read
> up on it, but I trust you on this part anyway. I'm also happy to see
> how minimal the impact in main.c is to support this extension. (Thanks
> to all the ground work you did earlier).
>
> So, all in all I'm happy to get this merged. Test with my devices
> showed up no regressions. I pulled it into master and if no problems
> show up the next days will make a new release later this week. Thanks
> again for this major contribution!

Great! Looking forward to directing everybody to the official 0.5 release.

> I wonder what would be the cheapest/easiast available device using DfuSe and
> being compatible with your implementation. A full pocket oscilloscope might
> be a bit overkill for playing with it. Any cheap devel board available
> having the DfuSe enabled bootloader installed?

- At $90, the DSO Nano 2 oscilloscope is the coolest device if you are
into (low frequency) electronics :)
http://www.seeedstudio.com/depot/dso-nano-v2-p-681.html

- If you have a JTAG adapter, you can get any STM32F1xx development
board and burn the DfuSe IAP loader yourself. For example a Maple
board http://leaflabs.com/ or compatible
http://www.olimex.com/dev/olimexino-stm32.html or the simple, compact
http://www.olimex.com/dev/stm32-h103.html both at 20€.

The cheapest STM32 device is the STM32 Discovery development board,
but that might need some soldering to get to work - it actually has
one main development STM32 and another STM32 acting as the debug
bridge for USB. I don't know if both are capable of running the IAP
loader, the first would need an extra USB socket, the second would
need sacrificing the debug link.

- The STM32F105/107 chips have the DfuSe loader in ROM, so that should
be much easier. And more RAM/flash.
I think this header board from Olimex should work:
http://www.olimex.com/dev/stm32-h107.html for 25€. But with shipping
added you're half the way to a DSO with LCD screen etc... It really
depends if you imagine doing something else than testing dfu-util on
it :)

Cheers,
Tormod

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

[Stefan Schmidt-2]

Hello.

On Mon, 2011-10-31 at 21:01, Tormod Volden wrote:

> On Mon, Oct 31, 2011 at 10:09 AM, Stefan Schmidt wrote:
> > Now for the review. I'm hapopy to see that they at least have choosen
> > a different DFU version to distinguish DfuSe from standard DFU. I
> > still need to get out the spec from the windows driver package to read
> > up on it, but I trust you on this part anyway. I'm also happy to see
> > how minimal the impact in main.c is to support this extension. (Thanks
> > to all the ground work you did earlier).
> >
> > So, all in all I'm happy to get this merged. Test with my devices
> > showed up no regressions. I pulled it into master and if no problems
> > show up the next days will make a new release later this week. Thanks
> > again for this major contribution!
>
> Great! Looking forward to directing everybody to the official 0.5 release.

Planned for wednesday or thursday at the moment. That will also void
my excuse for not getting some minor other things ready for a 0.6
release then.

> > I wonder what would be the cheapest/easiast available device using DfuSe and
> > being compatible with your implementation. A full pocket oscilloscope might
> > be a bit overkill for playing with it. Any cheap devel board available
> > having the DfuSe enabled bootloader installed?
>
> - At $90, the DSO Nano 2 oscilloscope is the coolest device if you are
> into (low frequency) electronics :)
> http://www.seeedstudio.com/depot/dso-nano-v2-p-681.html

Hmm, not sure I can convience myself needed it. There are cases where
I need an oscilloscope but during my studies I had access to some nice
lab equipment so now real need for an own oscilloscope. :) This may
have changed now that I finished studies. We will see.

> - If you have a JTAG adapter, you can get any STM32F1xx development
> board and burn the DfuSe IAP loader yourself. For example a Maple
> board http://leaflabs.com/ or compatible
> http://www.olimex.com/dev/olimexino-stm32.html or the simple, compact
> http://www.olimex.com/dev/stm32-h103.html both at 20€.

Interesting. Leaflabs is already using dfu-util but without the DfuSe
extension I think. That means they have adifferent implementation for
it on the same board. Being able to have both DFU version available
would be nice. JTAG is no problem at all. Sounds like a good
investment. :)

> The cheapest STM32 device is the STM32 Discovery development board,
> but that might need some soldering to get to work - it actually has
> one main development STM32 and another STM32 acting as the debug
> bridge for USB. I don't know if both are capable of running the IAP
> loader, the first would need an extra USB socket, the second would
> need sacrificing the debug link.
>
> - The STM32F105/107 chips have the DfuSe loader in ROM, so that should
> be much easier. And more RAM/flash.
> I think this header board from Olimex should work:
> http://www.olimex.com/dev/stm32-h107.html for 25€. But with shipping
> added you're half the way to a DSO with LCD screen etc... It really
> depends if you imagine doing something else than testing dfu-util on
> it :)

Sure, thats the question. Most of the devices I for dfu-util are
really for testing only. I will go with a leaflabs boards first and
consider the DSO nano later again I think. :)

regards
Stefan Schmidt

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