From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Tue, 27 Oct 2009 11:57:12 -0400 Subject: [U-Boot] non-blocking flash functions - is this possible/acceptable? In-Reply-To: <20091027152218.GB3216@leila.ping.de> References: <20091027125146.GA3216@leila.ping.de> <4AE6F3D5.5060403@ge.com> <4AE6FDC5.5070106@ge.com> <20091027152218.GB3216@leila.ping.de> Message-ID: <4AE71858.20209@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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