[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-for-linux-based-boards-td175319.html#a175947]
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
> 1. 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?v=2.6.36#L53
>
> 2. 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
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
