upstream u-boot with additional patches for our devices/boards: https://lists.denx.de/pipermail/u-boot/2017-March/282789.html (AXP crashes) ; Gbit ethernet patch for some LIME2 revisions ; with SPI flash support
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
u-boot/include/image-sparse.h

36 lines
804 B

/*
* Copyright 2014 Broadcom Corporation.
*
* SPDX-License-Identifier: GPL-2.0+
*/
#include <part.h>
#include <sparse_format.h>
#define ROUNDUP(x, y) (((x) + ((y) - 1)) & ~((y) - 1))
typedef struct sparse_storage {
unsigned int block_sz;
unsigned int start;
unsigned int size;
const char *name;
int (*write)(struct sparse_storage *storage, void *priv,
unsigned int offset, unsigned int size,
char *data);
} sparse_storage_t;
static inline int is_sparse_image(void *buf)
{
sparse_header_t *s_header = (sparse_header_t *)buf;
if ((le32_to_cpu(s_header->magic) == SPARSE_HEADER_MAGIC) &&
(le16_to_cpu(s_header->major_version) == 1))
return 1;
return 0;
}
int store_sparse_image(sparse_storage_t *storage, void *storage_priv,
fastboot: Implement flashing session counter 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>
9 years ago
unsigned int session_id, void *data);