[U-Boot] [U-Boot, v2, 07/14] fastboot: Implement flashing session counter

[Tom Rini]

On Thu, Oct 15, 2015 at 02:34:15PM +0200, Maxime Ripard wrote:

> The fastboot flash command that writes an image to a partition works in
> several steps:
> 
> 1 - Retrieve the maximum size the device can download through the
>     "max-download-size" variable
> 
> 2 - Retrieve the partition type through the "partition-type:%s" variable,
>     that indicates whether or not the partition needs to be erased (even
>     though the fastboot client has minimal support for that)
> 
> 3a - If the image is smaller than what the device can handle, send the image
>      and flash it.
> 
> 3b - If the image is larger than what the device can handle, create a
>      sparse image, and split it in several chunks that would fit. Send the
>      chunk, flash it, repeat until we have no more data to send.
> 
> However, in the 3b case, the subsequent transfers have no particular
> identifiers, the protocol just assumes that you would resume the writes
> where you left it.
> 
> While doing so works well, it also means that flashing two subsequent
> images on the same partition (for example because the user made a mistake)
> would not work withouth flashing another partition or rebooting the board,
> which is not really intuitive.
> 
> Since we have always the same pattern, we can however maintain a counter
> that will be reset every time the client will retrieve max-download-size,
> and incremented after each buffer will be flashed, that will allow us to
> tell whether we should simply resume the flashing where we were, or start
> back at the beginning of the partition.
> 
> Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
> Reviewed-by: Tom Rini <trini at konsulko.com>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151112/d0d2c195/attachment.sig>