From lists.tormod at gmail.com Mon Oct 26 20:38:08 2020 From: lists.tormod at gmail.com (Tormod Volden) Date: Mon, 26 Oct 2020 21:38:08 +0100 Subject: [Dfu-util] Patch for activating --upload-size option In-Reply-To: References: Message-ID: On Sat, Sep 5, 2020 at 1:30 AM Jakub Palider wrote: > Hello, > > please, review the patch and, if okay, apply it. > It was tested with some basic scenarios for the upload size and > results are backward compatible and work for relevant parameters: > > Use expected upload size when reading from device > > In order to limit transfer on wires stop transmission when > expected size is reached. Just to update the list on this: After reviewing the DFU_UPLOAD specifications and what our --expected-size option does (simply scale the progress bar), we agreed to drop this patch. Tormod [sorry for breaking the thread, the original post disappeared from my mailbox] From lists.tormod at gmail.com Mon Oct 26 20:45:24 2020 From: lists.tormod at gmail.com (Tormod Volden) Date: Mon, 26 Oct 2020 21:45:24 +0100 Subject: [Dfu-util] call for testing: dfu-util 0.10 RC Message-ID: Hi, I consider the current git head to be a release candidate for the upcoming 0.10 release of dfu-util, so I would be glad to see some testing on various devices. I have tested on STM32F4 and will test some custom IAP bootloaders. There are still known issues on STM32L4 and STMF0, but that has to wait for later releases. Thanks, Tormod From cavokz at gmail.com Tue Oct 27 12:48:38 2020 From: cavokz at gmail.com (Domenico Andreoli) Date: Tue, 27 Oct 2020 13:48:38 +0100 Subject: [Dfu-util] call for testing: dfu-util 0.10 RC In-Reply-To: References: Message-ID: <20201027124838.GA16353@m4> On Mon, Oct 26, 2020 at 09:45:24PM +0100, Tormod Volden wrote: > Hi, Hi, > I consider the current git head to be a release candidate for the > upcoming 0.10 release of dfu-util, so I would be glad to see some > testing on various devices. I have tested on STM32F4 and will test > some custom IAP bootloaders. There are still known issues on STM32L4 > and STMF0, but that has to wait for later releases. Built from git://git.code.sf.net/p/dfu-util/dfu-util. It seem that the -Z switch is ignored, no matter the value I specify the data transferred from the device is 16384. ~/dfu-util.git$ ./src/dfu-util -a0 -Z 1000 -U /tmp/stm32.dfu dfu-util 0.9 Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc. Copyright 2010-2020 Tormod Volden and Stefan Schmidt This program is Free Software and has ABSOLUTELY NO WARRANTY Please report bugs to http://sourceforge.net/p/dfu-util/tickets/ Opening DFU capable USB device... ID 0483:df11 Run-time device DFU version 011a Claiming USB DFU Interface... Setting Alternate Setting #0 ... Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing DFU mode device DFU version 011a Device returned transfer size 2048 Limiting default upload to 16384 bytes Upload [=========================] 100% 16384 bytes Upload done. ~/dfu-util.git$ 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 domenico.andreoli at linux.com Tue Oct 27 09:28:27 2020 From: domenico.andreoli at linux.com (Domenico Andreoli) Date: Tue, 27 Oct 2020 10:28:27 +0100 Subject: [Dfu-util] call for testing: dfu-util 0.10 RC In-Reply-To: References: Message-ID: <20201027092827.GA12343@m4> On Mon, Oct 26, 2020 at 09:45:24PM +0100, Tormod Volden wrote: > Hi, Hi, > I consider the current git head to be a release candidate for the > upcoming 0.10 release of dfu-util, so I would be glad to see some > testing on various devices. I have tested on STM32F4 and will test > some custom IAP bootloaders. There are still known issues on STM32L4 > and STMF0, but that has to wait for later releases. Is this the right repo? git://git.code.sf.net/p/dfu-util/dfu-util 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 Tue Oct 27 19:57:03 2020 From: lists.tormod at gmail.com (Tormod Volden) Date: Tue, 27 Oct 2020 20:57:03 +0100 Subject: [Dfu-util] Forward of moderated message In-Reply-To: References: Message-ID: 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, Yes, correct. It is also listed on the homepage http://dfu-util.sourceforge.net/ The latest commit hash is 5c323e45. > 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? >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
: 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. Regards, Tormod