From cavokz at gmail.com  Mon Nov  2 21:54:55 2020
From: cavokz at gmail.com (Domenico Andreoli)
Date: Mon, 2 Nov 2020 22:54:55 +0100
Subject: [Dfu-util] Forward of moderated message
In-Reply-To: <CAArsGaboLbBiBHvSgc8HdFYzcuBZvSVf7Bj0O_XstmHuNgLi-Q@mail.gmail.com>
References: <mailman.0.1603826027.91259.dfu-util@lists.osmocom.org>
 <CAArsGaboLbBiBHvSgc8HdFYzcuBZvSVf7Bj0O_XstmHuNgLi-Q@mail.gmail.com>
Message-ID: <20201102215455.GA5592@m4>

On Tue, Oct 27, 2020 at 08:57:03PM +0100, Tormod Volden wrote:
> On Tue, Oct 27, 2020 at 8:13 PM Domenico wrote:
> > Is this the right repo?
> >
> >   git://git.code.sf.net/p/dfu-util/dfu-util
> 
> Hi Domenico,

Hallo,

> 
> Yes, correct. It is also listed on the homepage http://dfu-util.sourceforge.net/
> The latest commit hash is 5c323e45.

Confirmed. You could also use (signed) git tags.

> 
> > It seem that the -Z switch is ignored, no matter the value I specify
> > the data transferred from the device is 16384.
> 
> > ID 0483:df11
> > Run-time device DFU version 011a
> 
> Thanks for testing! What is this device exactly?

This is an STM32F107VC (Olimex STM32-P107) but I also tested a GD32VF103
(Longan Nano), both are DfuSe devices and I had to use -D in combination
with --dfuse-address.

> 
> From the above, your device seems to be a DfuSe device. In this case
> this is the expected behavior. I would recommend a DfuSe upload,
> specifying -s <address>:<length>

Indeed it worked.

> 
> The standard DFU upload offers no means for the host to request a
> certain length (or start), the device will simply transfer what should
> be the full firmware (or whatever payload that will be). If the host
> terminates the transaction prematurely, the result is undefined. In
> real cases the device will often hang or act up and must be reset. The
> -Z / --upload-size option name is a bit misleading, this only
> specifies an /expected/ payload size that will be used to scale the
> progress bar and nothing else. This was added because there is no way
> for dfu-util to know how long the payload will be.
> 
> Some (all?) DfuSe bootloaders from ST seem to support a sort-of normal
> DFU upload, and will send back a payload without any hint of start
> address from the host. So I have preserved this functionality in
> dfu-util, more as a curiosity. However the bootloader doesn't
> terminate the transfer itself and my testing has shown that the
> bootloader will crash if the upload goes beyond the end of the flash
> memory. I therefore hardcoded a small size that I believe is safe for
> all devices. I should probably add a warning if this kind of upload is
> tried on a DfuSe device.
> 

I just tried to upload a new binary and see if it was being executed
after reset. Anything else you might want me to check?

Regards,
Domenico

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05


From lists.tormod at gmail.com  Mon Nov  9 23:20:59 2020
From: lists.tormod at gmail.com (Tormod Volden)
Date: Tue, 10 Nov 2020 00:20:59 +0100
Subject: [Dfu-util] Forward of moderated message
In-Reply-To: <20201102215455.GA5592@m4>
References: <mailman.0.1603826027.91259.dfu-util@lists.osmocom.org>
 <CAArsGaboLbBiBHvSgc8HdFYzcuBZvSVf7Bj0O_XstmHuNgLi-Q@mail.gmail.com>
 <20201102215455.GA5592@m4>
Message-ID: <CAArsGab6jisnmPyqFD1fyfawUC96KRGZNre647e_qA7qzYmbfg@mail.gmail.com>

On Mon, Nov 2, 2020 at 10:55 PM Domenico Andreoli wrote:
>
> This is an STM32F107VC (Olimex STM32-P107) but I also tested a GD32VF103
> (Longan Nano), both are DfuSe devices and I had to use -D in combination
> with --dfuse-address.
>
> > From the above, your device seems to be a DfuSe device. In this case
> > this is the expected behavior. I would recommend a DfuSe upload,
> > specifying -s <address>:<length>
>
> Indeed it worked.
>
> I just tried to upload a new binary and see if it was being executed
> after reset. Anything else you might want me to check?
>

Hi Domenico,

Thanks a lot for testing on your units. I don't have any particular
idea about what to test more. I think the DfuSe devices are rather
well tested by now.

I have added a warning if someone uses the "undocumented" upload
variant on DfuSe devices.

It seems possible that I can finish the release next weekend. I have
some changes queued up regarding error codes and their propagation but
I will rather land them after the release.

Regards,
Tormod


From lists.tormod at gmail.com  Sat Nov 21 21:17:36 2020
From: lists.tormod at gmail.com (Tormod Volden)
Date: Sat, 21 Nov 2020 22:17:36 +0100
Subject: [Dfu-util] [ANNOUNCE] dfu-util 0.10 released
Message-ID: <CAArsGaZf_xG-xz+LaaPkw6CVG32yd+ktj86HGch01cr+Gtqo9w@mail.gmail.com>

dfu-util 0.10 has been released, and is available from
http://dfu-util.sourceforge.net/ under "Releases".

Thanks to everybody who contributed with patches, testing and bug reporting.

>From the ChangeLog (see git history for full details):

    o New --wait option for devices to appear (J?rg Riechardt)
    o New --devnum option to filter devices (Harald Welte)
    o Support DFU_STATE_dfuMANIFEST_WAIT_RST (J?r?me Hamm)
    o Support large files (Tormod Volden)
    o Quirks for Jabra devices (Niels Skou Olsen)
    o Quirks for OpenPICC, SIMtrace (Harald Welte)
    o Quirks for GD32VF103 (Thomas Hebb)
    o Fix numeric argument parsing (Timo Poikola)
    o Improve alternate interface index matching (Aleks Chakin)
    o Improve libusb error messages (Alex Mastro)
    o Improve Stellaris firmware detection (Aleks Chakin)
    o Improve warnings and debug output (Tormod Volden)
    o Update manual page (Thomas Hebb)
    o Manual pages for dfu-suffix and dfu-prefix (Tormod Volden)
    o Usage text describes DfuSe modifiers (Uwe Bonnes)
    o dfuse: Erase all pages before programming (Geoffrey Hausheer)
    o dfuse: New "will-reset" option (Ievgenii Meshcheriakov)
    o dfuse: Allow 0 as start address (Xavier Domont)
    o dfuse: Workaround for Black Magic Probe issue (Tormod Volden)
    o dfuse: Workaround for STM32L4 page erase stalls (Tormod Volden)
    o dfuse-pack.py: Set (multiple) alternate interfaces (Tormod Volden)
    o dfuse-pack.py: S19 and ihex support (Thilo Cestonaro)
    o dfuse-pack.py: Intel HEX multi-segment index fix (Colin Parker)
    o dfuse-pack.py: Correct DFUImageSize (Hendry Kaak)
    o dfuse-pack.py: Python 3 compatibility (Michael Everitt)

Known / possible issues:
- Some STM32L4 chips may still show stalling issues (#40)
- Building with MSVC hasn't been tested

The binaries package (also in the release folder) includes 32-bit and
64-bit Windows binaries built on MinGW as well as macOS x86_64
binaries built on 10.13.6. It also includes an "lsusb" binary for
these platforms, which might come handy for debugging. Latest git of
libusb was used.

Currently five issues/enhancements are milestoned for the next release:
https://sourceforge.net/p/dfu-util/tickets/milestone/1.1/

Best regards,
Tormod