[U-Boot] non-blocking flash functions - is this possible/acceptable?

Jerry Van Baren gerald.vanbaren at ge.com
Tue Oct 27 16:57:12 CET 2009


Wolfgang Wegner wrote:
> Hi Jerry,
> 
> On Tue, Oct 27, 2009 at 10:03:49AM -0400, Jerry Van Baren wrote:
>> Jerry Van Baren wrote:
>>> Wolfgang Wegner wrote:
> [...]
>>>> we have an update protocol that normally relies on data being
>>>> received while the previous block is written to flash.
> [...]
>> By the way, what sort of benefit do you see?  What is your load time 
>> with and without the non-blocking changes?
> 
> I am not sure if I understand what you mean, or if we are talking
> about different things.

Yes, you are addressing my question.  I was probing for your use case 
and results.

> Our update protocol starts the update and immediately starts sending
> data over the (relatively slow) serial line. During the data is
> transferred, the first flash block is erased (first operation "in
> background"), and after the data for the complete flash block
> arrived, this data is written to flash and the next block is erased
> (again an operation "in background"), while the data transfer over
> the serial line continues.

I was thinking in terms of TFTP - quite fast.  Your device is 
transferring the data it over the serial link - very slow.  This means 
you data transfer is slow even relative to a flash erase operation, so 
this gives a substantial speed improvement.

[snip]

> Regards,
> Wolfgang

Thanks,
gvb


More information about the U-Boot mailing list