| Message ID | 1444912462-3949-8-git-send-email-maxime.ripard@free-electrons.com |
|---|---|
| State | Accepted |
| Delegated to: | Tom Rini |
| Headers | show |
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@free-electrons.com> Reviewed-by: Tom Rini <trini@konsulko.com>
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@free-electrons.com> > Reviewed-by: Tom Rini <trini@konsulko.com> Applied to u-boot/master, thanks!
diff --git a/common/aboot.c b/common/aboot.c index 6c35d8226903..7f412ac0ad4f 100644 --- a/common/aboot.c +++ b/common/aboot.c @@ -264,8 +264,8 @@ static void sparse_put_data_buffer(sparse_buffer_t *buffer) free(buffer); } -int store_sparse_image(sparse_storage_t *storage, - void *storage_priv, void *data) +int store_sparse_image(sparse_storage_t *storage, void *storage_priv, + unsigned int session_id, void *data) { unsigned int chunk, offset; sparse_header_t *sparse_header; diff --git a/common/fb_mmc.c b/common/fb_mmc.c index c9f2ed6b5863..c6989668ae5b 100644 --- a/common/fb_mmc.c +++ b/common/fb_mmc.c @@ -96,8 +96,9 @@ static void write_raw_image(block_dev_desc_t *dev_desc, disk_partition_t *info, fastboot_okay(response_str, ""); } -void fb_mmc_flash_write(const char *cmd, void *download_buffer, - unsigned int download_bytes, char *response) +void fb_mmc_flash_write(const char *cmd, unsigned int session_id, + void *download_buffer, unsigned int download_bytes, + char *response) { block_dev_desc_t *dev_desc; disk_partition_t info; @@ -151,7 +152,8 @@ void fb_mmc_flash_write(const char *cmd, void *download_buffer, printf("Flashing sparse image at offset " LBAFU "\n", info.start); - store_sparse_image(&sparse, &sparse_priv, download_buffer); + store_sparse_image(&sparse, &sparse_priv, session_id, + download_buffer); } else { write_raw_image(dev_desc, &info, cmd, download_buffer, download_bytes); diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c index 5703decfd360..9af0372007bb 100644 --- a/drivers/usb/gadget/f_fastboot.c +++ b/drivers/usb/gadget/f_fastboot.c @@ -51,6 +51,7 @@ static inline struct f_fastboot *func_to_fastboot(struct usb_function *f) } static struct f_fastboot *fastboot_func; +static unsigned int fastboot_flash_session_id; static unsigned int download_size; static unsigned int download_bytes; static bool is_high_speed; @@ -393,6 +394,15 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request *req) sprintf(str_num, "0x%08x", CONFIG_FASTBOOT_BUF_SIZE); strncat(response, str_num, chars_left); + + /* + * This also indicates the start of a new flashing + * "session", in which we could have 1-N buffers to + * write to a partition. + * + * Reset our session counter. + */ + fastboot_flash_session_id = 0; } else if (!strcmp_l1("serialno", cmd)) { s = getenv("serial#"); if (s) @@ -555,9 +565,11 @@ static void cb_flash(struct usb_ep *ep, struct usb_request *req) strcpy(response, "FAILno flash device defined"); #ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV - fb_mmc_flash_write(cmd, (void *)CONFIG_FASTBOOT_BUF_ADDR, + fb_mmc_flash_write(cmd, fastboot_flash_session_id, + (void *)CONFIG_FASTBOOT_BUF_ADDR, download_bytes, response); #endif + fastboot_flash_session_id++; fastboot_tx_write_str(response); } #endif diff --git a/include/aboot.h b/include/aboot.h index a2b0694190d9..0382f5bd2639 100644 --- a/include/aboot.h +++ b/include/aboot.h @@ -32,4 +32,4 @@ static inline int is_sparse_image(void *buf) } int store_sparse_image(sparse_storage_t *storage, void *storage_priv, - void *data); + unsigned int session_id, void *data); diff --git a/include/fb_mmc.h b/include/fb_mmc.h index 402ba9b1b470..978a1395a185 100644 --- a/include/fb_mmc.h +++ b/include/fb_mmc.h @@ -4,6 +4,7 @@ * SPDX-License-Identifier: GPL-2.0+ */ -void fb_mmc_flash_write(const char *cmd, void *download_buffer, - unsigned int download_bytes, char *response); +void fb_mmc_flash_write(const char *cmd, unsigned int session_id, + void *download_buffer, unsigned int download_bytes, + char *response); void fb_mmc_erase(const char *cmd, char *response);
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@free-electrons.com> --- common/aboot.c | 4 ++-- common/fb_mmc.c | 8 +++++--- drivers/usb/gadget/f_fastboot.c | 14 +++++++++++++- include/aboot.h | 2 +- include/fb_mmc.h | 5 +++-- 5 files changed, 24 insertions(+), 9 deletions(-)