[U-Boot] A proposal/hack for an efficient USB DFU for linux based boards

[Lukasz Majewski]

Hi Krishna,

> Hi,
> 
> Thanks for your time,
> 
>  Please find following comments:
> 
> >
> > 1. Current solution (u-boot):
> > - It is possible to specify your own "dfu_alt_info" environment
> >   variable when you call dfu command.
> >
> > 2. Speed improvement - section "Making it faster" from:
> > http://codelectron.wordpress.com/2014/02/28/flexible-firmware-upgrade/
> >
> > - I've noticed that you are referring to following dfu-util version:
> > dfu-util - (C) 2007 by Openmoko Inc.
> >
> > It seems to be a bit old one.
> >
> 
> I just used the content from my old documentation, But im referring to
> current implementation.
> 
> 
> > The newest GIT repo can be found at:
> > git://gitorious.org/dfu-util/dfu-util.git
> >
> > I'm referring to following SHA1 (master branch):
> > bda43a52a6c5e9dcd159236553b0d5c511616e77
> >
> > The code at dfuload_do_dnload() function is already rewritten to
> > only wait:
> > milli_sleep(dst.bwPollTimeout);
> >
> > which is correct, since non-zero values are explicitly specified in
> > u-boot (when e.g. target expects that eMMC data will be written).
> >
> > It seems that the proposed improvement is already implemented.
> >
> 
> I dont think its implemented, you can refer here, its the block of
> code what I am referring to,
> 
> https://gitorious.org/dfu-util/dfu-util/source/bda43a52a6c5e9dcd159236553b0d5c511616e77:src/dfu_load.c#L123
> https://gitorious.org/dfu-util/dfu-util/source/bda43a52a6c5e9dcd159236553b0d5c511616e77:src/dfu_load.c#L137

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?

> 
> 
> > As a side note:
> > To improve transmission speed we were even trying to increase the
> > EP0 packet size on HOST machine. Unfortunately it has some
> > limitations (4 KiB if I'm not wrong).
> >
> Yes I do think so about the limitation, as a standard EP0 should
> support atleast 64 bytes and DFU is based on that.
> 
> >
> > Anyway, I'm open for potential DFU transmission speed improvements.
> >
> >
> > 3. Flexibility improvement - section "Making it flexible"
> >
> > The idea of adding headers seems appealing - but there are as usual
> > some corner cases:
> >
> > - Backward compatibility - dfu-util and dfu use number of alt
> > settings to chose the memory region to be written. That is why you
> > observe a lot of alt=X when you type dfu-util -l. We would need
> > some extra switch in the dfu-util to support yours header based
> > approach.
> >
> > - In u-boot we would like to have some degree of control of where
> > and if we flash data. I personally like to specify beforehand (in
> > envs) what parts of memory are available for flashing.
> >
> 
> 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.

> 
> 
> > - Some more complicated schemes shall be considered as well. I've
> > got some pending patches to support eMMC's bootparts flashing via
> > DFU.
> >
> > - Also the header itself only assumes NAND being the backing
> > memory. But we now also alter content of eMMC and RAM with DFU.
> > This is missing.
> >
> > - The information provided by headers is already stored at
> >   "dfu_alt_info" environment variable. It is also used by other
> > gadgets.
> >
> 
> It was an example code based on what I had implemented some time
> back. It was based on nand flash, but the idea will be the same for
> any other  type.
> 
> I just wanted to share the idea of a different type of implementation
> of USB DFU.

I'm happy, that you had shared this fresh view.

Do you have any other ideas for improvements?

> 
> 
> Krishna
> www.codelectron.com



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group