Implement fastboot over NAND

PATCH Superseded Maxime Ripard 8 participants 65 messages Aug 31, 2015 – Sep 14, 2015

Subsystems (3)

USB Memory technology devices (MTD) Arm/Allwinner sunXi SoC support

lore

Share & tools

lore

Maxime Ripard

author

2015-08-31 14:46 UTC #0 lore raw

cover Implement fastboot over NAND

Hi everyone,

Here is the first attempt at getting fastboot flashing functions working on top of a NAND.

While the NAND support itself was quite easy to do, the support for the Android sparse images was quite difficult to add, and ended up being a quite huge refactoring of the sparse parse already in tree, that was tied to the MMC layer.

This serie has been tested on a CHIP and a Cubietruck, two Allwinner devices, the CHIP for the NAND, and the Cubietruck to test the MMC.

Let me know what you think,
Maxime

Maxime Ripard (13):
mtd: uboot: Add meaningful error message
sparse: Move main header parsing to a function of its own
sparse: Refactor chunk parsing function
sparse: Simplify multiple logic
sparse: Implement storage abstraction
fastboot: Move fastboot response functions to fastboot core
fastboot: Implement NAND backend
fastboot: nand: Add pre erase and write hooks
sparse: Rename the file and header
sunxi: Make the fastboot buffer larger
sunxi: Add support for android boot image
sunxi: A13-Olinuxino: Enable the USB OTG controller
sunxi: cubietruck: Enable the USB OTG controller

 common/Makefile                 |   7 +-
 common/aboot.c                  | 244 ---------------------------
 common/fb_mmc.c                 |  82 ++++++----
 common/fb_nand.c                | 219 +++++++++++++++++++++++++
 common/sparse.c                 | 354 ++++++++++++++++++++++++++++++++++++++++
 configs/A13-OLinuXino_defconfig |   2 +
 configs/Cubietruck_defconfig    |   5 +
 drivers/mtd/mtd_uboot.c         |   2 +-
 drivers/usb/gadget/f_fastboot.c |  39 ++++-
 include/configs/sunxi-common.h  |   3 +-
 include/fastboot.h              |  22 +++
 include/fb_nand.h               |  10 ++
 include/{aboot.h => sparse.h}   |  15 +-
 13 files changed, 714 insertions(+), 290 deletions(-)
 delete mode 100644 common/aboot.c
 create mode 100644 common/fb_nand.c
 create mode 100644 common/sparse.c
 create mode 100644 include/fastboot.h
 create mode 100644 include/fb_nand.h
 rename include/{aboot.h => sparse.h} (61%)

Signature · 1 line

2.5.0

Maxime Ripard

author

2015-08-31 14:46 UTC #1 lore raw

PATCH 1/13 mtd: uboot: Add meaningful error message

The current error message in get_part if CONFIG_MTDPARTS is disabled is "offset is not a number" which is confusing and doesn't help at all.

Change that for something that might give a hint on what's going on.

Signed-off-by Maxime Ripard <[email protected]>

---
 drivers/mtd/mtd_uboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/mtd/mtd_uboot.c +1 -1

index c517b9c65d68..21386951efd5 100644
@@ -37,7 +37,7 @@ static int get_part(const char *partname, int *idx, loff_t *off, loff_t *size,
 
 	return 0;
 #else
-	puts("offset is not a number\n");
+	puts("mtdparts support missing.\n");
 	return -1;
 #endif
 }

Signature · 1 line

2.5.0

Tom Rini

2015-09-04 17:20 UTC #2 lore raw

PATCH 1/13 mtd: uboot: Add meaningful error message

Quoted 6 lines · Maxime Ripard

The current error message in get_part if CONFIG_MTDPARTS is disabled is "offset is not a number" which is confusing and doesn't help at all.
Change that for something that might give a hint on what's going on.
Signed-off-by Maxime Ripard <[email protected]>

Reviewed-by Tom Rini <[email protected]>

Signature · 8 lines

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/20150904/c7261006/attachment.sig>

Maxime Ripard

author

2015-08-31 14:46 UTC #3 lore raw

PATCH 2/13 sparse: Move main header parsing to a function of its own

In reply to Maxime Ripard

The current sparse image format parser is quite tangled, with a lot of code duplication.

Start refactoring it by moving the header parsing function to a function of its own.

Signed-off-by Maxime Ripard <[email protected]>

---
 common/aboot.c | 55 +++++++++++++++++++++++++++++--------------------------
 1 file changed, 29 insertions(+), 26 deletions(-)

common/aboot.c +29 ~~-26~~

index fba8e3e683e7..7f12677d13a1 100644
@@ -41,35 +41,12 @@
 #include <part.h>
 #include <sparse_format.h>
 
