[Cc'ing the dfu-util list instead of myself, full thread on http://u-boot.10912.n7.nabble.com/A-proposal-hack-for-an-efficient-USB-DFU-f...]
On Fri, Mar 14, 2014 at 11:42 AM, Krishna Pattabiraman wrote:
On Fri, Mar 14, 2014 at 9:52 AM, Lukasz Majewski wrote:
Ok, so there is the current code:
do { ret = dfu_get_status(dif, &dst); if (ret < 0) { errx(EX_IOERR, "Error during download get_status"); goto out_free; } if (dst.bState == DFU_STATE_dfuDNLOAD_IDLE || dst.bState == DFU_STATE_dfuERROR) break; /* Wait while device executes flashing */ milli_sleep(dst.bwPollTimeout); } while (1);And the code you refer in your webpage: http://codelectron.wordpress.com/2014/02/28/flexible-firmware-upgrade/ do { ret = dfu_get_status(dif->dev_handle, dif->interface, &dst); if (ret < 0) { fprintf(stderr, "Error during download get_status\n"); goto out_free; } if (dst.bState == DFU_STATE_dfuDNLOAD_IDLE || dst.bState == DFU_STATE_dfuERROR) break; /* Wait while device executes flashing */ if (quirks & QUIRK_POLLTIMEOUT) milli_sleep(DEFAULT_POLLTIMEOUT); else milli_sleep(dst.bwPollTimeout); } while (1);
I'm a bit confused here, since it looks like the milli_sleep(DEFAULT_POLLTIMEOUT); is already removed.
Am I missing something?
The DEFAULT_POLLTIMEOUT is now applied inside dfu_get_status() so that is as before. However this default value is only used for a few devices with explicit quirks applied in dfu-util. For u-boot the bwPollTimeout value returned by the boot loader is used.
No not in the code. Yes they are different code but what I am speaking about in the blog is the removal of the whole block and removing the corresponding states in u-boot also. I have also given the reasons for it in the blog.
Then it would not be DFU any longer. The DFU standard mandates a DFU_GETSTATUS request after the DFU_DNLOAD request, and that the host should wait bwPollTimeout milliseconds before sending requests to the device again*. If u-boot does not need any time on its own here, it should return a zero bwPollTimeout.
*) The standard says "wait between the status phase of the next DFU_DNLOAD and the subsequent solicitation of the device's status via DFU_GETSTATUS", however many devices only initiates the actual flashing/erasing/etc after the DFU_GETSTATUS requests and can therefore set this value specifically for the current request.
Regards, Tormod
I developed it keeping in mind a situation in field where there can be a complete change in memory organisation.
Maybe some special alt setting could be defined for such a behavior in u-boot? We can think about that if it solves a real problem.
Its a difference between a partition table style vs free style. My reason for choosing the latter was
- The partition table is actually inside the linux kernel and to change
partition, we need upgrade to u-boot-env as well as Linux kernel. Risk of bricking was higher. Like here http://lxr.free-electrons.com/source/arch/arm/mach-omap2/board-omap3beagle.c...
- I used SAM9G45 and for normal booting of Linux and U-boot for upgrade and
other maintanence purpose. http://free-electrons.com/blog/at91bootstrap-linux/ .
I haven't considered other types of storage devices and boards, but I think that the concept is very same for other devices too.
I'm happy, that you had shared this fresh view.
Do you have any other ideas for improvements?
Yes, When you plug the DFU enabled device to PC as per standard it should show as Device Firware Updrade in the Device class. Device manager in windows and any similar appplication in other OS will show that. I haven't checked the current implementation in U-boot. It can be done by changing the configuration descriptor in the USB driver. The class is FE and sub class is 01 you can refer here http://www.usb.org/developers/defined_class/#BaseClassFEh .
Thank you for your time.
Krishna www.codelectron.com