Skip to contentSkip to conversation

usb: gadget: fastboot miscellaneous patches

PATCH New Eric Nelson 4 participants 25 messages Sep 30, 2014 – Oct 6, 2014 USB

lore
Share & tools
lore
#0 lore raw

cover usb: gadget: fastboot miscellaneous patches

While trying to configure Nitrogen6X boards to use Android Fastboot, I found a number of places where the implementation doesn't appear to match the latest host tools on AOSP.

Eric Nelson (3):
usb: gadget: fastboot: add max-download-size variable
usb: gadget: fastboot: explicitly set radix of maximum download size
usb: gadget: fastboot: terminate commands with NULL

 drivers/usb/gadget/f_fastboot.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)
Signature · 1 line
1.9.1
#1 lore raw

PATCH 1/3 usb: gadget: fastboot: add max-download-size variable

Current Android Fastboot seems to use 'max-download-size' instead of 'downloadsize' variable to indicate the maximum size of sparse segments.

See function get_target_sparse_limit() in file fastboot/fastboot.c in the AOSP:
https://android.googlesource.com/platform/system/core/+/master

---
 drivers/usb/gadget/f_fastboot.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/usb/gadget/f_fastboot.c +2 -1
index 38c0965..f970f89 100644
@@ -351,7 +351,8 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request *req)
 		strncat(response, FASTBOOT_VERSION, chars_left);
 	} else if (!strcmp_l1("bootloader-version", cmd)) {
 		strncat(response, U_BOOT_VERSION, chars_left);
-	} else if (!strcmp_l1("downloadsize", cmd)) {
+	} else if (!strcmp_l1("downloadsize", cmd) ||
+		!strcmp_l1("max-download-size", cmd)) {
 		char str_num[12];
 
 		sprintf(str_num, "%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);
Signature · 1 line
1.9.1
#2 lore raw

PATCH 1/3 usb: gadget: fastboot: add max-download-size variable

Quoted 19 lines · Eric Nelson

Current Android Fastboot seems to use 'max-download-size' instead of 'downloadsize' variable to indicate the maximum size of sparse segments.

See function get_target_sparse_limit() in file fastboot/fastboot.c in the AOSP:
https://android.googlesource.com/platform/system/core/+/master

---
  drivers/usb/gadget/f_fastboot.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
drivers/usb/gadget/f_fastboot.c +0 -0
index 38c0965..f970f89 100644

drivers/usb/gadget/f_fastboot.c static void cb_getvar(struct usb_ep *ep, struct usb_request *req) · line 358

Quoted 9 lines
drivers/usb/gadget/f_fastboot.c +2 -1
@@ -351,7 +351,8 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request *req)
  		strncat(response, FASTBOOT_VERSION, chars_left);
  	} else if (!strcmp_l1("bootloader-version", cmd)) {
  		strncat(response, U_BOOT_VERSION, chars_left);
-	} else if (!strcmp_l1("downloadsize", cmd)) {
+	} else if (!strcmp_l1("downloadsize", cmd) ||
+		!strcmp_l1("max-download-size", cmd)) {
  		char str_num[12];
 
  		sprintf(str_num, "%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);

(the host version of fastboot that I'm using requires this change!)

#3 lore raw

PATCH 1/3 usb: gadget: fastboot: add max-download-size variable

Quoted 33 lines · Steve Rae
Quoted 32 lines · Eric Nelson

Current Android Fastboot seems to use 'max-download-size' instead of 'downloadsize' variable to indicate the maximum size of sparse segments.

See function get_target_sparse_limit() in file fastboot/fastboot.c

in the AOSP:
https://android.googlesource.com/platform/system/core/+/master

---

  drivers/usb/gadget/f_fastboot.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
(quoted diff) +0 -0

b/drivers/usb/gadget/f_fastboot.c index 38c0965..f970f89 100644

drivers/usb/gadget/f_fastboot.c +2 -1
@@ -351,7 +351,8 @@ static void cb_getvar(struct usb_ep *ep, struct
 usb_request *req)
 
  		strncat(response, FASTBOOT_VERSION, chars_left);
 
  	} else if (!strcmp_l1("bootloader-version", cmd)) {
 
  		strncat(response, U_BOOT_VERSION, chars_left);
 
-	} else if (!strcmp_l1("downloadsize", cmd)) {
+	} else if (!strcmp_l1("downloadsize", cmd) ||
+		!strcmp_l1("max-download-size", cmd)) {
Quoted 6 lines
Quoted 3 lines
  		char str_num[12];
  		
  		sprintf(str_num, "%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);

(the host version of fastboot that I'm using requires this change!)

Wow, so the previous code that was accepted was broken ? Did you know about that breakage ?

Best regards,
Marek Vasut

#4 lore raw

PATCH 1/3 usb: gadget: fastboot: add max-download-size variable

Quoted 36 lines · Marek Vasut
Quoted 35 lines · Steve Rae
Quoted 34 lines · Eric Nelson

Current Android Fastboot seems to use 'max-download-size' instead of 'downloadsize' variable to indicate the maximum size of sparse segments.

See function get_target_sparse_limit() in file fastboot/fastboot.c

in the AOSP:
https://android.googlesource.com/platform/system/core/+/master

---

   drivers/usb/gadget/f_fastboot.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
(quoted diff) +0 -0

b/drivers/usb/gadget/f_fastboot.c index 38c0965..f970f89 100644

drivers/usb/gadget/f_fastboot.c +2 -1
@@ -351,7 +351,8 @@ static void cb_getvar(struct usb_ep *ep, struct
 usb_request *req)
 
   		strncat(response, FASTBOOT_VERSION, chars_left);
 
   	} else if (!strcmp_l1("bootloader-version", cmd)) {
 
   		strncat(response, U_BOOT_VERSION, chars_left);
 
-	} else if (!strcmp_l1("downloadsize", cmd)) {
+	} else if (!strcmp_l1("downloadsize", cmd) ||
+		!strcmp_l1("max-download-size", cmd)) {
 
   		char str_num[12];
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
   		sprintf(str_num, "%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);

(the host version of fastboot that I'm using requires this change!)

Wow, so the previous code that was accepted was broken ? Did you know about that breakage ?

It wasn't broken; let me try to clarify....
It seems that different host versions of "fastboot" use either "downloadsize" or "max-download-size" (I am not certain about the history...) The original code has "downloadsize", and with the host version of fastboot that I am testing with (which uses "max-download-size"), this reports as "unknown variable" - however, the download still occurs successfully (there must be some default size that it is using...) Therefore, it isn't broken (for me). However, Eric has reported that for his host version of fastboot, that it stops! So his changes (1/3 and 2/3) are required for his host version of fastboot (and they work properly with my version)
Hope that clarifies it,
Thanks, Steve
PS. none of these host versions of fastboot have any version identification -- so it is really difficult to determine what "host version" we are actually talking about....

Quoted 4 lines

Best regards,
Marek Vasut

#5 lore raw

PATCH 2/3 usb: gadget: fastboot: explicitly set radix of maximum download size

In reply to Eric Nelson

The processing of the max-download-size variable requires a radix specifier, or the fastboot host tool will interpret it as an octal number.

See function get_target_sparse_limit() in file fastboot/fastboot.c in the AOSP:
https://android.googlesource.com/platform/system/core/+/master

---
 drivers/usb/gadget/f_fastboot.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/f_fastboot.c +1 -1
index f970f89..86700f5 100644
@@ -355,7 +355,7 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request *req)
 		!strcmp_l1("max-download-size", cmd)) {
 		char str_num[12];
 
-		sprintf(str_num, "%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);
+		sprintf(str_num, "0x%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);
 		strncat(response, str_num, chars_left);
 	} else if (!strcmp_l1("serialno", cmd)) {
 		s = getenv("serial#");
Signature · 1 line
1.9.1
#6 lore raw

PATCH 2/3 usb: gadget: fastboot: explicitly set radix of maximum download size

Quoted 19 lines · Eric Nelson

The processing of the max-download-size variable requires a radix specifier, or the fastboot host tool will interpret it as an octal number.

See function get_target_sparse_limit() in file fastboot/fastboot.c in the AOSP:
https://android.googlesource.com/platform/system/core/+/master

---
  drivers/usb/gadget/f_fastboot.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/f_fastboot.c +0 -0
index f970f89..86700f5 100644

drivers/usb/gadget/f_fastboot.c static void cb_getvar(struct usb_ep *ep, struct usb_request *req) · line 361

Quoted 8 lines
drivers/usb/gadget/f_fastboot.c +1 -1
@@ -355,7 +355,7 @@ static void cb_getvar(struct usb_ep *ep, struct usb_request *req)
  		!strcmp_l1("max-download-size", cmd)) {
  		char str_num[12];
 
-		sprintf(str_num, "%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);
+		sprintf(str_num, "0x%08x", CONFIG_USB_FASTBOOT_BUF_SIZE);
  		strncat(response, str_num, chars_left);
  	} else if (!strcmp_l1("serialno", cmd)) {
  		s = getenv("serial#");

(the host version of fastboot that I'm using requires this change!)

#7 lore raw

PATCH 3/3 usb: gadget: fastboot: terminate commands with NULL

In reply to Eric Nelson

Without NULL termination, various commands will read past the end of input. In particular, this was noticed with error() calls in cb_getvar and simple_strtoul() in cb_download.

Since the download callback happens elsewhere, the 4k buffer should always be sufficient to handle command arguments.

---
 drivers/usb/gadget/f_fastboot.c | 7 +++++++
 1 file changed, 7 insertions(+)
drivers/usb/gadget/f_fastboot.c +7 -0
index 86700f5..0950ea8 100644
@@ -542,6 +542,13 @@ static void rx_handler_command(struct usb_ep *ep, struct usb_request *req)
 		error("unknown command: %s\n", cmdbuf);
 		fastboot_tx_write_str("FAILunknown command");
 	} else {
+		if (req->actual < req->length) {
+			u8 *buf = (u8 *)req->buf;
+			buf[req->actual] = 0;
+			func_cb(ep, req);
+		} else {
+			error("buffer overflow\n");
+		}
 		func_cb(ep, req);
 	}
 
Signature · 1 line
1.9.1
#8 lore raw

PATCH 3/3 usb: gadget: fastboot: terminate commands with NULL

Quoted 17 lines · Eric Nelson

Without NULL termination, various commands will read past the end of input. In particular, this was noticed with error() calls in cb_getvar and simple_strtoul() in cb_download.

Since the download callback happens elsewhere, the 4k buffer should always be sufficient to handle command arguments.

---
  drivers/usb/gadget/f_fastboot.c | 7 +++++++
  1 file changed, 7 insertions(+)
drivers/usb/gadget/f_fastboot.c +0 -0
index 86700f5..0950ea8 100644

drivers/usb/gadget/f_fastboot.c static void rx_handler_command(struct usb_ep *ep, struct usb_request *req) · line 550

Quoted 9 lines
drivers/usb/gadget/f_fastboot.c +6 -0
@@ -542,6 +542,13 @@ static void rx_handler_command(struct usb_ep *ep, struct usb_request *req)
  		error("unknown command: %s\n", cmdbuf);
  		fastboot_tx_write_str("FAILunknown command");
  	} else {
+		if (req->actual < req->length) {
+			u8 *buf = (u8 *)req->buf;
+			buf[req->actual] = 0;
+			func_cb(ep, req);
+		} else {
+			error("buffer overflow\n");
                         fastboot_tx_write_str("FAILbuffer overflow");

ADD this line

drivers/usb/gadget/f_fastboot.c static void rx_handler_command(struct usb_ep *ep, struct usb_request *req) · line 552

Quoted 2 lines
drivers/usb/gadget/f_fastboot.c +1 -0
+		}
  		func_cb(ep, req);

AND delete this line (otherwise the func_cb() is called twice!!!)

drivers/usb/gadget/f_fastboot.c static void rx_handler_command(struct usb_ep *ep, struct usb_request *req) · line 554

Quoted 3 lines
drivers/usb/gadget/f_fastboot.c +0 -0
  	}
 

I have not experienced this issue, however, if it is to be accepted, then please update these two lines.... Afterwards:

#9 lore raw

PATCH 3/3 usb: gadget: fastboot: terminate commands with NULL

Thanks Steve,

Quoted 32 lines · Steve Rae
Quoted 18 lines · Eric Nelson

Without NULL termination, various commands will read past the end of input. In particular, this was noticed with error() calls in cb_getvar and simple_strtoul() in cb_download.

Since the download callback happens elsewhere, the 4k buffer should always be sufficient to handle command arguments.

---
  drivers/usb/gadget/f_fastboot.c | 7 +++++++
  1 file changed, 7 insertions(+)
drivers/usb/gadget/f_fastboot.c +0 -0
index 86700f5..0950ea8 100644

drivers/usb/gadget/f_fastboot.c static void rx_handler_command(struct usb_ep *ep, · line 551

Quoted 10 lines
drivers/usb/gadget/f_fastboot.c +6 -0
@@ -542,6 +542,13 @@ static void rx_handler_command(struct usb_ep *ep,
 struct usb_request *req)
          error("unknown command: %s\n", cmdbuf);
          fastboot_tx_write_str("FAILunknown command");
      } else {
+        if (req->actual < req->length) {
+            u8 *buf = (u8 *)req->buf;
+            buf[req->actual] = 0;
+            func_cb(ep, req);
+        } else {
+            error("buffer overflow\n");
                        fastboot_tx_write_str("FAILbuffer overflow");
Quoted 6 lines

ADD this line

drivers/usb/gadget/f_fastboot.c static void rx_handler_command(struct usb_ep *ep, struct usb_request *req) · line 552

Quoted 2 lines
drivers/usb/gadget/f_fastboot.c +1 -0
+        }
          func_cb(ep, req);

AND delete this line (otherwise the func_cb() is called twice!!!)

Quoted 2 lines
drivers/usb/gadget/f_fastboot.c +0 -0
      }

Ouch. It appears I pooched the patch when trying to make checkpatch happy with the extra(neous) braces.

I'll forward V2 shortly.

Regards,

Eric

#10 lore raw

PATCH v2 3/3 usb: gadget: fastboot: terminate commands with NULL

In reply to Steve Rae

Without NULL termination, various commands will read past the end of input. In particular, this was noticed with error() calls in cb_getvar and simple_strtoul() in cb_download.

Since the download callback happens elsewhere, the 4k buffer should always be sufficient to handle command arguments.

---
V2 adds response to host in the event of failure and removes
double call-back via func_cb as pointed out by Steve Rae.

 drivers/usb/gadget/f_fastboot.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/usb/gadget/f_fastboot.c +8 -1
index 86700f5..0c91d3c 100644
@@ -542,7 +542,14 @@ static void rx_handler_command(struct usb_ep *ep, struct usb_request *req)
 		error("unknown command: %s\n", cmdbuf);
 		fastboot_tx_write_str("FAILunknown command");
 	} else {
-		func_cb(ep, req);
+		if (req->actual < req->length) {
+			u8 *buf = (u8 *)req->buf;
+			buf[req->actual] = 0;
+			func_cb(ep, req);
+		} else {
+			error("buffer overflow\n");
+			fastboot_tx_write_str("FAILbuffer overflow"); 
+		}
 	}
 
 	if (req->status == 0) {
Signature · 1 line
1.9.1
#11 lore raw

cover usb: gadget: fastboot miscellaneous patches

In reply to Eric Nelson
Quoted 8 lines · Eric Nelson

While trying to configure Nitrogen6X boards to use Android Fastboot, I found a number of places where the implementation doesn't appear to match the latest host tools on AOSP.

Eric Nelson (3):
usb: gadget: fastboot: add max-download-size variable
usb: gadget: fastboot: explicitly set radix of maximum download size
usb: gadget: fastboot: terminate commands with NULL

Just to make sure, are those fixes for 2014.10 or new stuff for next ?

Best regards,
Marek Vasut

#12 lore raw

cover usb: gadget: fastboot miscellaneous patches

Hi Marek,

Quoted 5 lines · Marek Vasut
Quoted 4 lines · Eric Nelson

While trying to configure Nitrogen6X boards to use Android Fastboot, I found a number of places where the implementation doesn't appear to match the latest host tools on AOSP.

Quoted 7 lines
Quoted 4 lines

Eric Nelson (3):
usb: gadget: fastboot: add max-download-size variable
usb: gadget: fastboot: explicitly set radix of maximum download size
usb: gadget: fastboot: terminate commands with NULL

Just to make sure, are those fixes for 2014.10 or new stuff for next ?

These patches are against master, but should apply against usb/next and dfu/next and "next" is fine for us.

I just thought I'd forward patches for what I've seen so far as I'm trying to understand how the parts fit together.

The current dependencies on PART_EFI and a fixed MMC device don't fit our needs very well, since we have our boot loader in SPI-NOR and support a variety of MMC, eMMC, and SATA drives for booting Android and structure in fb_mmc.c and aboot.c seems to require some compile-time decisions.

Regards,

Eric

#13 lore raw

cover usb: gadget: fastboot miscellaneous patches

Quoted 13 lines · Eric Nelson

Hi Marek,

Quoted 10 lines · Marek Vasut
Quoted 8 lines · Eric Nelson

While trying to configure Nitrogen6X boards to use Android Fastboot, I found a number of places where the implementation doesn't appear to match the latest host tools on AOSP.

Eric Nelson (3):
usb: gadget: fastboot: add max-download-size variable
usb: gadget: fastboot: explicitly set radix of maximum download size
usb: gadget: fastboot: terminate commands with NULL

Quoted 4 lines
Quoted 1 line

Just to make sure, are those fixes for 2014.10 or new stuff for next ?

These patches are against master, but should apply against usb/next and dfu/next and "next" is fine for us.

3/3 looks like a bugfix though. Is that a bugfix ?

Best regards,
Marek Vasut

#14 lore raw

cover usb: gadget: fastboot miscellaneous patches

Hi Marek,

Quoted 14 lines · Marek Vasut
Quoted 13 lines · Eric Nelson

Hi Marek,

Quoted 10 lines · Marek Vasut
Quoted 8 lines · Eric Nelson

While trying to configure Nitrogen6X boards to use Android Fastboot, I found a number of places where the implementation doesn't appear to match the latest host tools on AOSP.

Eric Nelson (3):
usb: gadget: fastboot: add max-download-size variable
usb: gadget: fastboot: explicitly set radix of maximum download size
usb: gadget: fastboot: terminate commands with NULL

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

Just to make sure, are those fixes for 2014.10 or new stuff for next ?

These patches are against master, but should apply against usb/next and dfu/next and "next" is fine for us.

3/3 looks like a bugfix though. Is that a bugfix ?

I wasn't able to get fastboot to do much of anything without all three.

-- lack of max-download-size simply stopped downloads
-- the missing radix caused my host to think that the 0x07000000 size (copied from Beagle) was 1.8 MiB instead of 100+ MiB. -- the lack of termination showed up as a request to download a **huge** image when I tried to send u-boot.imx. I think I got lucky that the next characters in the buffer looked like hex digits.

I suspect that others are either holding on to some local patches or are perhaps using old versions of the Fastboot host program.

After applying all three, I was able to configure for flashing on an MMC device, but I don't have anything configured to use EFI partitions, so there's no immediate route to usage for us.

I'd really like to be able to "fastboot flash bootloader u-boot.imx" and program SPI-NOR and also be able to boot a kernel and RAM disk using "fastboot boot uImage uramdisk.img", but neither of them seems very close. The first needs some more structure, and the latter seemed to decide its' own address for the kernel and simply ignore the RAM disk.

I have the sense that this code is pretty much a work in progress, but I'd like to hear otherwise from those who have used it.

Regards,

Eric

#15 lore raw

cover usb: gadget: fastboot miscellaneous patches

Quoted 47 lines · Eric Nelson

Hi Marek,

Quoted 14 lines · Marek Vasut
Quoted 13 lines · Eric Nelson

Hi Marek,

Quoted 10 lines · Marek Vasut
Quoted 8 lines · Eric Nelson

While trying to configure Nitrogen6X boards to use Android Fastboot, I found a number of places where the implementation doesn't appear to match the latest host tools on AOSP.

Eric Nelson (3):
usb: gadget: fastboot: add max-download-size variable
usb: gadget: fastboot: explicitly set radix of maximum download size
usb: gadget: fastboot: terminate commands with NULL

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

Just to make sure, are those fixes for 2014.10 or new stuff for next ?

These patches are against master, but should apply against usb/next and dfu/next and "next" is fine for us.

3/3 looks like a bugfix though. Is that a bugfix ?

I wasn't able to get fastboot to do much of anything without all three.

-- lack of max-download-size simply stopped downloads
-- the missing radix caused my host to think that the 0x07000000 size (copied from Beagle) was 1.8 MiB instead of 100+ MiB. -- the lack of termination showed up as a request to download a **huge** image when I tried to send u-boot.imx. I think I got lucky that the next characters in the buffer looked like hex digits.

I suspect that others are either holding on to some local patches or are perhaps using old versions of the Fastboot host program.

After applying all three, I was able to configure for flashing on an MMC device, but I don't have anything configured to use EFI partitions, so there's no immediate route to usage for us.

I'd really like to be able to "fastboot flash bootloader u-boot.imx" and program SPI-NOR and also be able to boot a kernel and RAM disk using "fastboot boot uImage uramdisk.img", but neither of them seems very close. The first needs some more structure, and the latter seemed to decide its' own address for the kernel and simply ignore the RAM disk.

Quoted 2 lines

I have the sense that this code is pretty much a work in progress, but I'd like to hear otherwise from those who have used it.

OK, so let's wait for the others' opinions.

Best regards,
Marek Vasut

#16 lore raw

cover usb: gadget: fastboot miscellaneous patches

Quoted 48 lines · Marek Vasut
Quoted 47 lines · Eric Nelson

Hi Marek,

Quoted 14 lines · Marek Vasut
Quoted 13 lines · Eric Nelson

Hi Marek,

Quoted 10 lines · Marek Vasut
Quoted 8 lines · Eric Nelson

While trying to configure Nitrogen6X boards to use Android Fastboot, I found a number of places where the implementation doesn't appear to match the latest host tools on AOSP.

Eric Nelson (3):
usb: gadget: fastboot: add max-download-size variable
usb: gadget: fastboot: explicitly set radix of maximum download size
usb: gadget: fastboot: terminate commands with NULL

Quoted 6 lines
Quoted 4 lines
Quoted 1 line

Just to make sure, are those fixes for 2014.10 or new stuff for next ?

These patches are against master, but should apply against usb/next and dfu/next and "next" is fine for us.

3/3 looks like a bugfix though. Is that a bugfix ?

I wasn't able to get fastboot to do much of anything without all three.

-- lack of max-download-size simply stopped downloads
-- the missing radix caused my host to think that the 0x07000000 size (copied from Beagle) was 1.8 MiB instead of 100+ MiB. -- the lack of termination showed up as a request to download a **huge** image when I tried to send u-boot.imx. I think I got lucky that the next characters in the buffer looked like hex digits.

I suspect that others are either holding on to some local patches or are perhaps using old versions of the Fastboot host program.

After applying all three, I was able to configure for flashing on an MMC device, but I don't have anything configured to use EFI partitions, so there's no immediate route to usage for us.

I'd really like to be able to "fastboot flash bootloader u-boot.imx" and program SPI-NOR and also be able to boot a kernel and RAM disk using "fastboot boot uImage uramdisk.img", but neither of them seems very close. The first needs some more structure, and the latter seemed to decide its' own address for the kernel and simply ignore the RAM disk.

Quoted 8 lines
Quoted 2 lines

I have the sense that this code is pretty much a work in progress, but I'd like to hear otherwise from those who have used it.

OK, so let's wait for the others' opinions.

Best regards,
Marek Vasut

I would recommend 1/3 & 2/3 for 2014.10 (I'm not certain about 3/3 because I don't think that it can actually occur on my boards....) Thanks, Steve

#17 lore raw

cover usb: gadget: fastboot miscellaneous patches

Quoted 53 lines · Steve Rae
Quoted 52 lines · Marek Vasut
Quoted 50 lines · Eric Nelson

Hi Marek,

Quoted 14 lines · Marek Vasut
Quoted 13 lines · Eric Nelson

Hi Marek,

Quoted 10 lines · Marek Vasut
Quoted 8 lines · Eric Nelson

While trying to configure Nitrogen6X boards to use Android Fastboot, I found a number of places where the implementation doesn't appear to match the latest host tools on AOSP.

Eric Nelson (3):
usb: gadget: fastboot: add max-download-size variable
usb: gadget: fastboot: explicitly set radix of maximum download size usb: gadget: fastboot: terminate commands with NULL

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

Just to make sure, are those fixes for 2014.10 or new stuff for next ?

These patches are against master, but should apply against usb/next and dfu/next and "next" is fine for us.

3/3 looks like a bugfix though. Is that a bugfix ?

I wasn't able to get fastboot to do much of anything without all three.

-- lack of max-download-size simply stopped downloads
-- the missing radix caused my host to think that the 0x07000000 size (copied from Beagle) was 1.8 MiB instead of 100+ MiB. -- the lack of termination showed up as a request to download a **huge** image when I tried to send u-boot.imx. I think I got lucky that the next characters in the buffer looked like hex digits.

I suspect that others are either holding on to some local patches or are perhaps using old versions of the Fastboot host program.

After applying all three, I was able to configure for flashing on an MMC device, but I don't have anything configured to use EFI partitions, so there's no immediate route to usage for us.

I'd really like to be able to "fastboot flash bootloader u-boot.imx" and program SPI-NOR and also be able to boot a kernel and RAM disk using "fastboot boot uImage uramdisk.img", but neither of them seems very close. The first needs some more structure, and the latter seemed to decide its' own address for the kernel and simply ignore the RAM disk.

I have the sense that this code is pretty much a work in progress, but I'd like to hear otherwise from those who have used it.

Quoted 8 lines
Quoted 4 lines

OK, so let's wait for the others' opinions.

Best regards,
Marek Vasut

I would recommend 1/3 & 2/3 for 2014.10 (I'm not certain about 3/3 because I don't think that it can actually occur on my boards....) Thanks, Steve

OK, Lukasz, do you want to send me a PR with those two ?

Best regards,
Marek Vasut

#18 lore raw

cover usb: gadget: fastboot miscellaneous patches

Hi Marek,

Quoted 63 lines · Steve Rae
Quoted 62 lines · Marek Vasut
Quoted 61 lines · Eric Nelson
Quoted 54 lines

Hi Marek,

Quoted 18 lines · Marek Vasut
Quoted 16 lines · Eric Nelson

Hi Marek,

Quoted 13 lines · Marek Vasut
Quoted 10 lines · Eric Nelson

While trying to configure Nitrogen6X boards to use Android Fastboot, I found a number of places where the implementation doesn't appear to match the latest host tools on AOSP.

Eric Nelson (3):
usb: gadget: fastboot: add max-download-size variable
usb: gadget: fastboot: explicitly set radix of maximum
download size usb: gadget: fastboot: terminate commands with NULL

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

Just to make sure, are those fixes for 2014.10 or new stuff for next ?

These patches are against master, but should apply against usb/next and dfu/next and "next" is fine for us.

3/3 looks like a bugfix though. Is that a bugfix ?

I wasn't able to get fastboot to do much of anything without all three.

-- lack of max-download-size simply stopped downloads -- the missing radix caused my host to think that the 0x07000000 size (copied from Beagle) was 1.8 MiB instead of 100+ MiB. -- the lack of termination showed up as a request to download a **huge** image when I tried to send u-boot.imx. I think I got lucky that the next characters in the buffer looked like hex digits.

I suspect that others are either holding on to some local patches or are perhaps using old versions of the Fastboot host program.

After applying all three, I was able to configure for flashing on an MMC device, but I don't have anything configured to use EFI partitions, so there's no immediate route to usage for us.

I'd really like to be able to "fastboot flash bootloader u-boot.imx" and program SPI-NOR and also be able to boot a kernel and RAM disk using "fastboot boot uImage uramdisk.img", but neither of them seems very close. The first needs some more structure, and the latter seemed to decide its' own address for the kernel and simply ignore the RAM disk.

Quoted 3 lines

I have the sense that this code is pretty much a work in progress, but I'd like to hear otherwise from those who have used it.

OK, so let's wait for the others' opinions.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

Best regards,
Marek Vasut

I would recommend 1/3 & 2/3 for 2014.10 (I'm not certain about 3/3 because I don't think that it can actually occur on my boards....) Thanks, Steve

OK, Lukasz, do you want to send me a PR with those two ?

There aren't any pending DFU patches, so I don't plan any PR before our ELCE2014 meeting.

Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb directly.

Quoted 3 lines

Best regards,
Marek Vasut

Signature · 5 lines
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
#19 lore raw

cover usb: gadget: fastboot miscellaneous patches

Quoted 75 lines · Lukasz Majewski

Hi Marek,

Quoted 73 lines · Steve Rae
Quoted 71 lines · Marek Vasut
Quoted 58 lines · Eric Nelson
Quoted 57 lines

Hi Marek,

Quoted 21 lines · Marek Vasut

On Tuesday, September 30, 2014 at 09:47:07 PM, Eric Nelson

Quoted 18 lines · wrote:

Hi Marek,

Quoted 15 lines · Marek Vasut

On Tuesday, September 30, 2014 at 09:05:39 PM, Eric Nelson

Quoted 11 lines · wrote:

While trying to configure Nitrogen6X boards to use Android Fastboot, I found a number of places where the implementation doesn't appear to match the latest host tools on AOSP.

Eric Nelson (3):
usb: gadget: fastboot: add max-download-size variable
usb: gadget: fastboot: explicitly set radix of maximum

download size usb: gadget: fastboot: terminate commands with NULL

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

Just to make sure, are those fixes for 2014.10 or new stuff for next ?

These patches are against master, but should apply against usb/next and dfu/next and "next" is fine for us.

3/3 looks like a bugfix though. Is that a bugfix ?

I wasn't able to get fastboot to do much of anything without all three.

-- lack of max-download-size simply stopped downloads -- the missing radix caused my host to think that the 0x07000000 size (copied from Beagle) was 1.8 MiB instead of 100+ MiB. -- the lack of termination showed up as a request to download a **huge** image when I tried to send u-boot.imx. I think I got lucky that the next characters in the buffer looked like hex digits.

I suspect that others are either holding on to some local patches or are perhaps using old versions of the Fastboot host program.

After applying all three, I was able to configure for flashing on an MMC device, but I don't have anything configured to use EFI partitions, so there's no immediate route to usage for us.

I'd really like to be able to "fastboot flash bootloader u-boot.imx" and program SPI-NOR and also be able to boot a kernel and RAM disk using "fastboot boot uImage uramdisk.img", but neither of them seems very close. The first needs some more structure, and the latter seemed to decide its' own address for the kernel and simply ignore the RAM disk.

Quoted 8 lines
Quoted 3 lines

I have the sense that this code is pretty much a work in progress, but I'd like to hear otherwise from those who have used it.

OK, so let's wait for the others' opinions.

Best regards,
Marek Vasut

I would recommend 1/3 & 2/3 for 2014.10 (I'm not certain about 3/3 because I don't think that it can actually occur on my boards....) Thanks, Steve

Quoted 6 lines
Quoted 1 line

OK, Lukasz, do you want to send me a PR with those two ?

There aren't any pending DFU patches, so I don't plan any PR before our ELCE2014 meeting.

Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb directly.

OK, done. Would you please keep an eye on 3/3 for me ?

#20 lore raw

cover usb: gadget: fastboot miscellaneous patches

Hi Marek,

Quoted 12 lines · Marek Vasut
Quoted 8 lines · Lukasz Majewski

Hi Marek,

<snip>

There aren't any pending DFU patches, so I don't plan any PR before our ELCE2014 meeting.

Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb directly.

OK, done. Would you please keep an eye on 3/3 for me ?

Is there an issue with 3/3? It seems to be needed to prevent reading of portions of the buffer that aren't part of the current command (especially strtoul).

Please advise,

Eric

#21 lore raw

cover usb: gadget: fastboot miscellaneous patches

Quoted 13 lines · Eric Nelson

Hi Marek,

Quoted 10 lines · Marek Vasut
Quoted 8 lines · Lukasz Majewski

Hi Marek,

<snip>

There aren't any pending DFU patches, so I don't plan any PR before our ELCE2014 meeting.

Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb directly.

Quoted 7 lines
Quoted 1 line

OK, done. Would you please keep an eye on 3/3 for me ?

Is there an issue with 3/3? It seems to be needed to prevent reading of portions of the buffer that aren't part of the current command (especially strtoul).

Please advise,

OK, I will pick the 3/3 too.

btw. The patch is not checkpatch clear. I _do_ know you know better than to submit such a poor patch. I will fix this locally.

Best regards,
Marek Vasut

#22 lore raw

cover usb: gadget: fastboot miscellaneous patches

Quoted 20 lines · Marek Vasut
Quoted 19 lines · Eric Nelson

Hi Marek,

Quoted 11 lines · Marek Vasut
Quoted 8 lines · Lukasz Majewski

Hi Marek,

<snip>

There aren't any pending DFU patches, so I don't plan any PR before our ELCE2014 meeting.

Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb directly.

OK, done. Would you please keep an eye on 3/3 for me ?

Is there an issue with 3/3? It seems to be needed to prevent reading of portions of the buffer that aren't part of the current command (especially strtoul).

Quoted 7 lines
Quoted 1 line

Please advise,

OK, I will pick the 3/3 too.

btw. The patch is not checkpatch clear. I _do_ know you know better than to submit such a poor patch. I will fix this locally.

Thanks Marek,

I do know better and missed it in V2.

#23 lore raw

cover usb: gadget: fastboot miscellaneous patches

Quoted 24 lines · Eric Nelson
Quoted 23 lines · Marek Vasut
Quoted 21 lines · Eric Nelson

Hi Marek,

Quoted 5 lines · Marek Vasut
Quoted 4 lines · Lukasz Majewski

Hi Marek,

<snip>

Quoted 7 lines
Quoted 5 lines

There aren't any pending DFU patches, so I don't plan any PR before our ELCE2014 meeting.

Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb directly.

OK, done. Would you please keep an eye on 3/3 for me ?

Is there an issue with 3/3? It seems to be needed to prevent reading of portions of the buffer that aren't part of the current command (especially strtoul).

Please advise,

Quoted 8 lines
Quoted 4 lines

OK, I will pick the 3/3 too.

btw. The patch is not checkpatch clear. I _do_ know you know better than to submit such a poor patch. I will fix this locally.

Thanks Marek,

I do know better and missed it in V2.

No worries, thank you!

Best regards,
Marek Vasut

#24 lore raw

cover usb: gadget: fastboot miscellaneous patches

In reply to Marek Vasut

Hi Marek,

Quoted 82 lines · Lukasz Majewski
Quoted 81 lines

Hi Marek,

Quoted 78 lines · Steve Rae
Quoted 67 lines · Marek Vasut
Quoted 66 lines
Quoted 63 lines · Eric Nelson

Hi Marek,

Quoted 21 lines · Marek Vasut

On Tuesday, September 30, 2014 at 09:47:07 PM, Eric Nelson

Quoted 18 lines · wrote:

Hi Marek,

Quoted 15 lines · Marek Vasut

On Tuesday, September 30, 2014 at 09:05:39 PM, Eric Nelson

Quoted 11 lines · wrote:

While trying to configure Nitrogen6X boards to use Android Fastboot, I found a number of places where the implementation doesn't appear to match the latest host tools on AOSP.

Eric Nelson (3):
usb: gadget: fastboot: add max-download-size variable
usb: gadget: fastboot: explicitly set radix of maximum

download size usb: gadget: fastboot: terminate commands with NULL

Quoted 7 lines
Quoted 5 lines
Quoted 2 lines

Just to make sure, are those fixes for 2014.10 or new stuff for next ?

These patches are against master, but should apply against usb/next and dfu/next and "next" is fine for us.

3/3 looks like a bugfix though. Is that a bugfix ?

I wasn't able to get fastboot to do much of anything without all three.

-- lack of max-download-size simply stopped downloads -- the missing radix caused my host to think that the 0x07000000 size (copied from Beagle) was 1.8 MiB instead of 100+ MiB. -- the lack of termination showed up as a request to download a **huge** image when I tried to send u-boot.imx. I think I got lucky that the next characters in the buffer looked like hex digits.

I suspect that others are either holding on to some local patches or are perhaps using old versions of the Fastboot host program.

After applying all three, I was able to configure for flashing on an MMC device, but I don't have anything configured to use EFI partitions, so there's no immediate route to usage for us.

I'd really like to be able to "fastboot flash bootloader u-boot.imx" and program SPI-NOR and also be able to boot a kernel and RAM disk using "fastboot boot uImage uramdisk.img", but neither of them seems very close. The first needs some more structure, and the latter seemed to decide its' own address for the kernel and simply ignore the RAM disk.

I have the sense that this code is pretty much a work in progress, but I'd like to hear otherwise from those who have used it.

Quoted 8 lines
Quoted 4 lines

OK, so let's wait for the others' opinions.

Best regards,
Marek Vasut

I would recommend 1/3 & 2/3 for 2014.10 (I'm not certain about 3/3 because I don't think that it can actually occur on my boards....) Thanks, Steve

OK, Lukasz, do you want to send me a PR with those two ?

Quoted 7 lines
Quoted 5 lines

There aren't any pending DFU patches, so I don't plan any PR before our ELCE2014 meeting.

Therefore please, if possible, pull 1/3 and 2/3 to u-boot-usb directly.

OK, done. Would you please keep an eye on 3/3 for me ?

Ok. No problem (If I would be added to CC).

Signature · 5 lines
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group