-void write_sparse_image(block_dev_desc_t *dev_desc,
-		disk_partition_t *info, const char *part_name,
-		void *data, unsigned sz)
+static sparse_header_t *sparse_parse_header(void **data)
 {
-	lbaint_t blk;
-	lbaint_t blkcnt;
-	lbaint_t blks;
-	uint32_t bytes_written = 0;
-	unsigned int chunk;
-	unsigned int chunk_data_sz;
-	uint32_t *fill_buf = NULL;
-	uint32_t fill_val;
-	sparse_header_t *sparse_header;
-	chunk_header_t *chunk_header;
-	uint32_t total_blocks = 0;
-	int i;
-
 	/* Read and skip over sparse image header */
-	sparse_header = (sparse_header_t *) data;
+	sparse_header_t *sparse_header = (sparse_header_t *) *data;
 
-	data += sparse_header->file_hdr_sz;
-	if (sparse_header->file_hdr_sz > sizeof(sparse_header_t))
-	{
-		/*
-		 * Skip the remaining bytes in a header that is longer than
-		 * we expected.
-		 */
-		data += (sparse_header->file_hdr_sz - sizeof(sparse_header_t));
-	}
+	*data += sparse_header->file_hdr_sz;
 
 	debug("=== Sparse Image Header ===\n");
 	debug("magic: 0x%x\n", sparse_header->magic);

@@ -81,6 +58,32 @@ void write_sparse_image(block_dev_desc_t *dev_desc,
 	debug("total_blks: %d\n", sparse_header->total_blks);
 	debug("total_chunks: %d\n", sparse_header->total_chunks);
 
+	return sparse_header;
+}
+
+void write_sparse_image(block_dev_desc_t *dev_desc,
+		disk_partition_t *info, const char *part_name,
+		void *data, unsigned sz)
+{
+	lbaint_t blk;
+	lbaint_t blkcnt;
+	lbaint_t blks;
+	uint32_t bytes_written = 0;
+       unsigned int chunk;
+       unsigned int chunk_data_sz;
+       uint32_t *fill_buf = NULL;
+       uint32_t fill_val;
+	sparse_header_t *sparse_header;
+       chunk_header_t *chunk_header;
+	uint32_t total_blocks = 0;
+	int i;
+
+	sparse_header = sparse_parse_header(&data);
+	if (!sparse_header) {
+		fastboot_fail("sparse header issue\n");
+		return;
+	}
+
 	/* verify sparse_header->blk_sz is an exact multiple of info->blksz */
 	if (sparse_header->blk_sz !=
 	    (sparse_header->blk_sz & ~(info->blksz - 1))) {

Signature · 1 line

2.5.0

Tom Rini

2015-09-04 17:20 UTC #4 lore raw

PATCH 2/13 sparse: Move main header parsing to a function of its own

Quoted 7 lines · Maxime Ripard

The current sparse image format parser is quite tangled, with a lot of code duplication.
Start refactoring it by moving the header parsing function to a function of its own.
Signed-off-by Maxime Ripard <[email protected]>

Reviewed-by Tom Rini <[email protected]>

Signature · 8 lines

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/20150904/d804d691/attachment.sig>

Maxime Ripard

author

2015-08-31 14:46 UTC #5 lore raw

PATCH 3/13 sparse: Refactor chunk parsing function

In reply to Maxime Ripard

The chunk parsing code was duplicating a lot of code among the various chunk types, while all of them could be covered by generic and simple functions.

Refactor the current code to reuse as much code as possible and hopefully make the chunk parsing loop more readable and concise.

Signed-off-by Maxime Ripard <[email protected]>

---
 common/aboot.c | 351 ++++++++++++++++++++++++++++++++++++---------------------
 1 file changed, 221 insertions(+), 130 deletions(-)

common/aboot.c +221 ~~-130~~

index 7f12677d13a1..65e633acfcb9 100644
@@ -37,10 +37,29 @@
 #include <config.h>
 #include <common.h>
 #include <aboot.h>
+#include <errno.h>
 #include <malloc.h>
 #include <part.h>
 #include <sparse_format.h>
 
+static unsigned int sparse_get_chunk_data_size(sparse_header_t *sparse,
+					       chunk_header_t *chunk)
+{
+	return chunk->total_sz - sparse->chunk_hdr_sz;
+}
+
+static bool sparse_chunk_has_buffer(chunk_header_t *chunk)
+{
+	switch (chunk->chunk_type) {
+	case CHUNK_TYPE_RAW:
+	case CHUNK_TYPE_FILL:
+		return true;
+
+	default:
+		return false;
+	}
+}
+
 static sparse_header_t *sparse_parse_header(void **data)
 {
 	/* Read and skip over sparse image header */

@@ -61,6 +80,173 @@ static sparse_header_t *sparse_parse_header(void **data)
 	return sparse_header;
 }
 
+static int sparse_parse_fill_chunk(sparse_header_t *sparse,
+				   chunk_header_t *chunk)
+{
+	unsigned int chunk_data_sz = sparse_get_chunk_data_size(sparse, chunk);
+
+	if (chunk_data_sz != sizeof(uint32_t))
+		return -EINVAL;
+
+	return 0;
+}
+
+static int sparse_parse_raw_chunk(sparse_header_t *sparse,
+				  chunk_header_t *chunk)
+{
+	unsigned int chunk_data_sz = sparse_get_chunk_data_size(sparse, chunk);
+
+	/* Check if the data size is a multiple of the main block size */
+	if (chunk_data_sz % sparse->blk_sz)
+		return -EINVAL;
+
+	/* Check that the chunk size is consistent */
+	if ((chunk_data_sz / sparse->blk_sz) != chunk->chunk_sz)
+		return -EINVAL;
+
+	return 0;
+}
+
+static chunk_header_t *sparse_parse_chunk(sparse_header_t *sparse,
+					  void **image)
+{
+	chunk_header_t *chunk = (chunk_header_t *) *image;
+	int ret;
+
+	debug("=== Chunk Header ===\n");
+	debug("chunk_type: 0x%x\n", chunk->chunk_type);
+	debug("chunk_data_sz: 0x%x\n", chunk->chunk_sz);
+	debug("total_size: 0x%x\n", chunk->total_sz);
+
+	switch (chunk->chunk_type) {
+	case CHUNK_TYPE_RAW:
+		ret = sparse_parse_raw_chunk(sparse, chunk);
+		if (ret)
+			return NULL;
+		break;
+
+	case CHUNK_TYPE_FILL:
+		ret = sparse_parse_fill_chunk(sparse, chunk);
+		if (ret)
+			return NULL;
+		break;
+
+	case CHUNK_TYPE_DONT_CARE:
+	case CHUNK_TYPE_CRC32:
+		debug("Ignoring chunk\n");
+		break;
+
+	default:
+		printf("%s: Unknown chunk type: %x\n", __func__,
+		       chunk->chunk_type);
+		return NULL;
+	}
+
+	*image += sparse->chunk_hdr_sz;
+
+	return chunk;
+}
+
+static int sparse_get_fill_buffer(sparse_header_t *sparse,
+				  chunk_header_t *chunk,
+				  sparse_buffer_t *buffer,
+				  unsigned int blk_sz,
+				  void *data)
+{
+	int i;
+
+	buffer->type = CHUNK_TYPE_FILL;
+
+	/*
+	 * We create a buffer of one block, and ask it to be
+	 * repeated as many times as needed.
+	 */
+	buffer->length = blk_sz;
+	buffer->repeat = (chunk->chunk_sz * sparse->blk_sz) / blk_sz;
+
+	buffer->data = memalign(ARCH_DMA_MINALIGN,
+				ROUNDUP(blk_sz,
+					ARCH_DMA_MINALIGN));
+	if (!buffer->data)
+		return -ENOMEM;
+
+	for (i = 0; i < (buffer->length / sizeof(uint32_t)); i++)
+		((uint32_t *)buffer->data)[i] = *(uint32_t *)(data);
+
+	return 0;
+}
+
+static int sparse_get_raw_buffer(sparse_header_t *sparse,
+				 chunk_header_t *chunk,
+				 sparse_buffer_t *buffer,
+				 unsigned int blk_sz,
+				 void *data)
+{
+	unsigned int chunk_data_sz = sparse_get_chunk_data_size(sparse, chunk);
+
+	buffer->type = CHUNK_TYPE_RAW;
+	buffer->length = chunk_data_sz;
+	buffer->data = data;
+	buffer->repeat = 1;
+
+	return 0;
+}
+
+static sparse_buffer_t *sparse_get_data_buffer(sparse_header_t *sparse,
+					       chunk_header_t *chunk,
+					       unsigned int blk_sz,
+					       void **image)
+{
+	unsigned int chunk_data_sz = sparse_get_chunk_data_size(sparse, chunk);
+	sparse_buffer_t *buffer;
+	void *data = *image;
+	int ret;
+
+	*image += chunk_data_sz;
+
+	if (!sparse_chunk_has_buffer(chunk))
+		return NULL;
+
+	buffer = calloc(sizeof(sparse_buffer_t), 1);
+	if (!buffer)
+		return NULL;
+
+	switch(chunk->chunk_type) {
+	case CHUNK_TYPE_RAW:
+		ret = sparse_get_raw_buffer(sparse, chunk, buffer, blk_sz,
+					    data);
+		if (ret)
+			return NULL;
+		break;
+
+	case CHUNK_TYPE_FILL:
+		ret = sparse_get_fill_buffer(sparse, chunk, buffer, blk_sz,
+					     data);
+		if (ret)
+			return NULL;
+		break;
+
+	default:
+		return NULL;
+	}
+
+	debug("=== Buffer ===\n");
+	debug("length: 0x%x\n", buffer->length);
+	debug("repeat: 0x%x\n", buffer->repeat);
+	debug("type: 0x%x\n", buffer->type);
+	debug("data: 0x%p\n", buffer->data);
+
+	return buffer;
+}
+
+static void sparse_put_data_buffer(sparse_buffer_t *buffer)
+{
+	if (buffer->type == CHUNK_TYPE_FILL)
+		free(buffer->data);
+
+	free(buffer);
+}
+
 void write_sparse_image(block_dev_desc_t *dev_desc,
 		disk_partition_t *info, const char *part_name,
 		void *data, unsigned sz)

@@ -69,12 +255,10 @@ void write_sparse_image(block_dev_desc_t *dev_desc,
 	lbaint_t blkcnt;
 	lbaint_t blks;
 	uint32_t bytes_written = 0;
-       unsigned int chunk;
-       unsigned int chunk_data_sz;
-       uint32_t *fill_buf = NULL;
-       uint32_t fill_val;
+	unsigned int chunk;
 	sparse_header_t *sparse_header;
-       chunk_header_t *chunk_header;
+	chunk_header_t *chunk_header;
+	sparse_buffer_t *buffer;
 	uint32_t total_blocks = 0;
 	int i;

@@ -97,142 +281,49 @@ void write_sparse_image(block_dev_desc_t *dev_desc,
 
 	/* Start processing chunks */
 	blk = info->start;
-	for (chunk=0; chunk<sparse_header->total_chunks; chunk++)
-	{
-		/* Read and skip over chunk header */
-		chunk_header = (chunk_header_t *) data;
-		data += sizeof(chunk_header_t);
-
-		if (chunk_header->chunk_type != CHUNK_TYPE_RAW) {
-			debug("=== Chunk Header ===\n");
-			debug("chunk_type: 0x%x\n", chunk_header->chunk_type);
-			debug("chunk_data_sz: 0x%x\n", chunk_header->chunk_sz);
-			debug("total_size: 0x%x\n", chunk_header->total_sz);
+	for (chunk = 0; chunk < sparse_header->total_chunks; chunk++) {
+		chunk_header = sparse_parse_chunk(sparse_header, &data);
+		if (!chunk_header) {
+			fastboot_fail("Unknown chunk type");
+			return;
 		}
 
-		if (sparse_header->chunk_hdr_sz > sizeof(chunk_header_t))
-		{
-			/*
-			 * Skip the remaining bytes in a header that is longer
-			 * than we expected.
-			 */
-			data += (sparse_header->chunk_hdr_sz -
-				 sizeof(chunk_header_t));
-		}
+		/* Retrieve the buffer we're going to write */
+		buffer = sparse_get_data_buffer(sparse_header, chunk_header,
+						info->blksz, &data);
+		if (!buffer)
+			continue;
 
-		chunk_data_sz = sparse_header->blk_sz * chunk_header->chunk_sz;
-		blkcnt = chunk_data_sz / info->blksz;
-		switch (chunk_header->chunk_type)
-		{
-			case CHUNK_TYPE_RAW:
-			if (chunk_header->total_sz !=
-			    (sparse_header->chunk_hdr_sz + chunk_data_sz))
-			{
-				fastboot_fail(
-					"Bogus chunk size for chunk type Raw");
-				return;
-			}
+		blkcnt = (buffer->length / info->blksz) * buffer->repeat;
 
-			if (blk + blkcnt > info->start + info->size) {
-				printf(
-				    "%s: Request would exceed partition size!\n",
-				    __func__);
-				fastboot_fail(
-				    "Request would exceed partition size!");
-				return;
-			}
-
-			blks = dev_desc->block_write(dev_desc->dev, blk, blkcnt,
-						     data);
-			if (blks != blkcnt) {
-				printf("%s: Write failed " LBAFU "\n",
-				       __func__, blks);
-				fastboot_fail("flash write failure");
-				return;
-			}
-			blk += blkcnt;
-			bytes_written += blkcnt * info->blksz;
-			total_blocks += chunk_header->chunk_sz;
-			data += chunk_data_sz;
-			break;
-
-			case CHUNK_TYPE_FILL:
-			if (chunk_header->total_sz !=
-			    (sparse_header->chunk_hdr_sz + sizeof(uint32_t)))
-			{
-				fastboot_fail(
-					"Bogus chunk size for chunk type FILL");
-				return;
-			}
-
-			fill_buf = (uint32_t *)
-				   memalign(ARCH_DMA_MINALIGN,
-					    ROUNDUP(info->blksz,
-						    ARCH_DMA_MINALIGN));
-			if (!fill_buf)
-			{
-				fastboot_fail(
-					"Malloc failed for: CHUNK_TYPE_FILL");
-				return;
-			}
-
-			fill_val = *(uint32_t *)data;
-			data = (char *) data + sizeof(uint32_t);
+		if (blk + blkcnt > info->start + info->size) {
+			printf("%s: Request would exceed partition size!\n",
+			       __func__);
+			fastboot_fail("Request would exceed partition size!");
+			return;
+		}
 
-			for (i = 0; i < (info->blksz / sizeof(fill_val)); i++)
-				fill_buf[i] = fill_val;
+		for (i = 0; i < buffer->repeat; i++) {
+			unsigned int buffer_blk_cnt;
+			unsigned int buffer_blks;
 
-			if (blk + blkcnt > info->start + info->size) {
-				printf(
-				    "%s: Request would exceed partition size!\n",
-				    __func__);
-				fastboot_fail(
-				    "Request would exceed partition size!");
-				return;
-			}
+			buffer_blk_cnt = buffer->length / storage->block_sz;
 
-			for (i = 0; i < blkcnt; i++) {
-				blks = dev_desc->block_write(dev_desc->dev,
-							     blk, 1, fill_buf);
-				if (blks != 1) {
-					printf(
-					    "%s: Write failed, block # " LBAFU "\n",
-					    __func__, blkcnt);
-					fastboot_fail("flash write failure");
-					free(fill_buf);
-					return;
-				}
-				blk++;
-			}
-			bytes_written += blkcnt * info->blksz;
-			total_blocks += chunk_data_sz / sparse_header->blk_sz;
-
-			free(fill_buf);
-			break;
-
-			case CHUNK_TYPE_DONT_CARE:
-			blk += blkcnt;
-			total_blocks += chunk_header->chunk_sz;
-			break;
-
-			case CHUNK_TYPE_CRC32:
-			if (chunk_header->total_sz !=
-			    sparse_header->chunk_hdr_sz)
-			{
-				fastboot_fail(
-					"Bogus chunk size for chunk type Dont Care");
+			buffer_blks = dev_desc->block_write(dev_desc->dev, blk,
+							    buffer_blk_cnt, buffer->data);
+			if (buffer_blks != buffer_blk_cnt) {
+				printf("%s: Write %d failed " LBAFU "\n",
+				       __func__, i, buffer_blks);
+				fastboot_fail("flash write failure");
 				return;
 			}
-			total_blocks += chunk_header->chunk_sz;
-			data += chunk_data_sz;
-			break;
 
-			default:
-			printf("%s: Unknown chunk type: %x\n", __func__,
-			       chunk_header->chunk_type);
-			fastboot_fail("Unknown chunk type");
-			return;
+			blk += buffer_blk_cnt;
+			bytes_written += buffer->length;
+			total_blocks += buffer_blk_cnt;
 		}
+
+		sparse_put_data_buffer(buffer);
 	}
 
 	debug("Wrote %d blocks, expected to write %d blocks\n",

Signature · 1 line

2.5.0

Tom Rini

2015-09-04 17:20 UTC #6 lore raw

PATCH 3/13 sparse: Refactor chunk parsing function

Quoted 8 lines · Maxime Ripard

The chunk parsing code was duplicating a lot of code among the various chunk types, while all of them could be covered by generic and simple functions.
Refactor the current code to reuse as much code as possible and hopefully make the chunk parsing loop more readable and concise.
Signed-off-by Maxime Ripard <[email protected]>

Reviewed-by Tom Rini <[email protected]>

Signature · 8 lines

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/20150904/4db16657/attachment.sig>

Maxime Ripard

author

2015-08-31 14:46 UTC #7 lore raw

PATCH 4/13 sparse: Simplify multiple logic

In reply to Maxime Ripard

To check the alignment of the image blocks to the storage blocks, the current code uses a convoluted syntax, while a simple mod also does the work.

Signed-off-by Maxime Ripard <[email protected]>

---
 common/aboot.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

common/aboot.c +1 -2

index 65e633acfcb9..c8556d9b23f4 100644
@@ -269,8 +269,7 @@ void write_sparse_image(block_dev_desc_t *dev_desc,
 	}
 
 	/* verify sparse_header->blk_sz is an exact multiple of info->blksz */
-	if (sparse_header->blk_sz !=
-	    (sparse_header->blk_sz & ~(info->blksz - 1))) {
+	if (sparse_header->blk_sz % info->blksz) {
 		printf("%s: Sparse image block size issue [%u]\n",
 		       __func__, sparse_header->blk_sz);
 		fastboot_fail("sparse image block size issue");

Signature · 1 line

2.5.0

Tom Rini

2015-09-04 17:20 UTC #8 lore raw

PATCH 4/13 sparse: Simplify multiple logic

Quoted 14 lines · Maxime Ripard

To check the alignment of the image blocks to the storage blocks, the current code uses a convoluted syntax, while a simple mod also does the work.
Signed-off-by Maxime Ripard <[email protected]>
---
 common/aboot.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
common/aboot.c +0 -0
index 65e633acfcb9..c8556d9b23f4 100644

common/aboot.c void write_sparse_image(block_dev_desc_t *dev_desc, · line 272

Quoted 6 lines

common/aboot.c +1 -2

@@ -269,8 +269,7 @@ void write_sparse_image(block_dev_desc_t *dev_desc,
 	}
 
 	/* verify sparse_header->blk_sz is an exact multiple of info->blksz */
-	if (sparse_header->blk_sz !=
-	    (sparse_header->blk_sz & ~(info->blksz - 1))) {
+	if (sparse_header->blk_sz % info->blksz) {

So, sometimes we have convoluted syntax like this to avoid what ends up as floating point math on 32bit platforms. Maybe this needs to be one of the helpers in include/linux/math64.h ? Or is this really just convoluted syntax? Thanks!

Signature · 8 lines

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/20150904/9a9b9bcf/attachment.sig>

Maxime Ripard

author

2015-09-06 11:27 UTC #9 lore raw

PATCH 4/13 sparse: Simplify multiple logic

Quoted 18 lines · Tom Rini

Quoted 16 lines · Maxime Ripard
To check the alignment of the image blocks to the storage blocks, the current code uses a convoluted syntax, while a simple mod also does the work.
Signed-off-by Maxime Ripard <[email protected]>
---
 common/aboot.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
common/aboot.c +0 -0
index 65e633acfcb9..c8556d9b23f4 100644
@@ -269,8 +269,7 @@ void write_sparse_image(block_dev_desc_t *dev_desc,
 	}
 

Quoted 7 lines

common/aboot.c void write_sparse_image(block_dev_desc_t *dev_desc, · line 272
Quoted 4 lines
common/aboot.c +1 -2
 	/* verify sparse_header->blk_sz is an exact multiple of info->blksz */
-	if (sparse_header->blk_sz !=
-	    (sparse_header->blk_sz & ~(info->blksz - 1))) {
+	if (sparse_header->blk_sz % info->blksz) {
So, sometimes we have convoluted syntax like this to avoid what ends up as floating point math on 32bit platforms.

Now that you speak of this, we did have some compilers on some platforms that ended up generating floating point related failures on our branch, but I didn't have the time to look into it.

However, I don't really know how we can end up with floating point math with a mod, is this some optimisations done by gcc?

Quoted 1 line

Maybe this needs to be one of the helpers in include/linux/math64.h?

Probably then, yes.

Thanks!
Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150906/d5389adc/attachment.sig>

Tom Rini

2015-09-06 19:28 UTC #10 lore raw

PATCH 4/13 sparse: Simplify multiple logic

Quoted 27 lines · Maxime Ripard

Quoted 18 lines · Tom Rini
Quoted 16 lines · Maxime Ripard
To check the alignment of the image blocks to the storage blocks, the current code uses a convoluted syntax, while a simple mod also does the work.
Signed-off-by Maxime Ripard <[email protected]>
---
 common/aboot.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
common/aboot.c +0 -0
index 65e633acfcb9..c8556d9b23f4 100644
@@ -269,8 +269,7 @@ void write_sparse_image(block_dev_desc_t *dev_desc,
 	}
 
Quoted 7 lines
common/aboot.c void write_sparse_image(block_dev_desc_t *dev_desc, · line 272
Quoted 4 lines
common/aboot.c +1 -2
 	/* verify sparse_header->blk_sz is an exact multiple of info->blksz */
-	if (sparse_header->blk_sz !=
-	    (sparse_header->blk_sz & ~(info->blksz - 1))) {
+	if (sparse_header->blk_sz % info->blksz) {
So, sometimes we have convoluted syntax like this to avoid what ends up as floating point math on 32bit platforms.

Quoted 6 lines

Now that you speak of this, we did have some compilers on some platforms that ended up generating floating point related failures on our branch, but I didn't have the time to look into it.
However, I don't really know how we can end up with floating point math with a mod, is this some optimisations done by gcc?

My fuzz recollection is that GCC on 32bit ARM when it defaults to a hardfloat ABI "knows" that it is "safe" to use the floating point registers to do 64bit division rather than shifting and so forth.

Quoted 3 lines

Quoted 1 line
Maybe this needs to be one of the helpers in include/linux/math64.h?
Probably then, yes.

Yeah, this is it. My first guess is that if you look at 9e374e7b729dc9f68be89cd3e3b1d4d48c768ecf you'll find an example that matches the problem here and what the right helper/code chagnes are.

Signature · 8 lines

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/20150906/18a1602a/attachment.sig>

Maxime Ripard

author

2015-09-13 17:08 UTC #11 lore raw

PATCH 4/13 sparse: Simplify multiple logic

Quoted 32 lines · Tom Rini

Quoted 31 lines · Maxime Ripard
Quoted 18 lines · Tom Rini
Quoted 16 lines · Maxime Ripard
To check the alignment of the image blocks to the storage blocks, the current code uses a convoluted syntax, while a simple mod also does the work.
Signed-off-by Maxime Ripard <[email protected]>
---
 common/aboot.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
common/aboot.c +0 -0
index 65e633acfcb9..c8556d9b23f4 100644
@@ -269,8 +269,7 @@ void write_sparse_image(block_dev_desc_t *dev_desc,
 	}
 
Quoted 7 lines
common/aboot.c void write_sparse_image(block_dev_desc_t *dev_desc, · line 272
Quoted 4 lines
common/aboot.c +1 -2
 	/* verify sparse_header->blk_sz is an exact multiple of info->blksz */
-	if (sparse_header->blk_sz !=
-	    (sparse_header->blk_sz & ~(info->blksz - 1))) {
+	if (sparse_header->blk_sz % info->blksz) {
So, sometimes we have convoluted syntax like this to avoid what ends up as floating point math on 32bit platforms.
Now that you speak of this, we did have some compilers on some platforms that ended up generating floating point related failures on our branch, but I didn't have the time to look into it.

Quoted 6 lines

Quoted 2 lines
However, I don't really know how we can end up with floating point math with a mod, is this some optimisations done by gcc?
My fuzz recollection is that GCC on 32bit ARM when it defaults to a hardfloat ABI "knows" that it is "safe" to use the floating point registers to do 64bit division rather than shifting and so forth.

Hmm, ok, I see.

Quoted 7 lines

Quoted 3 lines
Quoted 1 line
Maybe this needs to be one of the helpers in include/linux/math64.h?
Probably then, yes.
Yeah, this is it. My first guess is that if you look at 9e374e7b729dc9f68be89cd3e3b1d4d48c768ecf you'll find an example that matches the problem here and what the right helper/code chagnes are.

I'll look at this and use it then.

Thanks!
Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150913/96c1e172/attachment.sig>

Maxime Ripard

author

2015-08-31 14:46 UTC #12 lore raw

PATCH 5/13 sparse: Implement storage abstraction

In reply to Maxime Ripard

The current sparse image parser relies heavily on the MMC layer, and doesn't allow any other kind of storage medium to be used.

Rework the parser to support any kind of storage medium, as long as there is an implementation for it.

Signed-off-by Maxime Ripard <[email protected]>

---
 common/aboot.c  | 51 +++++++++++++++++++++++++++++++++++----------------
 common/fb_mmc.c | 39 +++++++++++++++++++++++++++++++++++----
 include/aboot.h | 14 ++++++++++++++
 3 files changed, 84 insertions(+), 20 deletions(-)

common/aboot.c +35 ~~-16~~

index c8556d9b23f4..18ff30ee6d11 100644
@@ -42,6 +42,13 @@
 #include <part.h>
 #include <sparse_format.h>
 
+typedef struct sparse_buffer {
+	void	*data;
+	u32	length;
+	u32	repeat;
+	u16	type;
+} sparse_buffer_t;
+
 static unsigned int sparse_get_chunk_data_size(sparse_header_t *sparse,
 					       chunk_header_t *chunk)
 {

@@ -247,13 +254,11 @@ static void sparse_put_data_buffer(sparse_buffer_t *buffer)
 	free(buffer);
 }
 
-void write_sparse_image(block_dev_desc_t *dev_desc,
-		disk_partition_t *info, const char *part_name,
-		void *data, unsigned sz)
+void store_sparse_image(sparse_storage_t *storage,
+			void *storage_priv, void *data)
 {
-	lbaint_t blk;
-	lbaint_t blkcnt;
-	lbaint_t blks;
+	uint32_t blk;
+	uint32_t blkcnt;
 	uint32_t bytes_written = 0;
 	unsigned int chunk;
 	sparse_header_t *sparse_header;

@@ -262,14 +267,25 @@ void write_sparse_image(block_dev_desc_t *dev_desc,
 	uint32_t total_blocks = 0;
 	int i;
 
+	debug("=== Storage ===\n");
+	debug("name: %s\n", storage->name);
+	debug("block_size: 0x%x\n", storage->block_sz);
+	debug("start: 0x%x\n", storage->start);
+	debug("size: 0x%x\n", storage->size);
+	debug("write: 0x%p\n", storage->write);
+	debug("priv: 0x%p\n", storage_priv);
+
 	sparse_header = sparse_parse_header(&data);
 	if (!sparse_header) {
 		fastboot_fail("sparse header issue\n");
 		return;
 	}
 
-	/* verify sparse_header->blk_sz is an exact multiple of info->blksz */
-	if (sparse_header->blk_sz % info->blksz) {
+	/*
+	 * Verify that the sparse block size is a multiple of our
+	 * storage backend block size
+	 */
+	if (sparse_header->blk_sz % storage->block_sz) {
 		printf("%s: Sparse image block size issue [%u]\n",
 		       __func__, sparse_header->blk_sz);
 		fastboot_fail("sparse image block size issue");

@@ -279,7 +295,7 @@ void write_sparse_image(block_dev_desc_t *dev_desc,
 	puts("Flashing Sparse Image\n");
 
 	/* Start processing chunks */
-	blk = info->start;
+	blk = storage->start;
 	for (chunk = 0; chunk < sparse_header->total_chunks; chunk++) {
 		chunk_header = sparse_parse_chunk(sparse_header, &data);
 		if (!chunk_header) {

@@ -289,13 +305,13 @@ void write_sparse_image(block_dev_desc_t *dev_desc,
 
 		/* Retrieve the buffer we're going to write */
 		buffer = sparse_get_data_buffer(sparse_header, chunk_header,
-						info->blksz, &data);
+						storage->block_sz, &data);
 		if (!buffer)
 			continue;
 
-		blkcnt = (buffer->length / info->blksz) * buffer->repeat;
+		blkcnt = (buffer->length / storage->block_sz) * buffer->repeat;
 
-		if (blk + blkcnt > info->start + info->size) {
+		if (blk + blkcnt > storage->start + storage->size) {
 			printf("%s: Request would exceed partition size!\n",
 			       __func__);
 			fastboot_fail("Request would exceed partition size!");

@@ -308,10 +324,12 @@ void write_sparse_image(block_dev_desc_t *dev_desc,
 
 			buffer_blk_cnt = buffer->length / storage->block_sz;
 
-			buffer_blks = dev_desc->block_write(dev_desc->dev, blk,
-							    buffer_blk_cnt, buffer->data);
+			buffer_blks = storage->write(storage,
+						     storage_priv,
+						     blk, buffer_blk_cnt,
+						     buffer->data);
 			if (buffer_blks != buffer_blk_cnt) {
-				printf("%s: Write %d failed " LBAFU "\n",
+				printf("%s: Write %d failed %d\n",
 				       __func__, i, buffer_blks);
 				fastboot_fail("flash write failure");
 				return;

@@ -327,7 +345,8 @@ void write_sparse_image(block_dev_desc_t *dev_desc,
 
 	debug("Wrote %d blocks, expected to write %d blocks\n",
 	      total_blocks, sparse_header->total_blks);
-	printf("........ wrote %u bytes to '%s'\n", bytes_written, part_name);
+	printf("........ wrote %u bytes to '%s'\n", bytes_written,
+	       storage->name);
 
 	if (total_blocks != sparse_header->total_blks)
 		fastboot_fail("sparse image write failure");

common/fb_mmc.c +35 -4

index 0c48cf929f8f..a44627c00060 100644
@@ -33,6 +33,10 @@ void fastboot_okay(const char *s)
 	strncat(response_str, s, RESPONSE_LEN - 4 - 1);
 }
 
+struct fb_mmc_sparse {
+	block_dev_desc_t	*dev_desc;
+};
+
 static int get_partition_info_efi_by_name_or_alias(block_dev_desc_t *dev_desc,
 		const char *name, disk_partition_t *info)
 {

@@ -55,6 +59,19 @@ static int get_partition_info_efi_by_name_or_alias(block_dev_desc_t *dev_desc,
 	return ret;
 }
 
+
+static unsigned int fb_mmc_sparse_write(struct sparse_storage *storage,
+					void *priv,
+					unsigned int offset,
+					unsigned int size,
+					char *data)
+{
+	struct fb_mmc_sparse *sparse = priv;
+	block_dev_desc_t *dev_desc = sparse->dev_desc;
+
+	return dev_desc->block_write(dev_desc->dev, offset, size, data);
+}
+
 static void write_raw_image(block_dev_desc_t *dev_desc, disk_partition_t *info,
 		const char *part_name, void *buffer,
 		unsigned int download_bytes)

@@ -126,12 +143,26 @@ void fb_mmc_flash_write(const char *cmd, void *download_buffer,
 		return;
 	}
 
-	if (is_sparse_image(download_buffer))
-		write_sparse_image(dev_desc, &info, cmd, download_buffer,
-				   download_bytes);
-	else
+	if (is_sparse_image(download_buffer)) {
+		struct fb_mmc_sparse sparse_priv;
+		sparse_storage_t sparse;
+
+		sparse_priv.dev_desc = dev_desc;
+
+		sparse.block_sz = info.blksz;
+		sparse.start = info.start;
+		sparse.size = info.size;
+		sparse.name = cmd;
+		sparse.write = fb_mmc_sparse_write;
+
+		printf("Flashing sparse image at offset " LBAFU "\n",
+		       info.start);
+
+		store_sparse_image(&sparse, &sparse_priv, download_buffer);
+	} else {
 		write_raw_image(dev_desc, &info, cmd, download_buffer,
 				download_bytes);
+	}
 }
 
 void fb_mmc_erase(const char *cmd, char *response)

include/aboot.h +14 -0

index 30e4d36df8ba..162d81da6d9d 100644
@@ -9,6 +9,17 @@
 
 #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;
+
+	unsigned int	(*write)(struct sparse_storage *storage, void *priv,
+				 unsigned int offset, unsigned int size,
+				 char *data);
+} sparse_storage_t;
+
 void fastboot_fail(const char *s);
 void fastboot_okay(const char *s);

@@ -26,3 +37,6 @@ static inline int is_sparse_image(void *buf)
 void write_sparse_image(block_dev_desc_t *dev_desc,
 		disk_partition_t *info, const char *part_name,
 		void *data, unsigned sz);
+
+void store_sparse_image(sparse_storage_t *storage, void *storage_priv,
+			void *data);

Signature · 1 line

2.5.0

Tom Rini

2015-09-04 17:20 UTC #13 lore raw

PATCH 5/13 sparse: Implement storage abstraction

Quoted 7 lines · Maxime Ripard

The current sparse image parser relies heavily on the MMC layer, and doesn't allow any other kind of storage medium to be used.
Rework the parser to support any kind of storage medium, as long as there is an implementation for it.
Signed-off-by Maxime Ripard <[email protected]>

Reviewed-by Tom Rini <[email protected]>

Signature · 8 lines

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/20150904/b4b0dc6b/attachment.sig>

Maxime Ripard

author

2015-08-31 14:46 UTC #14 lore raw

PATCH 6/13 fastboot: Move fastboot response functions to fastboot core

In reply to Maxime Ripard

The functions and a few define to generate a fastboot message to be sent back to the host were so far duplicated among the users.

Move them all to a common place.

Signed-off-by Maxime Ripard <[email protected]>

---
 common/aboot.c                  | 14 ++++++--------
 common/fb_mmc.c                 | 43 ++++++++++++++---------------------------
 drivers/usb/gadget/f_fastboot.c | 27 ++++++++++++++++++--------
 include/aboot.h                 |  3 ---
 include/fastboot.h              | 22 +++++++++++++++++++++
 5 files changed, 62 insertions(+), 47 deletions(-)
 create mode 100644 include/fastboot.h

common/aboot.c +6 -8

index 18ff30ee6d11..37ad50efc50a 100644
@@ -277,7 +277,7 @@ void store_sparse_image(sparse_storage_t *storage,
 
 	sparse_header = sparse_parse_header(&data);
 	if (!sparse_header) {
-		fastboot_fail("sparse header issue\n");
+		printf("sparse header issue\n");
 		return;
 	}

@@ -288,7 +288,6 @@ void store_sparse_image(sparse_storage_t *storage,
 	if (sparse_header->blk_sz % storage->block_sz) {
 		printf("%s: Sparse image block size issue [%u]\n",
 		       __func__, sparse_header->blk_sz);
-		fastboot_fail("sparse image block size issue");
 		return;
 	}

@@ -299,7 +298,7 @@ void store_sparse_image(sparse_storage_t *storage,
 	for (chunk = 0; chunk < sparse_header->total_chunks; chunk++) {
 		chunk_header = sparse_parse_chunk(sparse_header, &data);
 		if (!chunk_header) {
-			fastboot_fail("Unknown chunk type");
+			printf("Unknown chunk type");
 			return;
 		}

@@ -314,7 +313,6 @@ void store_sparse_image(sparse_storage_t *storage,
 		if (blk + blkcnt > storage->start + storage->size) {
 			printf("%s: Request would exceed partition size!\n",
 			       __func__);
-			fastboot_fail("Request would exceed partition size!");
 			return;
 		}

@@ -331,7 +329,6 @@ void store_sparse_image(sparse_storage_t *storage,
 			if (buffer_blks != buffer_blk_cnt) {
 				printf("%s: Write %d failed %d\n",
 				       __func__, i, buffer_blks);
-				fastboot_fail("flash write failure");
 				return;
 			}

@@ -348,9 +345,10 @@ void store_sparse_image(sparse_storage_t *storage,
 	printf("........ wrote %u bytes to '%s'\n", bytes_written,
 	       storage->name);
 
-	if (total_blocks != sparse_header->total_blks)
-		fastboot_fail("sparse image write failure");
+	if (total_blocks != sparse_header->total_blks) {
+		printf("sparse image write failure");
+		return;
+	}
 
-	fastboot_okay("");
 	return;
 }

common/fb_mmc.c +15 ~~-28~~

123 lines not on this page · raw message

drivers/usb/gadget/f_fastboot.c +19 -8

index ca01a018b5d1..5703decfd360 100644
@@ -13,6 +13,7 @@
 #include <config.h>
 #include <common.h>
 #include <errno.h>
+#include <fastboot.h>
 #include <malloc.h>
 #include <linux/usb/ch9.h>
 #include <linux/usb/gadget.h>

@@ -34,9 +35,6 @@
 #define RX_ENDPOINT_MAXIMUM_PACKET_SIZE_1_1  (0x0040)
 #define TX_ENDPOINT_MAXIMUM_PACKET_SIZE      (0x0040)
 
-/* The 64 defined bytes plus \0 */
-#define RESPONSE_LEN	(64 + 1)
-
 #define EP_BUFFER_SIZE			4096
 
 struct f_fastboot {

@@ -125,6 +123,19 @@ static struct usb_gadget_strings *fastboot_strings[] = {
 static void rx_handler_command(struct usb_ep *ep, struct usb_request *req);
 static int strcmp_l1(const char *s1, const char *s2);
 
+
+void fastboot_fail(char *response, const char *reason)
+{
+	strncpy(response, "FAIL\0", 5);
+	strncat(response, reason, FASTBOOT_RESPONSE_LEN - 4 - 1);
+}
+
+void fastboot_okay(char *response, const char *reason)
+{
+	strncpy(response, "OKAY\0", 5);
+	strncat(response, reason, FASTBOOT_RESPONSE_LEN - 4 - 1);
+}
+
 static void fastboot_complete(struct usb_ep *ep, struct usb_request *req)
 {
 	int status = req->status;

@@ -358,7 +369,7 @@ static int strcmp_l1(const char *s1, const char *s2)
 static void cb_getvar(struct usb_ep *ep, struct usb_request *req)
 {
 	char *cmd = req->buf;
-	char response[RESPONSE_LEN];
+	char response[FASTBOOT_RESPONSE_LEN];
 	const char *s;
 	size_t chars_left;

@@ -415,7 +426,7 @@ static unsigned int rx_bytes_expected(unsigned int maxpacket)
 #define BYTES_PER_DOT	0x20000
 static void rx_handler_dl_image(struct usb_ep *ep, struct usb_request *req)
 {
-	char response[RESPONSE_LEN];
+	char response[FASTBOOT_RESPONSE_LEN];
 	unsigned int transfer_size = download_size - download_bytes;
 	const unsigned char *buffer = req->buf;
 	unsigned int buffer_size = req->actual;

@@ -472,7 +483,7 @@ static void rx_handler_dl_image(struct usb_ep *ep, struct usb_request *req)
 static void cb_download(struct usb_ep *ep, struct usb_request *req)
 {
 	char *cmd = req->buf;
-	char response[RESPONSE_LEN];
+	char response[FASTBOOT_RESPONSE_LEN];
 	unsigned int max;
 
 	strsep(&cmd, ":");

@@ -533,7 +544,7 @@ static void cb_continue(struct usb_ep *ep, struct usb_request *req)
 static void cb_flash(struct usb_ep *ep, struct usb_request *req)
 {
 	char *cmd = req->buf;
-	char response[RESPONSE_LEN];
+	char response[FASTBOOT_RESPONSE_LEN];
 
 	strsep(&cmd, ":");
 	if (!cmd) {

@@ -577,7 +588,7 @@ static void cb_oem(struct usb_ep *ep, struct usb_request *req)
 static void cb_erase(struct usb_ep *ep, struct usb_request *req)
 {
 	char *cmd = req->buf;
-	char response[RESPONSE_LEN];
+	char response[FASTBOOT_RESPONSE_LEN];
 
 	strsep(&cmd, ":");
 	if (!cmd) {

include/aboot.h +0 -3

index 162d81da6d9d..55da8336f20d 100644
@@ -20,9 +20,6 @@ typedef struct sparse_storage {
 				 char *data);
 } sparse_storage_t;
 
-void fastboot_fail(const char *s);
-void fastboot_okay(const char *s);
-
 static inline int is_sparse_image(void *buf)
 {
 	sparse_header_t *s_header = (sparse_header_t *)buf;

include/fastboot.h new file +22 -0

new file mode 100644
index 000000000000..db826d20bfef
@@ -0,0 +1,22 @@
+/*
+ * (C) Copyright 2008 - 2009
+ * Windriver, <www.windriver.com>
+ * Tom Rix <[email protected]>
+ *
+ * Copyright 2011 Sebastian Andrzej Siewior <[email protected]>
+ *
+ * Copyright 2014 Linaro, Ltd.
+ * Rob Herring <[email protected]>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+#ifndef _FASTBOOT_H_
+#define _FASTBOOT_H_
+
+/* The 64 defined bytes plus \0 */
+#define FASTBOOT_RESPONSE_LEN	(64 + 1)
+
+void fastboot_fail(char *response, const char *reason);
+void fastboot_okay(char *response, const char *reason);
+
+#endif /* _FASTBOOT_H_ */

Signature · 1 line

2.5.0

Tom Rini

2015-09-04 17:20 UTC #15 lore raw

PATCH 6/13 fastboot: Move fastboot response functions to fastboot core

Quoted 4 lines · Maxime Ripard

The functions and a few define to generate a fastboot message to be sent back to the host were so far duplicated among the users.
Move them all to a common place.

[snip]

Quoted 50 lines

common/aboot.c +2 -5

index 18ff30ee6d11..37ad50efc50a 100644
@@ -277,7 +277,7 @@ void store_sparse_image(sparse_storage_t *storage,
 
 	sparse_header = sparse_parse_header(&data);
 	if (!sparse_header) {
-		fastboot_fail("sparse header issue\n");
+		printf("sparse header issue\n");
 		return;
 	}

@@ -288,7 +288,6 @@ void store_sparse_image(sparse_storage_t *storage,
 	if (sparse_header->blk_sz % storage->block_sz) {
 		printf("%s: Sparse image block size issue [%u]\n",
 		       __func__, sparse_header->blk_sz);
-		fastboot_fail("sparse image block size issue");
 		return;
 	}

@@ -299,7 +298,7 @@ void store_sparse_image(sparse_storage_t *storage,
 	for (chunk = 0; chunk < sparse_header->total_chunks; chunk++) {
 		chunk_header = sparse_parse_chunk(sparse_header, &data);
 		if (!chunk_header) {
-			fastboot_fail("Unknown chunk type");
+			printf("Unknown chunk type");
 			return;
 		}

@@ -314,7 +313,6 @@ void store_sparse_image(sparse_storage_t *storage,
 		if (blk + blkcnt > storage->start + storage->size) {
 			printf("%s: Request would exceed partition size!\n",
 			       __func__);
-			fastboot_fail("Request would exceed partition size!");
 			return;
 		}

@@ -331,7 +329,6 @@ void store_sparse_image(sparse_storage_t *storage,
 			if (buffer_blks != buffer_blk_cnt) {
 				printf("%s: Write %d failed %d\n",
 				       __func__, i, buffer_blks);
-				fastboot_fail("flash write failure");
 				return;
 			}

@@ -348,9 +345,10 @@ void store_sparse_image(sparse_storage_t *storage,
 	printf("........ wrote %u bytes to '%s'\n", bytes_written,
 	       storage->name);

common/aboot.c void store_sparse_image(sparse_storage_t *storage, · line 354

Quoted 10 lines

common/aboot.c +4 -3

-	if (total_blocks != sparse_header->total_blks)
-		fastboot_fail("sparse image write failure");
+	if (total_blocks != sparse_header->total_blks) {
+		printf("sparse image write failure");
+		return;
+	}
 
-	fastboot_okay("");
 	return;
 }

Why in the case of this image do we not need to do fastboot_fail/okay now? It's not obvious from the rest of the changes to me, thanks!

Signature · 8 lines

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/20150904/f4427325/attachment.sig>

Maxime Ripard

author

2015-09-06 16:11 UTC #16 lore raw

PATCH 6/13 fastboot: Move fastboot response functions to fastboot core

Quoted 64 lines · Tom Rini

Quoted 4 lines · Maxime Ripard

The functions and a few define to generate a fastboot message to be sent back to the host were so far duplicated among the users.
Move them all to a common place.

[snip]

Quoted 57 lines

common/aboot.c +6 -7

index 18ff30ee6d11..37ad50efc50a 100644
@@ -277,7 +277,7 @@ void store_sparse_image(sparse_storage_t *storage,
 
 	sparse_header = sparse_parse_header(&data);
 	if (!sparse_header) {
-		fastboot_fail("sparse header issue\n");
+		printf("sparse header issue\n");
 		return;
 	}

@@ -288,7 +288,6 @@ void store_sparse_image(sparse_storage_t *storage,
 	if (sparse_header->blk_sz % storage->block_sz) {
 		printf("%s: Sparse image block size issue [%u]\n",
 		       __func__, sparse_header->blk_sz);
-		fastboot_fail("sparse image block size issue");
 		return;
 	}

@@ -299,7 +298,7 @@ void store_sparse_image(sparse_storage_t *storage,
 	for (chunk = 0; chunk < sparse_header->total_chunks; chunk++) {
 		chunk_header = sparse_parse_chunk(sparse_header, &data);
 		if (!chunk_header) {
-			fastboot_fail("Unknown chunk type");
+			printf("Unknown chunk type");
 			return;
 		}

@@ -314,7 +313,6 @@ void store_sparse_image(sparse_storage_t *storage,
 		if (blk + blkcnt > storage->start + storage->size) {
 			printf("%s: Request would exceed partition size!\n",
 			       __func__);
-			fastboot_fail("Request would exceed partition size!");
 			return;
 		}

@@ -331,7 +329,6 @@ void store_sparse_image(sparse_storage_t *storage,
 			if (buffer_blks != buffer_blk_cnt) {
 				printf("%s: Write %d failed %d\n",
 				       __func__, i, buffer_blks);
-				fastboot_fail("flash write failure");
 				return;
 			}

@@ -348,9 +345,10 @@ void store_sparse_image(sparse_storage_t *storage,
 	printf("........ wrote %u bytes to '%s'\n", bytes_written,
 	       storage->name);
 
-	if (total_blocks != sparse_header->total_blks)
-		fastboot_fail("sparse image write failure");
+	if (total_blocks != sparse_header->total_blks) {
+		printf("sparse image write failure");
+		return;
+	}

Quoted 6 lines

common/aboot.c void store_sparse_image(sparse_storage_t *storage, · line 354
Quoted 3 lines
common/aboot.c +0 -1
-	fastboot_okay("");
 	return;
 }
Why in the case of this image do we not need to do fastboot_fail/okay now? It's not obvious from the rest of the changes to me, thanks!

I took that shortcut while refactoring and forgot to fix it...

The issue is that we don't have access to the response buffer in those functions. We could pass it as an argument, but that would:

- Prevent the calling function (that "owns" the buffer pointer) to use fastboot_fail / fastboot_okay, which feels a bit wrong.

- On a more theorical point, the sparse image format should be decoupled from the fastboot protocol, hence not really rely of these functions.

What we can do though, is simply return an error code, and the storage layers could use fastboot_okay / fastboot_fail themselves. Does that sound good?

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150906/3f9b2ab8/attachment.sig>

Tom Rini

2015-09-06 19:43 UTC #17 lore raw

PATCH 6/13 fastboot: Move fastboot response functions to fastboot core

Quoted 80 lines · Maxime Ripard

Quoted 64 lines · Tom Rini

Quoted 4 lines · Maxime Ripard

The functions and a few define to generate a fastboot message to be sent back to the host were so far duplicated among the users.
Move them all to a common place.

[snip]

Quoted 57 lines

common/aboot.c +6 -7

index 18ff30ee6d11..37ad50efc50a 100644
@@ -277,7 +277,7 @@ void store_sparse_image(sparse_storage_t *storage,
 
 	sparse_header = sparse_parse_header(&data);
 	if (!sparse_header) {
-		fastboot_fail("sparse header issue\n");
+		printf("sparse header issue\n");
 		return;
 	}

@@ -288,7 +288,6 @@ void store_sparse_image(sparse_storage_t *storage,
 	if (sparse_header->blk_sz % storage->block_sz) {
 		printf("%s: Sparse image block size issue [%u]\n",
 		       __func__, sparse_header->blk_sz);
-		fastboot_fail("sparse image block size issue");
 		return;
 	}

@@ -299,7 +298,7 @@ void store_sparse_image(sparse_storage_t *storage,
 	for (chunk = 0; chunk < sparse_header->total_chunks; chunk++) {
 		chunk_header = sparse_parse_chunk(sparse_header, &data);
 		if (!chunk_header) {
-			fastboot_fail("Unknown chunk type");
+			printf("Unknown chunk type");
 			return;
 		}

@@ -314,7 +313,6 @@ void store_sparse_image(sparse_storage_t *storage,
 		if (blk + blkcnt > storage->start + storage->size) {
 			printf("%s: Request would exceed partition size!\n",
 			       __func__);
-			fastboot_fail("Request would exceed partition size!");
 			return;
 		}

@@ -331,7 +329,6 @@ void store_sparse_image(sparse_storage_t *storage,
 			if (buffer_blks != buffer_blk_cnt) {
 				printf("%s: Write %d failed %d\n",
 				       __func__, i, buffer_blks);
-				fastboot_fail("flash write failure");
 				return;
 			}

@@ -348,9 +345,10 @@ void store_sparse_image(sparse_storage_t *storage,
 	printf("........ wrote %u bytes to '%s'\n", bytes_written,
 	       storage->name);
 
-	if (total_blocks != sparse_header->total_blks)
-		fastboot_fail("sparse image write failure");
+	if (total_blocks != sparse_header->total_blks) {
+		printf("sparse image write failure");
+		return;
+	}

Quoted 6 lines

common/aboot.c void store_sparse_image(sparse_storage_t *storage, · line 354
Quoted 3 lines
common/aboot.c +0 -1
-	fastboot_okay("");
 	return;
 }
Why in the case of this image do we not need to do fastboot_fail/okay now? It's not obvious from the rest of the changes to me, thanks!

I took that shortcut while refactoring and forgot to fix it...

The issue is that we don't have access to the response buffer in those functions. We could pass it as an argument, but that would:

- Prevent the calling function (that "owns" the buffer pointer) to use fastboot_fail / fastboot_okay, which feels a bit wrong.

Quoted 7 lines

- On a more theorical point, the sparse image format should be decoupled from the fastboot protocol, hence not really rely of these functions.
What we can do though, is simply return an error code, and the storage layers could use fastboot_okay / fastboot_fail themselves. Does that sound good?

Error code and letting the higher level deal with it sounds good to me!

Signature · 8 lines

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/20150906/799efb0f/attachment.sig>

Maxime Ripard

author

2015-08-31 14:46 UTC #18 lore raw

PATCH 7/13 fastboot: Implement NAND backend

In reply to Maxime Ripard

So far the fastboot code was only supporting MMC-backed devices for its flashing operations (flash and erase).

Add a storage backend for NAND-backed devices.

Signed-off-by Maxime Ripard <[email protected]>

---
 common/Makefile                 |   7 +-
 common/fb_nand.c                | 198 ++++++++++++++++++++++++++++++++++++++++
 drivers/usb/gadget/f_fastboot.c |  12 ++-
 include/fb_nand.h               |  10 ++
 4 files changed, 225 insertions(+), 2 deletions(-)
 create mode 100644 common/fb_nand.c
 create mode 100644 include/fb_nand.h

common/Makefile +6 -1

index dc82433e90de..20e8027a8913 100644
@@ -271,10 +271,15 @@ obj-y += memsize.o
 obj-y += stdio.o
 
 # This option is not just y/n - it can have a numeric value
-ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
+ifdef CONFIG_FASTBOOT_FLASH
 obj-y += aboot.o
+ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
 obj-y += fb_mmc.o
 endif
+ifdef CONFIG_FASTBOOT_FLASH_NAND_DEV
+obj-y += fb_nand.o
+endif
+endif
 
 obj-$(CONFIG_CMD_BLOB) += cmd_blob.o

common/fb_nand.c new file +198 -0

198 lines not on this page · raw message

drivers/usb/gadget/f_fastboot.c +11 -1

index 5703decfd360..866d426732fa 100644
@@ -24,6 +24,9 @@
 #ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
 #include <fb_mmc.h>
 #endif
+#ifdef CONFIG_FASTBOOT_FLASH_NAND_DEV
+#include <fb_nand.h>
+#endif
 
 #define FASTBOOT_VERSION		"0.4"

@@ -558,6 +561,10 @@ static void cb_flash(struct usb_ep *ep, struct usb_request *req)
 	fb_mmc_flash_write(cmd, (void *)CONFIG_FASTBOOT_BUF_ADDR,
 			   download_bytes, response);
 #endif
+#ifdef CONFIG_FASTBOOT_FLASH_NAND_DEV
+	fb_nand_flash_write(cmd, (void *)CONFIG_USB_FASTBOOT_BUF_ADDR,
+			    download_bytes, response);
+#endif
 	fastboot_tx_write_str(response);
 }
 #endif

@@ -565,7 +572,7 @@ static void cb_flash(struct usb_ep *ep, struct usb_request *req)
 static void cb_oem(struct usb_ep *ep, struct usb_request *req)
 {
 	char *cmd = req->buf;
-#ifdef CONFIG_FASTBOOT_FLASH
+#ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
 	if (strncmp("format", cmd + 4, 6) == 0) {
 		char cmdbuf[32];
                 sprintf(cmdbuf, "gpt write mmc %x $partitions",

@@ -602,6 +609,9 @@ static void cb_erase(struct usb_ep *ep, struct usb_request *req)
 #ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
 	fb_mmc_erase(cmd, response);
 #endif
+#ifdef CONFIG_FASTBOOT_FLASH_NAND_DEV
+	fb_nand_erase(cmd, response);
+#endif
 	fastboot_tx_write_str(response);
 }
 #endif

include/fb_nand.h new file +10 -0

new file mode 100644
index 000000000000..88bdf3690de9
@@ -0,0 +1,10 @@
+/*
+ * Copyright 2014 Broadcom Corporation.
+ * Copyright 2015 Free Electrons.
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+void fb_nand_flash_write(const char *cmd, void *download_buffer,
+			 unsigned int download_bytes, char *response);
+void fb_nand_erase(const char *cmd, char *response);

Signature · 1 line

2.5.0

Tom Rini

2015-09-04 17:20 UTC #19 lore raw

PATCH 7/13 fastboot: Implement NAND backend

Quoted 6 lines · Maxime Ripard

So far the fastboot code was only supporting MMC-backed devices for its flashing operations (flash and erase).
Add a storage backend for NAND-backed devices.
Signed-off-by Maxime Ripard <[email protected]>

In general:

Reviewed-by Tom Rini <[email protected]>

But would it be possible to do this similar to how DFU is where we can have NAND and MMC and whatever else built-in and then use the right one as instructed by the user? ie change the command from 'fastboot <USB_controller>' to 'fastboot <USB_controller> [interface]' (or maybe have to make interface required, not sure). Thanks!

Signature · 8 lines

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/20150904/c0a5219f/attachment.sig>

Maxime Ripard

author

2015-09-06 15:57 UTC #20 lore raw

PATCH 7/13 fastboot: Implement NAND backend

Quoted 11 lines · Tom Rini

Quoted 6 lines · Maxime Ripard
So far the fastboot code was only supporting MMC-backed devices for its flashing operations (flash and erase).
Add a storage backend for NAND-backed devices.
Signed-off-by Maxime Ripard <[email protected]>
In general:

Quoted 7 lines

Reviewed-by Tom Rini <[email protected]>
But would it be possible to do this similar to how DFU is where we can have NAND and MMC and whatever else built-in and then use the right one as instructed by the user? ie change the command from 'fastboot <USB_controller>' to 'fastboot <USB_controller> [interface]' (or maybe have to make interface required, not sure). Thanks!

As in something like "fastboot 0 mmc 0" ?

Sounds good, however, since fastboot only refers to partitions by name, we could simply allow mix and matching them. What do you think?

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150906/021bb85f/attachment.sig>

Tom Rini

2015-09-06 19:41 UTC #21 lore raw

PATCH 7/13 fastboot: Implement NAND backend

Quoted 20 lines · Maxime Ripard

Quoted 11 lines · Tom Rini
Quoted 6 lines · Maxime Ripard
So far the fastboot code was only supporting MMC-backed devices for its flashing operations (flash and erase).
Add a storage backend for NAND-backed devices.
Signed-off-by Maxime Ripard <[email protected]>
In general:
Quoted 7 lines
Reviewed-by Tom Rini <[email protected]>
But would it be possible to do this similar to how DFU is where we can have NAND and MMC and whatever else built-in and then use the right one as instructed by the user? ie change the command from 'fastboot <USB_controller>' to 'fastboot <USB_controller> [interface]' (or maybe have to make interface required, not sure). Thanks!

Quoted 4 lines

As in something like "fastboot 0 mmc 0" ?
Sounds good, however, since fastboot only refers to partitions by name, we could simply allow mix and matching them. What do you think?

Sure, sounds good, thanks!

Signature · 8 lines

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/20150906/f4beeffb/attachment.sig>

Boris Brezillon

2015-09-10 07:41 UTC #22 lore raw

PATCH 7/13 fastboot: Implement NAND backend

In reply to Maxime Ripard

Hi Maxime,

Quoted 7 lines · On Mon, 31 Aug 2015 16:46:07 +0200 Maxime Ripard…

So far the fastboot code was only supporting MMC-backed devices for its flashing operations (flash and erase).
Add a storage backend for NAND-backed devices.
Signed-off-by Maxime Ripard <[email protected]>
---

[...]

Quoted 4 lines

common/fb_nand.c new file +4 -0

+
+static int _fb_nand_write(nand_info_t *nand, struct part_info *part,
+			  void *buffer, unsigned int offset,
+			  unsigned int length)

common/fb_nand.c line 95

Quoted 10 lines

common/fb_nand.c new file +10 -0

+{
+	int flags = WITH_WR_VERIFY;
+	int ret;
+
+#ifdef CONFIG_FASTBOOT_FLASH_NAND_TRIMFFS
+	flags |= WITH_DROP_FFS;
+#endif
+	ret = nand_write_skip_bad(nand, offset, &length, NULL,
+				  part->size - (offset - part->offset),
+				  buffer, flags);

Hm, you seem to ignore skipped blocks here (the 'actual' parameter is NULL), which means you won't adapt the offset accordingly and will likely override some data if you appear to have bad blocks in the section you're writing with the sparse method.

common/fb_nand.c line 105

Quoted 10 lines

common/fb_nand.c new file +10 -0

+
+	if (ret)
+		return ret;
+
+	return ret;
+}
+
+static unsigned int fb_nand_sparse_write(struct sparse_storage *storage,
+					 void *priv,
+					 unsigned int offset,

Maybe you should pass a pointer here, so that you can properly update it with the number of skipped blocks (the same goes for the _fb_nand_write function).

Best Regards,

Boris

Signature · 3 lines

Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Maxime Ripard

author

2015-08-31 14:46 UTC #23 lore raw

PATCH 8/13 fastboot: nand: Add pre erase and write hooks

In reply to Maxime Ripard

Some devices might need to do some per-partition initialization (ECC/Randomizer settings change for example) before actually accessing it.

Add some hooks before the write and erase operations to let the boards define what they need to do if needed.

Signed-off-by Maxime Ripard <[email protected]>

---
 common/fb_nand.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

common/fb_nand.c +22 -1

index 0e1d0603dbcf..1aab1e88f9c0 100644
@@ -23,6 +23,16 @@ struct fb_nand_sparse {
 	struct part_info	*part;
 };
 
+__weak int board_fastboot_erase_partition_setup(char *name)
+{
+	return 0;
+}
+
+__weak int board_fastboot_write_partition_setup(char *name)
+{
+	return 0;
+}
+
 static int fb_nand_lookup(const char *partname, char *response,
 			  nand_info_t **nand,
 			  struct part_info **part)

@@ -90,10 +100,10 @@ static int _fb_nand_write(nand_info_t *nand, struct part_info *part,
 #ifdef CONFIG_FASTBOOT_FLASH_NAND_TRIMFFS
 	flags |= WITH_DROP_FFS;
 #endif
+
 	ret = nand_write_skip_bad(nand, offset, &length, NULL,
 				  part->size - (offset - part->offset),
 				  buffer, flags);
-
 	if (ret)
 		return ret;

@@ -132,6 +142,9 @@ void fb_nand_flash_write(const char *partname, void *download_buffer,
 		return;
 	}
 
+	ret = board_fastboot_erase_partition_setup(part->name);
+	if (ret)
+		return;
 
 	ret = _fb_nand_erase(nand, part);
 	if (ret) {

@@ -140,6 +153,10 @@ void fb_nand_flash_write(const char *partname, void *download_buffer,
 		return;
 	}
 
+	ret = board_fastboot_write_partition_setup(part->name);
+	if (ret)
+		return;
+
 	if (is_sparse_image(download_buffer)) {
 		struct fb_nand_sparse sparse_priv;
 		sparse_storage_t sparse;

@@ -187,6 +204,10 @@ void fb_nand_erase(const char *partname, char *response)
 		return;
 	}
 
+	ret = board_fastboot_erase_partition_setup(part->name);
+	if (ret)
+		return;
+
 	ret = _fb_nand_erase(nand, part);
 	if (ret) {
 		error("failed erasing from device %s", nand->name);

Signature · 1 line

2.5.0

Tom Rini

2015-09-04 17:20 UTC #24 lore raw

PATCH 8/13 fastboot: nand: Add pre erase and write hooks

Quoted 7 lines · Maxime Ripard

Some devices might need to do some per-partition initialization (ECC/Randomizer settings change for example) before actually accessing it.
Add some hooks before the write and erase operations to let the boards define what they need to do if needed.
Signed-off-by Maxime Ripard <[email protected]>

Reviewed-by Tom Rini <[email protected]>

Signature · 8 lines

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/20150904/a0486aaf/attachment.sig>

Maxime Ripard

author

2015-08-31 14:46 UTC #25 lore raw

PATCH 9/13 sparse: Rename the file and header

In reply to Maxime Ripard

The Android sparse image format is currently supported through a file called aboot, which isn't really such a great name, since the sparse image format is only used for transferring data with fastboot.

Rename the file and header to a file called "sparse", which also makes it consistent with the header defining the image structures.

Signed-off-by Maxime Ripard <[email protected]>

---
 common/Makefile               | 2 +-
 common/fb_mmc.c               | 2 +-
 common/fb_nand.c              | 2 +-
 common/{aboot.c => sparse.c}  | 2 +-
 include/{aboot.h => sparse.h} | 0
 5 files changed, 4 insertions(+), 4 deletions(-)
 rename common/{aboot.c => sparse.c} (99%)
 rename include/{aboot.h => sparse.h} (100%)

common/Makefile +1 -1

index 20e8027a8913..f4c4cb623fc2 100644
@@ -272,7 +272,7 @@ obj-y += stdio.o
 
 # This option is not just y/n - it can have a numeric value
 ifdef CONFIG_FASTBOOT_FLASH
-obj-y += aboot.o
+obj-y += sparse.o
 ifdef CONFIG_FASTBOOT_FLASH_MMC_DEV
 obj-y += fb_mmc.o
 endif

common/fb_mmc.c +1 -1

index 0d6bcbf1f78b..eceedf1f1803 100644
@@ -9,7 +9,7 @@
 #include <fastboot.h>
 #include <fb_mmc.h>
 #include <part.h>
-#include <aboot.h>
+#include <sparse.h>
 #include <sparse_format.h>
 #include <mmc.h>

common/fb_nand.c +1 -1

index 1aab1e88f9c0..eb7ce4a35a43 100644
@@ -8,8 +8,8 @@
 #include <config.h>
 #include <common.h>
 
-#include <aboot.h>
 #include <fastboot.h>
+#include <sparse.h>
 #include <sparse_format.h>
 
 #include <linux/mtd/mtd.h>

common/sparse.c renamed from common/aboot.c +1 -1

similarity index 99%
rename from common/aboot.c
rename to common/sparse.c
index 37ad50efc50a..74178f764b18 100644
@@ -36,10 +36,10 @@
 
 #include <config.h>
 #include <common.h>
-#include <aboot.h>
 #include <errno.h>
 #include <malloc.h>
 #include <part.h>
+#include <sparse.h>
 #include <sparse_format.h>
 
 typedef struct sparse_buffer {

include/sparse.h renamed from include/aboot.h +0 -0

similarity index 100%
rename from include/aboot.h
rename to include/sparse.h

Signature · 1 line

2.5.0

Tom Rini

2015-09-04 17:21 UTC #26 lore raw

PATCH 9/13 sparse: Rename the file and header

Quoted 8 lines · Maxime Ripard

The Android sparse image format is currently supported through a file called aboot, which isn't really such a great name, since the sparse image format is only used for transferring data with fastboot.
Rename the file and header to a file called "sparse", which also makes it consistent with the header defining the image structures.
Signed-off-by Maxime Ripard <[email protected]>

In general, yes this is better so:

Reviewed-by Tom Rini <[email protected]>

But I honestly thought you were messing with the Linux sparse stuff at first. So maybe common/image-spare.[ch] ?

Signature · 8 lines

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/20150904/11ce9164/attachment.sig>

Maxime Ripard

author

2015-09-06 11:28 UTC #27 lore raw

PATCH 9/13 sparse: Rename the file and header

Quoted 9 lines · Tom Rini

Quoted 7 lines · Maxime Ripard
The Android sparse image format is currently supported through a file called aboot, which isn't really such a great name, since the sparse image format is only used for transferring data with fastboot.
Rename the file and header to a file called "sparse", which also makes it consistent with the header defining the image structures.

Quoted 8 lines

Quoted 1 line
Signed-off-by Maxime Ripard <[email protected]>
In general, yes this is better so:
Reviewed-by Tom Rini <[email protected]>
But I honestly thought you were messing with the Linux sparse stuff at first. So maybe common/image-spare.[ch] ?

Ah, good point. Yes, I'll rename it :)

Thanks!
Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150906/b1c6caef/attachment.sig>

Maxime Ripard

author

2015-08-31 14:46 UTC #28 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

In reply to Maxime Ripard

When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.

Increase it to something that looks decent for such a use case.

Signed-off-by Maxime Ripard <[email protected]>

---
 include/configs/sunxi-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

include/configs/sunxi-common.h +1 -1

index 1abf73c31179..710521c617f5 100644
@@ -363,7 +363,7 @@ extern int soft_i2c_gpio_scl;
 #ifdef CONFIG_USB_FUNCTION_FASTBOOT
 #define CONFIG_CMD_FASTBOOT
 #define CONFIG_FASTBOOT_BUF_ADDR	CONFIG_SYS_LOAD_ADDR
-#define CONFIG_FASTBOOT_BUF_SIZE	0x2000000
+#define CONFIG_FASTBOOT_BUF_SIZE	(256 << 20)
 
 #define CONFIG_FASTBOOT_FLASH
 #define CONFIG_FASTBOOT_FLASH_MMC_DEV	0

Signature · 1 line

2.5.0

Hans de Goede

2015-08-31 15:01 UTC #29 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

Hi,

Quoted 15 lines · Maxime Ripard

When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
Increase it to something that looks decent for such a use case.
Signed-off-by Maxime Ripard <[email protected]>
---
  include/configs/sunxi-common.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/sunxi-common.h +0 -0
index 1abf73c31179..710521c617f5 100644

include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 366

Quoted 5 lines

include/configs/sunxi-common.h +1 -1

@@ -363,7 +363,7 @@ extern int soft_i2c_gpio_scl;
  #ifdef CONFIG_USB_FUNCTION_FASTBOOT
  #define CONFIG_CMD_FASTBOOT
  #define CONFIG_FASTBOOT_BUF_ADDR	CONFIG_SYS_LOAD_ADDR
-#define CONFIG_FASTBOOT_BUF_SIZE	0x2000000
+#define CONFIG_FASTBOOT_BUF_SIZE	(256 << 20)

Hmm, where / how does this get allocated? On some boards we only have 256M RAM, so this is not going to fit ... also if this comes out of the heap, the current heap is only 4M and the wip sunxi nand patches boost it to 64 (I still need to verify this works on a 256M board, this may need a tweak to bootm_size to make sure the bootm code does not try to put the kernel where it conflicts with the heap ...).

Regards,

Hans

Rob Herring

2015-08-31 19:17 UTC #30 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

Quoted 27 lines · Hans de Goede

Hi,
Quoted 17 lines · Maxime Ripard
When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
Increase it to something that looks decent for such a use case.
Signed-off-by Maxime Ripard <[email protected]>
---
  include/configs/sunxi-common.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/sunxi-common.h +0 -0
index 1abf73c31179..710521c617f5 100644
include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 366
Quoted 5 lines
include/configs/sunxi-common.h +1 -1
@@ -363,7 +363,7 @@ extern int soft_i2c_gpio_scl;
  #ifdef CONFIG_USB_FUNCTION_FASTBOOT
  #define CONFIG_CMD_FASTBOOT
  #define CONFIG_FASTBOOT_BUF_ADDR      CONFIG_SYS_LOAD_ADDR
-#define CONFIG_FASTBOOT_BUF_SIZE       0x2000000
+#define CONFIG_FASTBOOT_BUF_SIZE       (256 << 20)

Quoted 7 lines

Hmm, where / how does this get allocated? On some boards we only have 256M RAM, so this is not going to fit ... also if this comes out of the heap, the current heap is only 4M and the wip sunxi nand patches boost it to 64 (I still need to verify this works on a 256M board, this may need a tweak to bootm_size to make sure the bootm code does not try to put the kernel where it conflicts with the heap ...).

I don't think this needs to be so big with current fastboot tool. It will break up the files if needed. However, IIRC this only works for sparse images, so I think this needs to be sized large enough for your biggest bootimage.

Rob

Maxime Ripard

author

2015-09-01 07:14 UTC #31 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

Quoted 36 lines · Rob Herring

Quoted 27 lines · Hans de Goede
Hi,
Quoted 17 lines · Maxime Ripard
When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
Increase it to something that looks decent for such a use case.
Signed-off-by Maxime Ripard <[email protected]>
---
  include/configs/sunxi-common.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/sunxi-common.h +0 -0
index 1abf73c31179..710521c617f5 100644
include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 366
Quoted 5 lines
include/configs/sunxi-common.h +1 -1
@@ -363,7 +363,7 @@ extern int soft_i2c_gpio_scl;
  #ifdef CONFIG_USB_FUNCTION_FASTBOOT
  #define CONFIG_CMD_FASTBOOT
  #define CONFIG_FASTBOOT_BUF_ADDR      CONFIG_SYS_LOAD_ADDR
-#define CONFIG_FASTBOOT_BUF_SIZE       0x2000000
+#define CONFIG_FASTBOOT_BUF_SIZE       (256 << 20)
Quoted 7 lines
Hmm, where / how does this get allocated? On some boards we only have 256M RAM, so this is not going to fit ... also if this comes out of the heap, the current heap is only 4M and the wip sunxi nand patches boost it to 64 (I still need to verify this works on a 256M board, this may need a tweak to bootm_size to make sure the bootm code does not try to put the kernel where it conflicts with the heap ...).

Quoted 4 lines

I don't think this needs to be so big with current fastboot tool. It will break up the files if needed. However, IIRC this only works for sparse images, so I think this needs to be sized large enough for your biggest bootimage.

Hmm, interesting.

Do you know how it works exactly ? Are we expected to just go on with writing data at the offset we previously stopped in such a case? I don't think we support that currently.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150901/d4ac449b/attachment.sig>

Rob Herring

2015-09-08 13:00 UTC #32 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

Quoted 42 lines · Maxime Ripard

Quoted 36 lines · Rob Herring
Quoted 27 lines · Hans de Goede
Hi,
Quoted 17 lines · Maxime Ripard
When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
Increase it to something that looks decent for such a use case.
Signed-off-by Maxime Ripard <[email protected]>
---
  include/configs/sunxi-common.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/sunxi-common.h +0 -0
index 1abf73c31179..710521c617f5 100644
include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 366
Quoted 5 lines
include/configs/sunxi-common.h +1 -1
@@ -363,7 +363,7 @@ extern int soft_i2c_gpio_scl;
  #ifdef CONFIG_USB_FUNCTION_FASTBOOT
  #define CONFIG_CMD_FASTBOOT
  #define CONFIG_FASTBOOT_BUF_ADDR      CONFIG_SYS_LOAD_ADDR
-#define CONFIG_FASTBOOT_BUF_SIZE       0x2000000
+#define CONFIG_FASTBOOT_BUF_SIZE       (256 << 20)
Quoted 7 lines
Hmm, where / how does this get allocated? On some boards we only have 256M RAM, so this is not going to fit ... also if this comes out of the heap, the current heap is only 4M and the wip sunxi nand patches boost it to 64 (I still need to verify this works on a 256M board, this may need a tweak to bootm_size to make sure the bootm code does not try to put the kernel where it conflicts with the heap ...).
Quoted 4 lines
I don't think this needs to be so big with current fastboot tool. It will break up the files if needed. However, IIRC this only works for sparse images, so I think this needs to be sized large enough for your biggest bootimage.

Quoted 5 lines

Hmm, interesting.
Do you know how it works exactly ? Are we expected to just go on with writing data at the offset we previously stopped in such a case? I don't think we support that currently.

The hard work is on the client side. The client will retrieve the maxdownloadsize variable and then split the sparse image into smaller hunks if needed. So the u-boot side doesn't have to do anything special if 2 chunks happen to be contiguous.

Rob

Maxime Ripard

author

2015-09-08 15:44 UTC #33 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

Quoted 46 lines · Rob Herring

Quoted 44 lines · Maxime Ripard
Quoted 36 lines · Rob Herring
Quoted 27 lines · Hans de Goede
Hi,
Quoted 17 lines · Maxime Ripard
When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
Increase it to something that looks decent for such a use case.
Signed-off-by Maxime Ripard <[email protected]>
---
  include/configs/sunxi-common.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/sunxi-common.h +0 -0
index 1abf73c31179..710521c617f5 100644
include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 366
Quoted 5 lines
include/configs/sunxi-common.h +1 -1
@@ -363,7 +363,7 @@ extern int soft_i2c_gpio_scl;
  #ifdef CONFIG_USB_FUNCTION_FASTBOOT
  #define CONFIG_CMD_FASTBOOT
  #define CONFIG_FASTBOOT_BUF_ADDR      CONFIG_SYS_LOAD_ADDR
-#define CONFIG_FASTBOOT_BUF_SIZE       0x2000000
+#define CONFIG_FASTBOOT_BUF_SIZE       (256 << 20)
Quoted 7 lines
Hmm, where / how does this get allocated? On some boards we only have 256M RAM, so this is not going to fit ... also if this comes out of the heap, the current heap is only 4M and the wip sunxi nand patches boost it to 64 (I still need to verify this works on a 256M board, this may need a tweak to bootm_size to make sure the bootm code does not try to put the kernel where it conflicts with the heap ...).
Quoted 4 lines
I don't think this needs to be so big with current fastboot tool. It will break up the files if needed. However, IIRC this only works for sparse images, so I think this needs to be sized large enough for your biggest bootimage.
Hmm, interesting.

Quoted 8 lines

Quoted 3 lines
Do you know how it works exactly ? Are we expected to just go on with writing data at the offset we previously stopped in such a case? I don't think we support that currently.
The hard work is on the client side. The client will retrieve the maxdownloadsize variable and then split the sparse image into smaller hunks if needed. So the u-boot side doesn't have to do anything special if 2 chunks happen to be contiguous.

Well, it still has to make sure it keeps the offset of the current session instead of restarting from the partition base offset, and I'm not sure I've seen anything like it for now.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150908/85230286/attachment.sig>

Maxime Ripard

author

2015-09-01 07:05 UTC #34 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

In reply to Hans de Goede

Hi,

Quoted 22 lines · Hans de Goede

Quoted 15 lines · Maxime Ripard
When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
Increase it to something that looks decent for such a use case.
Signed-off-by Maxime Ripard <[email protected]>
---
 include/configs/sunxi-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/sunxi-common.h +0 -0
index 1abf73c31179..710521c617f5 100644
include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 366
Quoted 5 lines
include/configs/sunxi-common.h +1 -1
@@ -363,7 +363,7 @@ extern int soft_i2c_gpio_scl;
 #ifdef CONFIG_USB_FUNCTION_FASTBOOT
 #define CONFIG_CMD_FASTBOOT
 #define CONFIG_FASTBOOT_BUF_ADDR	CONFIG_SYS_LOAD_ADDR
-#define CONFIG_FASTBOOT_BUF_SIZE	0x2000000
+#define CONFIG_FASTBOOT_BUF_SIZE	(256 << 20)

Quoted 7 lines

Hmm, where / how does this get allocated? On some boards we only have 256M RAM, so this is not going to fit ... also if this comes out of the heap, the current heap is only 4M and the wip sunxi nand patches boost it to 64 (I still need to verify this works on a 256M board, this may need a tweak to bootm_size to make sure the bootm code does not try to put the kernel where it conflicts with the heap ...).

It's not allocated, it just uses the RAM directly, starting at the offset CONFIG_FASTBOOT_BUF_ADDR (0x42000000 in our case), just like any *load function for example.

The only thing we have to make sure is that we won't overwrite U-boot itself, which will be an issue on those 256MB boards...

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150901/33bda824/attachment.sig>

Hans de Goede

2015-09-01 08:59 UTC #35 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

Hi,

Quoted 33 lines · Maxime Ripard

Hi,
Quoted 22 lines · Hans de Goede
Quoted 15 lines · Maxime Ripard
When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
Increase it to something that looks decent for such a use case.
Signed-off-by Maxime Ripard <[email protected]>
---
  include/configs/sunxi-common.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/sunxi-common.h +0 -0
index 1abf73c31179..710521c617f5 100644
include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 366
Quoted 5 lines
include/configs/sunxi-common.h +1 -1
@@ -363,7 +363,7 @@ extern int soft_i2c_gpio_scl;
  #ifdef CONFIG_USB_FUNCTION_FASTBOOT
  #define CONFIG_CMD_FASTBOOT
  #define CONFIG_FASTBOOT_BUF_ADDR	CONFIG_SYS_LOAD_ADDR
-#define CONFIG_FASTBOOT_BUF_SIZE	0x2000000
+#define CONFIG_FASTBOOT_BUF_SIZE	(256 << 20)
Quoted 7 lines
Hmm, where / how does this get allocated? On some boards we only have 256M RAM, so this is not going to fit ... also if this comes out of the heap, the current heap is only 4M and the wip sunxi nand patches boost it to 64 (I still need to verify this works on a 256M board, this may need a tweak to bootm_size to make sure the bootm code does not try to put the kernel where it conflicts with the heap ...).

Quoted 6 lines

It's not allocated, it just uses the RAM directly, starting at the offset CONFIG_FASTBOOT_BUF_ADDR (0x42000000 in our case), just like any *load function for example.
The only thing we have to make sure is that we won't overwrite U-boot itself, which will be an issue on those 256MB boards...

Well the only 256M board is the A13-OLinuXino-MICRO, all other boards have at least 512M and the A13-OLinuXino-MICRO does not have nand, so I guess we do not really need to worry about this.

Regards,

Hans

Maxime Ripard

author

2015-09-03 21:43 UTC #36 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

Quoted 40 lines · Hans de Goede

Hi,
Quoted 37 lines · Maxime Ripard
Hi,
Quoted 22 lines · Hans de Goede
Quoted 15 lines · Maxime Ripard
When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
Increase it to something that looks decent for such a use case.
Signed-off-by Maxime Ripard <[email protected]>
---
 include/configs/sunxi-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/sunxi-common.h +0 -0
index 1abf73c31179..710521c617f5 100644
include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 366
Quoted 5 lines
include/configs/sunxi-common.h +1 -1
@@ -363,7 +363,7 @@ extern int soft_i2c_gpio_scl;
 #ifdef CONFIG_USB_FUNCTION_FASTBOOT
 #define CONFIG_CMD_FASTBOOT
 #define CONFIG_FASTBOOT_BUF_ADDR	CONFIG_SYS_LOAD_ADDR
-#define CONFIG_FASTBOOT_BUF_SIZE	0x2000000
+#define CONFIG_FASTBOOT_BUF_SIZE	(256 << 20)
Quoted 7 lines
Hmm, where / how does this get allocated? On some boards we only have 256M RAM, so this is not going to fit ... also if this comes out of the heap, the current heap is only 4M and the wip sunxi nand patches boost it to 64 (I still need to verify this works on a 256M board, this may need a tweak to bootm_size to make sure the bootm code does not try to put the kernel where it conflicts with the heap ...).
It's not allocated, it just uses the RAM directly, starting at the offset CONFIG_FASTBOOT_BUF_ADDR (0x42000000 in our case), just like any *load function for example.

Quoted 6 lines

Quoted 2 lines
The only thing we have to make sure is that we won't overwrite U-boot itself, which will be an issue on those 256MB boards...
Well the only 256M board is the A13-OLinuXino-MICRO, all other boards have at least 512M and the A13-OLinuXino-MICRO does not have nand, so I guess we do not really need to worry about this.

You could use fastboot to flash something on the MMC, so I guess it is something to worry about :)

Rob was kind of saying that such a huge value wasn't needed, so I guess we can simply drop that patch.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150903/7431cab1/attachment.sig>

Siarhei Siamashka

2015-09-01 08:02 UTC #37 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

In reply to Hans de Goede

Quoted 24 lines · On Mon, 31 Aug 2015 17:01:42 +0200 Hans de Goede <[email protected]> wrote:

Hi,
Quoted 15 lines · Maxime Ripard
When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
Increase it to something that looks decent for such a use case.
Signed-off-by Maxime Ripard <[email protected]>
---
  include/configs/sunxi-common.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/sunxi-common.h +0 -0
index 1abf73c31179..710521c617f5 100644
include/configs/sunxi-common.h extern int soft_i2c_gpio_scl; · line 366
Quoted 5 lines
include/configs/sunxi-common.h +1 -1
@@ -363,7 +363,7 @@ extern int soft_i2c_gpio_scl;
  #ifdef CONFIG_USB_FUNCTION_FASTBOOT
  #define CONFIG_CMD_FASTBOOT
  #define CONFIG_FASTBOOT_BUF_ADDR	CONFIG_SYS_LOAD_ADDR
-#define CONFIG_FASTBOOT_BUF_SIZE	0x2000000
+#define CONFIG_FASTBOOT_BUF_SIZE	(256 << 20)

Quoted 7 lines

Hmm, where / how does this get allocated? On some boards we only have 256M RAM, so this is not going to fit ... also if this comes out of the heap, the current heap is only 4M and the wip sunxi nand patches boost it to 64 (I still need to verify this works on a 256M board, this may need a tweak to bootm_size to make sure the bootm code does not try to put the kernel where it conflicts with the heap ...).

Can this be eventually improved to become a dynamic limit (depending on the RAM size available on the device) instead of the "one size fits all" hardcoded define approach?

Signature · 2 lines

Best regards,
Siarhei Siamashka

Ian Campbell

2015-09-01 07:22 UTC #38 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

In reply to Maxime Ripard

Quoted 2 lines · Maxime Ripard

When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.

(Apart from rooting/rescuing the odd phone I'm completely unfamiliar with fastboot, so sorry if this is all obvious).

The main partition of a system these days is measured in GB, I think. So why does going from 32MB to 256MB for the buffer make a useful difference?

Is there some enormous per-buffer overhead which needs to be amortised? Or is something else going on?

IOW what is the practical impact of this change?

Quoted 21 lines

Increase it to something that looks decent for such a use case.
Signed-off-by Maxime Ripard <[email protected]>
---
 include/configs/sunxi-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/configs/sunxi renamed from include/configs/sunxi-common.h +0 -1
-common.h
index 1abf73c31179..710521c617f5 100644
include/configs/sunxi-common.h +1 -1
@@ -363,7 +363,7 @@ extern int soft_i2c_gpio_scl;
 #ifdef CONFIG_USB_FUNCTION_FASTBOOT
 #define CONFIG_CMD_FASTBOOT
 #define CONFIG_FASTBOOT_BUF_ADDR	CONFIG_SYS_LOAD_ADDR
-#define CONFIG_FASTBOOT_BUF_SIZE	0x2000000
+#define CONFIG_FASTBOOT_BUF_SIZE	(256 << 20)
 
 #define CONFIG_FASTBOOT_FLASH
 #define CONFIG_FASTBOOT_FLASH_MMC_DEV	0

Siarhei Siamashka

2015-09-01 07:44 UTC #39 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

Quoted 7 lines · On Tue, 01 Sep 2015 08:22:04 +0100 Ian Campbell <[email protected]> wrote:

Quoted 2 lines · Maxime Ripard
When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
(Apart from rooting/rescuing the odd phone I'm completely unfamiliar with fastboot, so sorry if this is all obvious).

Quoted 8 lines

The main partition of a system these days is measured in GB, I think. So why does going from 32MB to 256MB for the buffer make a useful difference?
Is there some enormous per-buffer overhead which needs to be amortised? Or is something else going on?
IOW what is the practical impact of this change?

I don't know what are Maxime's plans. But if fastboot is fast and can load the kernel and initrd to the device over USB, then it becomes a useful alternative to using FEL for loading kernel.

FEL is implemented by BROM, but it is not particularly fast and the transfer speed varies for different SoC variants:
http://linux-sunxi.org/FEL/USBBoot#SoC_support_status

Somebody might want to evaluate the use of fastboot for loading kernel with initrd and document it at http://linux-sunxi.org/FEL/USBBoot

FEL is still needed for loading U-Boot over USB on sunxi hardware, but U-Boot size is relatively small compared to the kernel, and especially initrd.

Signature · 2 lines

Best regards,
Siarhei Siamashka

Maxime Ripard

author

2015-09-01 08:11 UTC #40 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

Quoted 14 lines · Siarhei Siamashka

Quoted 11 lines · On Tue, 01 Sep 2015 08:22:04 +0100 Ian Campbell <[email protected]> wrote:
Quoted 2 lines · Maxime Ripard
When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
(Apart from rooting/rescuing the odd phone I'm completely unfamiliar with fastboot, so sorry if this is all obvious).
The main partition of a system these days is measured in GB, I think. So why does going from 32MB to 256MB for the buffer make a useful difference?

Quoted 8 lines

Quoted 4 lines
Is there some enormous per-buffer overhead which needs to be amortised? Or is something else going on?
IOW what is the practical impact of this change?
I don't know what are Maxime's plans. But if fastboot is fast and can load the kernel and initrd to the device over USB, then it becomes a useful alternative to using FEL for loading kernel.

This serie is mostly to use fastboot to flash partition images to the storage device. We're using it to program the flash the first time.

It's indeed significantly faster than using fel to do so (by a guesstimate, something around 30-50%), and is more pratical in the sense that you can later on reflash only a single partition, all of that through USB.

However, you can also use it to simply boot a kernel, without touching any of the device storage. The main drawback with that is that the DT has to be appended, which prevents the use of simplefb or psci in our case...

I tried to amend the android boot image format that fastboot sends when doing so to add a section for the DT, but gave up when having to deal with the image parser in u-boot.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150901/ef279425/attachment.sig>

Tom Rini

2015-09-04 17:02 UTC #41 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

In reply to Siarhei Siamashka

Quoted 14 lines · Siarhei Siamashka

Quoted 11 lines · On Tue, 01 Sep 2015 08:22:04 +0100 Ian Campbell <[email protected]> wrote:
Quoted 2 lines · Maxime Ripard
When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
(Apart from rooting/rescuing the odd phone I'm completely unfamiliar with fastboot, so sorry if this is all obvious).
The main partition of a system these days is measured in GB, I think. So why does going from 32MB to 256MB for the buffer make a useful difference?

Quoted 8 lines

Quoted 4 lines
Is there some enormous per-buffer overhead which needs to be amortised? Or is something else going on?
IOW what is the practical impact of this change?
I don't know what are Maxime's plans. But if fastboot is fast and can load the kernel and initrd to the device over USB, then it becomes a useful alternative to using FEL for loading kernel.

This is in fact a common use case for development. Other platforms / SoCs do use fastboot in non-Android development as how to pass in a new testing kernel / initrd / device tree combo.

Signature · 8 lines

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/20150904/da438a75/attachment.sig>

Maxime Ripard

author

2015-09-06 11:23 UTC #42 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

Quoted 21 lines · Tom Rini

Quoted 19 lines · Siarhei Siamashka
Quoted 15 lines · On Tue, 01 Sep 2015 08:22:04 +0100 Ian Campbell <[email protected]> wrote:
Quoted 2 lines · Maxime Ripard
When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
(Apart from rooting/rescuing the odd phone I'm completely unfamiliar with fastboot, so sorry if this is all obvious).
The main partition of a system these days is measured in GB, I think. So why does going from 32MB to 256MB for the buffer make a useful difference?
Is there some enormous per-buffer overhead which needs to be amortised? Or is something else going on?
IOW what is the practical impact of this change?

Quoted 7 lines

Quoted 3 lines
I don't know what are Maxime's plans. But if fastboot is fast and can load the kernel and initrd to the device over USB, then it becomes a useful alternative to using FEL for loading kernel.
This is in fact a common use case for development. Other platforms / SoCs do use fastboot in non-Android development as how to pass in a new testing kernel / initrd / device tree combo.

AFAIK, there's no support in fastboot for a dt yet. You can only give it a kernel with an appended DT.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150906/9c30a9f9/attachment.sig>

Maxime Ripard

author

2015-09-01 07:57 UTC #43 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

In reply to Ian Campbell

Hi Ian,

Quoted 7 lines · Ian Campbell

Quoted 2 lines · Maxime Ripard
When using fastboot and flashing a larger image such as the main partition of a system, the current 32MB limit for the buffer is quite small.
(Apart from rooting/rescuing the odd phone I'm completely unfamiliar with fastboot, so sorry if this is all obvious).

Quoted 8 lines

The main partition of a system these days is measured in GB, I think. So why does going from 32MB to 256MB for the buffer make a useful difference?
Is there some enormous per-buffer overhead which needs to be amortised? Or is something else going on?
IOW what is the practical impact of this change?

It really depends on the image content you're trying to flash, but there's two things to consider:

- On a NAND device, you will just flash the actual content, but not the extra empty space in the partition, and the FS will automatically grow the first time you mount it.

- If there's some blocks that are filled with the same content, the sparse image format I was refactoring earlier in that patchset will be able to compress it to 16 bytes (iirc), instead of a full block (512 bytes or a page, depending on whether you use an MMC or a NAND). On NAND images, there's often a lot of pages filled with 0xff, which fall into that category, I'd expect it to be similar on block partitions for the extra space.

The current use case we have for example is to flash a 4GB partition with a debian system, in a UBI partition. Even though it's a decent system, storage size-wise, the file actually transfered and stored in the memory is around 210MB once compressed, and 270MB if not compressed.

Of course, this will all depend on the ratio between the empty space and the files themselves, and what files you actually have there, but while 32MB is definitely useless, 256MB is already a decent size.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150901/579d3bde/attachment.sig>

Tom Rini

2015-09-04 16:59 UTC #44 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

On Tue, Sep 01, 2015 at 09:57:16AM +0200, Maxime Ripard wrote:

[snip]

Quoted 3 lines

Of course, this will all depend on the ratio between the empty space and the files themselves, and what files you actually have there, but while 32MB is definitely useless, 256MB is already a decent size.

So there's not any automatic chunking and writing of the image? Maybe I'm confusing this with DFU and/or my wishlist/imagination...

Signature · 8 lines

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/20150904/754cae25/attachment.sig>

Maxime Ripard

author

2015-09-06 11:22 UTC #45 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

Quoted 9 lines · Tom Rini

On Tue, Sep 01, 2015 at 09:57:16AM +0200, Maxime Ripard wrote:
[snip]
Quoted 3 lines
Of course, this will all depend on the ratio between the empty space and the files themselves, and what files you actually have there, but while 32MB is definitely useless, 256MB is already a decent size.
So there's not any automatic chunking and writing of the image? Maybe I'm confusing this with DFU and/or my wishlist/imagination...

Apparently, Rob was saying there was some, but I'm not sure we support that yet, I'd need to look into it.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150906/40f01934/attachment.sig>

Ian Campbell

2015-09-07 09:07 UTC #46 lore raw

PATCH 10/13 sunxi: Make the fastboot buffer larger

Quoted 8 lines · Maxime Ripard

Quoted 7 lines · Tom Rini
On Tue, Sep 01, 2015 at 09:57:16AM +0200, Maxime Ripard wrote:
[snip]
Quoted 3 lines
Of course, this will all depend on the ratio between the empty space and the files themselves, and what files you actually have there, but while 32MB is definitely useless, 256MB is already a decent size.

Quoted 5 lines

Quoted 2 lines
So there's not any automatic chunking and writing of the image? Maybe I'm confusing this with DFU and/or my wishlist/imagination...
Apparently, Rob was saying there was some, but I'm not sure we support that yet, I'd need to look into it.

It seems this is pretty critical, given that storage (both capacity and actual required space within the fs) are growing and 256MB is only barely big enough for the 4GB image you have today (210MB after the various compression strategies are applied).

Ian.

Maxime Ripard

author

2015-08-31 14:46 UTC #47 lore raw

PATCH 11/13 sunxi: Add support for android boot image

In reply to Maxime Ripard

When using the fastboot boot command, the image sent to U-Boot will be an Android boot image. If the support is missing, that won't obviously work, so we need it in our configuration.

Signed-off-by Maxime Ripard <[email protected]>

---
 include/configs/sunxi-common.h | 1 +
 1 file changed, 1 insertion(+)

include/configs/sunxi-common.h +1 -0

index 710521c617f5..ee81fa9a1142 100644
@@ -364,6 +364,7 @@ extern int soft_i2c_gpio_scl;
 #define CONFIG_CMD_FASTBOOT
 #define CONFIG_FASTBOOT_BUF_ADDR	CONFIG_SYS_LOAD_ADDR
 #define CONFIG_FASTBOOT_BUF_SIZE	(256 << 20)
+#define CONFIG_ANDROID_BOOT_IMAGE
 
 #define CONFIG_FASTBOOT_FLASH
 #define CONFIG_FASTBOOT_FLASH_MMC_DEV	0

Signature · 1 line

2.5.0

Ian Campbell

2015-09-01 07:08 UTC #48 lore raw

PATCH 11/13 sunxi: Add support for android boot image

Quoted 3 lines · Maxime Ripard

When using the fastboot boot command, the image sent to U-Boot will be an Android boot image. If the support is missing, that won't obviously work, so we need it in our configuration.

Dumb question: Is it possible to boot anything _other_ than an android boot image via fastboot?

If not then one of the two config options really ought to imply the other.

If it is possible to boot something else via fastboot then:

Acked-by Ian Campbell <[email protected]>

Ian.

Maxime Ripard

author

2015-09-01 07:15 UTC #49 lore raw

PATCH 11/13 sunxi: Add support for android boot image

Quoted 7 lines · Ian Campbell

Quoted 3 lines · Maxime Ripard
When using the fastboot boot command, the image sent to U-Boot will be an Android boot image. If the support is missing, that won't obviously work, so we need it in our configuration.
Dumb question: Is it possible to boot anything _other_ than an android boot image via fastboot?

AFAIK, the fastboot tool will automatically generate an android boot image when given any image, and will send that. I don't think there's any way to circumvent that behaviour.

Quoted 2 lines

If not then one of the two config options really ought to imply the other.

Yeah, probably.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150901/6c1ae8dd/attachment.sig>

Paul Kocialkowski

2015-09-01 09:00 UTC #50 lore raw

PATCH 11/13 sunxi: Add support for android boot image

In reply to Ian Campbell

Le mardi 01 septembre 2015 ? 08:08 +0100, Ian Campbell a ?crit :

Quoted 10 lines · Maxime Ripard

Quoted 3 lines
When using the fastboot boot command, the image sent to U-Boot will be an Android boot image. If the support is missing, that won't obviously work, so we need it in our configuration.
Dumb question: Is it possible to boot anything _other_ than an android boot image via fastboot?
If not then one of the two config options really ought to imply the other.

Well, those options have not been moved to Kconfig yet, but when they do, there should indeed be such a dependency.

Otherwise, I believe it still makes sense to have two separate options because one might want Android boot image support without fastboot.

Quoted 4 lines

If it is possible to boot something else via fastboot then:
Acked-by Ian Campbell <[email protected]>
Ian.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150901/19d9b17c/attachment.sig>

Ian Campbell

2015-09-01 10:46 UTC #51 lore raw

PATCH 11/13 sunxi: Add support for android boot image

Quoted 11 lines · Paul Kocialkowski

Le mardi 01 septembre 2015 ? 08:08 +0100, Ian Campbell a ?crit :
Quoted 10 lines · Maxime Ripard
Quoted 5 lines
When using the fastboot boot command, the image sent to U-Boot will be an
Android boot image. If the support is missing, that won't obviously work,
so we need it in our configuration.
Dumb question: Is it possible to boot anything _other_ than an android boot image via fastboot?

Quoted 8 lines

Quoted 2 lines
If not then one of the two config options really ought to imply the other.
Well, those options have not been moved to Kconfig yet, but when they do, there should indeed be such a dependency.
Otherwise, I believe it still makes sense to have two separate options because one might want Android boot image support without fastboot.

Then fastboot should depend on android boot image support but not vice -versa.

Quoted 6 lines

Quoted 5 lines
If it is possible to boot something else via fastboot then:
Acked-by Ian Campbell <[email protected]>
Ian.

Maxime Ripard

author

2015-09-01 11:29 UTC #52 lore raw

PATCH 11/13 sunxi: Add support for android boot image

Quoted 15 lines · Ian Campbell

Quoted 14 lines · Paul Kocialkowski
Le mardi 01 septembre 2015 ? 08:08 +0100, Ian Campbell a ?crit :
Quoted 12 lines · Maxime Ripard
Quoted 5 lines
When using the fastboot boot command, the image sent to U-Boot will be an
Android boot image. If the support is missing, that won't obviously work,
so we need it in our configuration.
Dumb question: Is it possible to boot anything _other_ than an android boot image via fastboot?
If not then one of the two config options really ought to imply the other.

Quoted 8 lines

Quoted 5 lines
Well, those options have not been moved to Kconfig yet, but when they do, there should indeed be such a dependency.
Otherwise, I believe it still makes sense to have two separate options because one might want Android boot image support without fastboot.
Then fastboot should depend on android boot image support but not vice -versa.

Indeed, but it's not yet a Kconfig option.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150901/fbcd214a/attachment.sig>

Ian Campbell

2015-09-01 13:54 UTC #53 lore raw

PATCH 11/13 sunxi: Add support for android boot image

Quoted 22 lines · Maxime Ripard

Quoted 21 lines · Ian Campbell
Quoted 20 lines · Paul Kocialkowski
Le mardi 01 septembre 2015 ? 08:08 +0100, Ian Campbell a ?crit :
Quoted 9 lines · Maxime Ripard
Quoted 7 lines
When using the fastboot boot command, the image sent to U-Boot will
be an
Android boot image. If the support is missing, that won't obviously
work,
so we need it in our configuration.
Quoted 6 lines
Dumb question: Is it possible to boot anything _other_ than an android
boot image via fastboot?
If not then one of the two config options really ought to imply the other.
Well, those options have not been moved to Kconfig yet, but when they do, there should indeed be such a dependency.

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
Otherwise, I believe it still makes sense to have two separate options
because one might want Android boot image support without fastboot.
Then fastboot should depend on android boot image support but not vice -versa.
Indeed, but it's not yet a Kconfig option.

I'm not sure that's a necessary prerequisite, in some common place do:

#if defined(CONFIG_CMD_FASTBOOT) && !defined(CONFIG_ANDROID_BOOT_IMAGE) #define CONFIG_ANDROID_BOOT_IMAGE
#endif

Ian.

Paul Kocialkowski

2015-09-01 13:59 UTC #54 lore raw

PATCH 11/13 sunxi: Add support for android boot image

Le mardi 01 septembre 2015 ? 14:54 +0100, Ian Campbell a ?crit :

Quoted 30 lines · Maxime Ripard

Quoted 29 lines · Ian Campbell
Quoted 27 lines · Paul Kocialkowski
Quoted 17 lines
Le mardi 01 septembre 2015 ? 08:08 +0100, Ian Campbell a ?crit :
Quoted 9 lines · Maxime Ripard
Quoted 7 lines
When using the fastboot boot command, the image sent to U-Boot will
be an
Android boot image. If the support is missing, that won't obviously
work,
so we need it in our configuration.
Quoted 6 lines
Dumb question: Is it possible to boot anything _other_ than an android
boot image via fastboot?
If not then one of the two config options really ought to imply the other.
Quoted 6 lines
Well, those options have not been moved to Kconfig yet, but when they do, there should indeed be such a dependency.
Otherwise, I believe it still makes sense to have two separate options
because one might want Android boot image support without fastboot.
Then fastboot should depend on android boot image support but not vice -versa.

Quoted 7 lines

Quoted 1 line
Indeed, but it's not yet a Kconfig option.
I'm not sure that's a necessary prerequisite, in some common place do:
#if defined(CONFIG_CMD_FASTBOOT) && !defined(CONFIG_ANDROID_BOOT_IMAGE) #define CONFIG_ANDROID_BOOT_IMAGE
#endif

Well, I'm not sure adding Kconfig-style logic really is a good idea as it removes some incentive to do things right and move everything over to Kconfig (which is out of the scope of this patch set, I believe).

In addition, I don't see what a relevant place to but this in would be. Putting that in sunxi-common.h is just adding two useless extra lines (having the define is sufficient).

Overall, I don't think this is a good idea when we have Kconfig around the corner to do things right?

Signature · 16 lines

Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150901/d506c28d/attachment.sig>

Maxime Ripard

author

2015-09-01 11:28 UTC #55 lore raw

PATCH 11/13 sunxi: Add support for android boot image

In reply to Paul Kocialkowski

Quoted 9 lines · Paul Kocialkowski

Le mardi 01 septembre 2015 ? 08:08 +0100, Ian Campbell a ?crit :
Quoted 8 lines · Maxime Ripard
Quoted 3 lines
When using the fastboot boot command, the image sent to U-Boot will be an Android boot image. If the support is missing, that won't obviously work, so we need it in our configuration.
Dumb question: Is it possible to boot anything _other_ than an android boot image via fastboot?

Quoted 8 lines

Quoted 2 lines
If not then one of the two config options really ought to imply the other.
Well, those options have not been moved to Kconfig yet, but when they do, there should indeed be such a dependency.
Otherwise, I believe it still makes sense to have two separate options because one might want Android boot image support without fastboot.

Ah, good point, Android stores its kernel/initrd in that format. So even if you don't want fastboot, you might want the support for the image itself.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150901/a6e7dccc/attachment.sig>

Rob Herring

2015-09-08 13:12 UTC #56 lore raw

PATCH 11/13 sunxi: Add support for android boot image

In reply to Ian Campbell

Quoted 7 lines · Ian Campbell

Quoted 3 lines · Maxime Ripard
When using the fastboot boot command, the image sent to U-Boot will be an Android boot image. If the support is missing, that won't obviously work, so we need it in our configuration.
Dumb question: Is it possible to boot anything _other_ than an android boot image via fastboot?

Yes, fastboot just writes either raw block data or sparse images to partitions. While the client tool can create the boot image for you, that is purely a client side feature. What you can boot is determined by your boot scripts. You can also boot an Android boot image with bootm and without any fastboot support.

Rob

Maxime Ripard

author

2015-08-31 14:46 UTC #57 lore raw

PATCH 12/13 sunxi: A13-Olinuxino: Enable the USB OTG controller

In reply to Maxime Ripard

The A13-Olinuxino has a mini-USB connector that can be used to power up the board and as an OTG connector.

Since we have already some USB host-only ports right beside this one, enable it in gadget mode

Signed-off-by Maxime Ripard <[email protected]>

---
 configs/A13-OLinuXino_defconfig | 2 ++
 1 file changed, 2 insertions(+)

configs/A13-OLinuXino_defconfig +2 -0

index 4b4337223ca5..70aa194b91c4 100644
@@ -3,6 +3,7 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN5I=y
 CONFIG_DRAM_CLK=408
 CONFIG_DRAM_EMR1=0
+CONFIG_USB0_VBUS_DET="PG1"
 CONFIG_USB1_VBUS_PIN="PG11"
 CONFIG_AXP_GPIO=y
 # CONFIG_VIDEO_HDMI is not set

@@ -11,6 +12,7 @@ CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y
 CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0"
 CONFIG_VIDEO_LCD_POWER="AXP0-0"
 CONFIG_VIDEO_LCD_BL_PWM="PB2"
+CONFIG_USB_MUSB_SUNXI=y
 CONFIG_DEFAULT_DEVICE_TREE="sun5i-a13-olinuxino"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL=y

Signature · 1 line

2.5.0

Hans de Goede

2015-09-01 09:01 UTC #58 lore raw

PATCH 12/13 sunxi: A13-Olinuxino: Enable the USB OTG controller

Hi,

Quoted 24 lines · Maxime Ripard

The A13-Olinuxino has a mini-USB connector that can be used to power up the board and as an OTG connector.
Since we have already some USB host-only ports right beside this one, enable it in gadget mode
Signed-off-by Maxime Ripard <[email protected]>
---
  configs/A13-OLinuXino_defconfig | 2 ++
  1 file changed, 2 insertions(+)
configs/A13-OLinuXino_defconfig +1 -0
index 4b4337223ca5..70aa194b91c4 100644
@@ -3,6 +3,7 @@ CONFIG_ARCH_SUNXI=y
  CONFIG_MACH_SUN5I=y
  CONFIG_DRAM_CLK=408
  CONFIG_DRAM_EMR1=0
+CONFIG_USB0_VBUS_DET="PG1"
  CONFIG_USB1_VBUS_PIN="PG11"
  CONFIG_AXP_GPIO=y
  # CONFIG_VIDEO_HDMI is not set

configs/A13-OLinuXino_defconfig CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y · line 18

Quoted 7 lines

configs/A13-OLinuXino_defconfig +1 -0

@@ -11,6 +12,7 @@ CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y
  CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0"
  CONFIG_VIDEO_LCD_POWER="AXP0-0"
  CONFIG_VIDEO_LCD_BL_PWM="PB2"
+CONFIG_USB_MUSB_SUNXI=y
  CONFIG_DEFAULT_DEVICE_TREE="sun5i-a13-olinuxino"
  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
  CONFIG_SPL=y

The CONFIG_xxx defines for using MUSB in either host or gadget mode have changed in v2015.10, looks like you need to rebase this series and fix this.

Regards,

Hans

Maxime Ripard

author

2015-09-03 21:41 UTC #59 lore raw

PATCH 12/13 sunxi: A13-Olinuxino: Enable the USB OTG controller

Hi Hans,

Quoted 30 lines · Hans de Goede

Hi,
Quoted 27 lines · Maxime Ripard
The A13-Olinuxino has a mini-USB connector that can be used to power up the board and as an OTG connector.
Since we have already some USB host-only ports right beside this one, enable it in gadget mode
Signed-off-by Maxime Ripard <[email protected]>
---
 configs/A13-OLinuXino_defconfig | 2 ++
 1 file changed, 2 insertions(+)
configs/A13-OLinuXino_defconfig +1 -0
index 4b4337223ca5..70aa194b91c4 100644
@@ -3,6 +3,7 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN5I=y
 CONFIG_DRAM_CLK=408
 CONFIG_DRAM_EMR1=0
+CONFIG_USB0_VBUS_DET="PG1"
 CONFIG_USB1_VBUS_PIN="PG11"
 CONFIG_AXP_GPIO=y
 # CONFIG_VIDEO_HDMI is not set
@@ -11,6 +12,7 @@ CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y
 CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0"
 CONFIG_VIDEO_LCD_POWER="AXP0-0"
 CONFIG_VIDEO_LCD_BL_PWM="PB2"

Quoted 8 lines

configs/A13-OLinuXino_defconfig CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y · line 18
Quoted 4 lines
configs/A13-OLinuXino_defconfig +1 -0
+CONFIG_USB_MUSB_SUNXI=y
 CONFIG_DEFAULT_DEVICE_TREE="sun5i-a13-olinuxino"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL=y
The CONFIG_xxx defines for using MUSB in either host or gadget mode have changed in v2015.10, looks like you need to rebase this series and fix this.

This was based on 2015.10-rc2. I enabled it as a gadget through menuconfig. What is the policy on using gadget vs host? I guess it would make more sense to enable all the OTG connectors to gadget, but maybe that's just me.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150903/f3d60092/attachment.sig>

Hans de Goede

2015-09-10 18:47 UTC #60 lore raw

PATCH 12/13 sunxi: A13-Olinuxino: Enable the USB OTG controller

Hi,

Quoted 42 lines · Maxime Ripard

Hi Hans,
Quoted 30 lines · Hans de Goede
Hi,
Quoted 27 lines · Maxime Ripard
The A13-Olinuxino has a mini-USB connector that can be used to power up the board and as an OTG connector.
Since we have already some USB host-only ports right beside this one, enable it in gadget mode
Signed-off-by Maxime Ripard <[email protected]>
---
  configs/A13-OLinuXino_defconfig | 2 ++
  1 file changed, 2 insertions(+)
configs/A13-OLinuXino_defconfig +1 -0
index 4b4337223ca5..70aa194b91c4 100644
@@ -3,6 +3,7 @@ CONFIG_ARCH_SUNXI=y
  CONFIG_MACH_SUN5I=y
  CONFIG_DRAM_CLK=408
  CONFIG_DRAM_EMR1=0
+CONFIG_USB0_VBUS_DET="PG1"
  CONFIG_USB1_VBUS_PIN="PG11"
  CONFIG_AXP_GPIO=y
  # CONFIG_VIDEO_HDMI is not set
@@ -11,6 +12,7 @@ CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y
  CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0"
  CONFIG_VIDEO_LCD_POWER="AXP0-0"
  CONFIG_VIDEO_LCD_BL_PWM="PB2"
Quoted 8 lines
configs/A13-OLinuXino_defconfig CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y · line 18
Quoted 4 lines
configs/A13-OLinuXino_defconfig +1 -0
+CONFIG_USB_MUSB_SUNXI=y
  CONFIG_DEFAULT_DEVICE_TREE="sun5i-a13-olinuxino"
  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
  CONFIG_SPL=y
The CONFIG_xxx defines for using MUSB in either host or gadget mode have changed in v2015.10, looks like you need to rebase this series and fix this.

Quoted 1 line

This was based on 2015.10-rc2.

Are you sure?

drivers/usb/musb-new/Kconfig has:

config USB_MUSB_HOST
bool "MUSB host mode support"
help
Enables the MUSB USB dual-role controller in host mode.

config USB_MUSB_GADGET
bool "MUSB gadget mode support"
help
Enables the MUSB USB dual-role controller in gadget mode.

if USB_MUSB_HOST || USB_MUSB_GADGET

config USB_MUSB_SUNXI
bool "Enable sunxi OTG / DRC USB controller"
depends on ARCH_SUNXI
default y
---help---
Say y here to enable support for the sunxi OTG / DRC USB controller used on almost all sunxi boards.

endif

And you are not setting USB_MUSB_HOST nor USB_MUSB_GADGET so you should never get a chance to set USB_MUSB_SUNXI. Also note that USB_MUSB_SUNXI gets selected automatically as soon as you select either USB_MUSB_HOST or USB_MUSB_GADGET...

Quoted 4 lines

I enabled it as a gadget through
menuconfig. What is the policy on using gadget vs host? I guess it would make more sense to enable all the OTG connectors to gadget, but maybe that's just me.

The policy I'm thinking of (and which we are currently sorta following wrt enabling USB_MUSB_HOST) is that on devices with no normal usb ports we use USB_MUSB_HOST, so that people can interact with u-boot without needing a serial console (which often requires soldering).

On boards which do have a normal usb port I fully agree that USB_MUSB_GADGET is a good default.

In practice this will likely boil down to use USB_MUSB_HOST on tablets and USB_MUSB_GADGET everywhere else.

Regards,

Hans

Maxime Ripard

author

2015-09-13 17:13 UTC #61 lore raw

PATCH 12/13 sunxi: A13-Olinuxino: Enable the USB OTG controller

Quoted 71 lines · Hans de Goede

Hi,
Quoted 42 lines · Maxime Ripard
Hi Hans,
Quoted 30 lines · Hans de Goede
Hi,
Quoted 27 lines · Maxime Ripard
The A13-Olinuxino has a mini-USB connector that can be used to power up the board and as an OTG connector.
Since we have already some USB host-only ports right beside this one, enable it in gadget mode
Signed-off-by Maxime Ripard <[email protected]>
---
 configs/A13-OLinuXino_defconfig | 2 ++
 1 file changed, 2 insertions(+)
configs/A13-OLinuXino_defconfig +1 -0
index 4b4337223ca5..70aa194b91c4 100644
@@ -3,6 +3,7 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN5I=y
 CONFIG_DRAM_CLK=408
 CONFIG_DRAM_EMR1=0
+CONFIG_USB0_VBUS_DET="PG1"
 CONFIG_USB1_VBUS_PIN="PG11"
 CONFIG_AXP_GPIO=y
 # CONFIG_VIDEO_HDMI is not set
@@ -11,6 +12,7 @@ CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y
 CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0"
 CONFIG_VIDEO_LCD_POWER="AXP0-0"
 CONFIG_VIDEO_LCD_BL_PWM="PB2"
Quoted 8 lines
configs/A13-OLinuXino_defconfig CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y · line 18
Quoted 4 lines
configs/A13-OLinuXino_defconfig +1 -0
+CONFIG_USB_MUSB_SUNXI=y
 CONFIG_DEFAULT_DEVICE_TREE="sun5i-a13-olinuxino"
 # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
 CONFIG_SPL=y
The CONFIG_xxx defines for using MUSB in either host or gadget mode have changed in v2015.10, looks like you need to rebase this series and fix this.
Quoted 1 line
This was based on 2015.10-rc2.
Are you sure?
drivers/usb/musb-new/Kconfig has:
config USB_MUSB_HOST
bool "MUSB host mode support"
help
Enables the MUSB USB dual-role controller in host mode.
config USB_MUSB_GADGET
bool "MUSB gadget mode support"
help
Enables the MUSB USB dual-role controller in gadget mode.
if USB_MUSB_HOST || USB_MUSB_GADGET
config USB_MUSB_SUNXI
bool "Enable sunxi OTG / DRC USB controller"
depends on ARCH_SUNXI
default y
---help---
Say y here to enable support for the sunxi OTG / DRC USB controller used on almost all sunxi boards.

Quoted 6 lines

endif
And you are not setting USB_MUSB_HOST nor USB_MUSB_GADGET so you should never get a chance to set USB_MUSB_SUNXI. Also note that USB_MUSB_SUNXI gets selected automatically as soon as you select either USB_MUSB_HOST or USB_MUSB_GADGET...

Hmmm, there's something fishy then. I maybe used menuconfig and forgot to fix the defconfig or something. I don't see any other explanation. Anyway, I'll update and fix it in v2, obviously :)

Quoted 9 lines

Quoted 3 lines
I enabled it as a gadget through menuconfig. What is the policy on using gadget vs host? I guess it would make more sense to enable all the OTG connectors to gadget, but maybe that's just me.
The policy I'm thinking of (and which we are currently sorta following wrt enabling USB_MUSB_HOST) is that on devices with no normal usb ports we use USB_MUSB_HOST, so that people can interact with u-boot without needing a serial console (which often requires soldering).

Quoted 5 lines

On boards which do have a normal usb port I fully agree that USB_MUSB_GADGET is a good default.
In practice this will likely boil down to use USB_MUSB_HOST on tablets and USB_MUSB_GADGET everywhere else.

Sounds good!

If there's a UART gadget, we could also always select USB_MUSB_GADGET, and export a UART there for the tablets, but I haven't seen such a gadget in the code, so I guess your idea makes more sense :)

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150913/d622c906/attachment.sig>

Hans de Goede

2015-09-13 17:38 UTC #62 lore raw

PATCH 12/13 sunxi: A13-Olinuxino: Enable the USB OTG controller

Hi,

Quoted 95 lines · Maxime Ripard

Quoted 71 lines · Hans de Goede
Hi,
Quoted 42 lines · Maxime Ripard
Hi Hans,
Quoted 30 lines · Hans de Goede
Hi,
Quoted 27 lines · Maxime Ripard
The A13-Olinuxino has a mini-USB connector that can be used to power up the board and as an OTG connector.
Since we have already some USB host-only ports right beside this one, enable it in gadget mode
Signed-off-by Maxime Ripard <[email protected]>
---
  configs/A13-OLinuXino_defconfig | 2 ++
  1 file changed, 2 insertions(+)
configs/A13-OLinuXino_defconfig +1 -0
index 4b4337223ca5..70aa194b91c4 100644
@@ -3,6 +3,7 @@ CONFIG_ARCH_SUNXI=y
  CONFIG_MACH_SUN5I=y
  CONFIG_DRAM_CLK=408
  CONFIG_DRAM_EMR1=0
+CONFIG_USB0_VBUS_DET="PG1"
  CONFIG_USB1_VBUS_PIN="PG11"
  CONFIG_AXP_GPIO=y
  # CONFIG_VIDEO_HDMI is not set
@@ -11,6 +12,7 @@ CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y
  CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0"
  CONFIG_VIDEO_LCD_POWER="AXP0-0"
  CONFIG_VIDEO_LCD_BL_PWM="PB2"
Quoted 8 lines
configs/A13-OLinuXino_defconfig CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y · line 18
Quoted 4 lines
configs/A13-OLinuXino_defconfig +1 -0
+CONFIG_USB_MUSB_SUNXI=y
  CONFIG_DEFAULT_DEVICE_TREE="sun5i-a13-olinuxino"
  # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
  CONFIG_SPL=y
The CONFIG_xxx defines for using MUSB in either host or gadget mode have changed in v2015.10, looks like you need to rebase this series and fix this.
Quoted 1 line
This was based on 2015.10-rc2.
Are you sure?
drivers/usb/musb-new/Kconfig has:
config USB_MUSB_HOST
bool "MUSB host mode support"
help
Enables the MUSB USB dual-role controller in host mode.
config USB_MUSB_GADGET
bool "MUSB gadget mode support"
help
Enables the MUSB USB dual-role controller in gadget mode.
if USB_MUSB_HOST || USB_MUSB_GADGET
config USB_MUSB_SUNXI
bool "Enable sunxi OTG / DRC USB controller"
depends on ARCH_SUNXI
default y
---help---
Say y here to enable support for the sunxi OTG / DRC USB controller used on almost all sunxi boards.
Quoted 6 lines
endif
And you are not setting USB_MUSB_HOST nor USB_MUSB_GADGET so you should never get a chance to set USB_MUSB_SUNXI. Also note that USB_MUSB_SUNXI gets selected automatically as soon as you select either USB_MUSB_HOST or USB_MUSB_GADGET...
Hmmm, there's something fishy then. I maybe used menuconfig and forgot to fix the defconfig or something. I don't see any other explanation. Anyway, I'll update and fix it in v2, obviously :)
Quoted 12 lines
Quoted 3 lines
I enabled it as a gadget through menuconfig. What is the policy on using gadget vs host? I guess it would make more sense to enable all the OTG connectors to gadget, but maybe that's just me.
The policy I'm thinking of (and which we are currently sorta following wrt enabling USB_MUSB_HOST) is that on devices with no normal usb ports we use USB_MUSB_HOST, so that people can interact with u-boot without needing a serial console (which often requires soldering).
On boards which do have a normal usb port I fully agree that USB_MUSB_GADGET is a good default.

Quoted 8 lines

Quoted 2 lines
In practice this will likely boil down to use USB_MUSB_HOST on tablets and USB_MUSB_GADGET everywhere else.
Sounds good!
If there's a UART gadget, we could also always select USB_MUSB_GADGET, and export a UART there for the tablets, but I haven't seen such a gadget in the code, so I guess your idea makes more sense :)

Ack. AFAIK u-boot currently lacks a serial gadget, once it gets one things get somewhat more complicated, for debugging a serial gadget is fine. But for now (no usable tablet ui) I sorta expect people to want to have hooked up a usb-keyb to a tablet (which is not running android) anyways, at which point the host option makes more sense.

Ideally we would build in both, and decide which one to use based on the id-pin. The sunxi musb-host code already checks the id-pin and does not touch the controller if it is not pulled down (iow if no host cable is inserted).

Regards,

Hans

Quoted 3 lines

Maxime

Maxime Ripard

author

2015-09-14 21:19 UTC #63 lore raw

PATCH 12/13 sunxi: A13-Olinuxino: Enable the USB OTG controller

Quoted 23 lines · Hans de Goede

Quoted 8 lines
Quoted 8 lines
The policy I'm thinking of (and which we are currently sorta following wrt enabling USB_MUSB_HOST) is that on devices with no normal usb ports we use USB_MUSB_HOST, so that people can interact with u-boot without needing a serial console (which often requires soldering).
On boards which do have a normal usb port I fully agree that USB_MUSB_GADGET is a good default.
Quoted 8 lines
Quoted 2 lines
In practice this will likely boil down to use USB_MUSB_HOST on tablets and USB_MUSB_GADGET everywhere else.
Sounds good!
If there's a UART gadget, we could also always select USB_MUSB_GADGET, and export a UART there for the tablets, but I haven't seen such a gadget in the code, so I guess your idea makes more sense :)
Ack. AFAIK u-boot currently lacks a serial gadget, once it gets one things get somewhat more complicated, for debugging a serial gadget is fine. But for now (no usable tablet ui) I sorta expect people to want to have hooked up a usb-keyb to a tablet (which is not running android) anyways, at which point the host option makes more sense.

Quoted 4 lines

Ideally we would build in both, and decide which one to use based on the id-pin. The sunxi musb-host code already checks the id-pin and does not touch the controller if it is not pulled down (iow if no host cable is inserted).

Looks like a good plan. I'll update my patch and resend it.

Thanks!
Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150914/b99091b2/attachment.sig>

Maxime Ripard

author

2015-08-31 14:46 UTC #64 lore raw

PATCH 13/13 sunxi: cubietruck: Enable the USB OTG controller

In reply to Maxime Ripard

The Cubietruck has a mini-USB connector that can be used to power up the board and as an OTG connector.

Since we have already some USB host-only ports right beside this one, enable it in gadget mode

Signed-off-by Maxime Ripard <[email protected]>

---
 configs/Cubietruck_defconfig | 5 +++++
 1 file changed, 5 insertions(+)

configs/Cubietruck_defconfig +5 -0

index b8809c806b3f..59e8cb6ea339 100644
@@ -13,3 +13,8 @@ CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPH(1
 # CONFIG_CMD_FPGA is not set
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_USB_EHCI_HCD=y
+CONFIG_USB0_ID_DET="PH19"
+CONFIG_USB0_VBUS_DET="PH22"
+CONFIG_USB0_VBUS_PIN="PH17"
+CONFIG_USB_MUSB_SUNXI=y
+CONFIG_USB_MUSB_GADGET=y

Signature · 1 line

2.5.0