* [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes @ 2012-11-30 18:01 Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 1/9] usb: Fix bug when both DFU & ETHER are defined Pantelis Antoniou ` (9 more replies) 0 siblings, 10 replies; 35+ messages in thread From: Pantelis Antoniou @ 2012-11-30 18:01 UTC (permalink / raw) To: u-boot Third take of USB + DFU updates. Changelog for the pendants: changes from v2: * Handle large transfers properly take #2 * Different method of avoid double linking of usb gadget & usb ether. changes from v1: * Properly terminate terminate string list. * Handle large transfers properly take #1 Pantelis Antoniou (9): usb: Fix bug when both DFU & ETHER are defined g_dnl: Issue connect/disconnect as appropriate g_dnl: Properly terminate string list. dfu: Only perform DFU board_usb_init() for TRATS dfu: Fix crash when wrong number of arguments given dfu: Send correct DFU response from composite_setup dfu: Properly zero out timeout value dfu: Add a partition type target dfu: Support larger than memory transfers. common/cmd_dfu.c | 5 +- drivers/dfu/dfu.c | 244 ++++++++++++++++++++++++++++-------- drivers/dfu/dfu_mmc.c | 109 ++++++++++++---- drivers/usb/gadget/Makefile | 8 +- drivers/usb/gadget/composite.c | 27 ++++ drivers/usb/gadget/ep0.c | 1 + drivers/usb/gadget/f_dfu.c | 9 +- drivers/usb/gadget/g_dnl.c | 12 +- include/configs/am335x_evm.h | 1 + include/configs/am3517_evm.h | 1 + include/configs/h2200.h | 1 + include/configs/omap3_beagle.h | 1 + include/configs/s5p_goni.h | 1 + include/configs/s5pc210_universal.h | 1 + include/configs/trats.h | 1 + include/dfu.h | 21 +++- 16 files changed, 356 insertions(+), 87 deletions(-) -- 1.7.12 ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 1/9] usb: Fix bug when both DFU & ETHER are defined 2012-11-30 18:01 [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Pantelis Antoniou @ 2012-11-30 18:01 ` Pantelis Antoniou 2012-12-01 5:30 ` Marek Vasut 2012-11-30 18:01 ` [U-Boot] [PATCH v3 2/9] g_dnl: Issue connect/disconnect as appropriate Pantelis Antoniou ` (8 subsequent siblings) 9 siblings, 1 reply; 35+ messages in thread From: Pantelis Antoniou @ 2012-11-30 18:01 UTC (permalink / raw) To: u-boot When both CONFIG_USB_GADGET & CONFIG_USB_ETHER are defined the makefile links objects twice. The cleanest way to fix is to use a new define, CONFIG_USB_UTIL which must be defined when either CONFIG_USB_ETHER or CONFIG_USB_GADGET are defined. All affected boards have been modified as well. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> --- drivers/usb/gadget/Makefile | 8 ++++++-- include/configs/am335x_evm.h | 1 + include/configs/am3517_evm.h | 1 + include/configs/h2200.h | 1 + include/configs/omap3_beagle.h | 1 + include/configs/s5p_goni.h | 1 + include/configs/s5pc210_universal.h | 1 + include/configs/trats.h | 1 + 8 files changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 040eaba..167f24f 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -25,15 +25,19 @@ include $(TOPDIR)/config.mk LIB := $(obj)libusb_gadget.o +# required for both USB_GADGET & USB_ETHER +ifdef CONFIG_USB_UTIL +COBJS-y += epautoconf.o config.o usbstring.o +endif + # new USB gadget layer dependencies ifdef CONFIG_USB_GADGET -COBJS-y += epautoconf.o config.o usbstring.o COBJS-$(CONFIG_USB_GADGET_S3C_UDC_OTG) += s3c_udc_otg.o COBJS-$(CONFIG_USBDOWNLOAD_GADGET) += g_dnl.o COBJS-$(CONFIG_DFU_FUNCTION) += f_dfu.o endif ifdef CONFIG_USB_ETHER -COBJS-y += ether.o epautoconf.o config.o usbstring.o +COBJS-y += ether.o COBJS-$(CONFIG_USB_ETH_RNDIS) += rndis.o COBJS-$(CONFIG_MV_UDC) += mv_udc.o COBJS-$(CONFIG_CPU_PXA25X) += pxa25x_udc.o diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index ab9549b..ee19e54 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -278,6 +278,7 @@ #ifdef CONFIG_MUSB_GADGET #define CONFIG_USB_ETHER +#define CONFIG_USB_UTIL #define CONFIG_USB_ETH_RNDIS #endif /* CONFIG_MUSB_GADGET */ diff --git a/include/configs/am3517_evm.h b/include/configs/am3517_evm.h index ba15325..3aedff3 100644 --- a/include/configs/am3517_evm.h +++ b/include/configs/am3517_evm.h @@ -123,6 +123,7 @@ #ifdef CONFIG_MUSB_GADGET #define CONFIG_USB_GADGET_DUALSPEED #define CONFIG_USB_ETHER +#define CONFIG_USB_UTIL #define CONFIG_USB_ETH_RNDIS #endif /* CONFIG_MUSB_GADGET */ diff --git a/include/configs/h2200.h b/include/configs/h2200.h index 516a26e..fc27bf0 100644 --- a/include/configs/h2200.h +++ b/include/configs/h2200.h @@ -170,6 +170,7 @@ #define CONFIG_USB_GADGET_PXA2XX #define CONFIG_USB_ETHER +#define CONFIG_USB_UTIL #define CONFIG_USB_ETH_SUBSET #define CONFIG_USBNET_DEV_ADDR "de:ad:be:ef:00:01" diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 12d65f2..04fbb5d 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -123,6 +123,7 @@ #define CONFIG_USB_GADGET_DUALSPEED #define CONFIG_TWL4030_USB 1 #define CONFIG_USB_ETHER +#define CONFIG_USB_UTIL #define CONFIG_USB_ETHER_RNDIS /* USB EHCI */ diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index 56e8347..1e180ade 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -231,6 +231,7 @@ #define CONFIG_I2C_MULTI_BUS #define CONFIG_SYS_MAX_I2C_BUS 7 #define CONFIG_USB_GADGET +#define CONFIG_USB_UTIL #define CONFIG_USB_GADGET_S3C_UDC_OTG #define CONFIG_USB_GADGET_DUALSPEED diff --git a/include/configs/s5pc210_universal.h b/include/configs/s5pc210_universal.h index 894f38b..07ab884 100644 --- a/include/configs/s5pc210_universal.h +++ b/include/configs/s5pc210_universal.h @@ -258,6 +258,7 @@ #define CONFIG_POWER_MAX8998 #define CONFIG_USB_GADGET +#define CONFIG_USB_UTIL #define CONFIG_USB_GADGET_S3C_UDC_OTG #define CONFIG_USB_GADGET_DUALSPEED diff --git a/include/configs/trats.h b/include/configs/trats.h index 355029e..7c2c875 100644 --- a/include/configs/trats.h +++ b/include/configs/trats.h @@ -245,6 +245,7 @@ #define CONFIG_POWER_BATTERY #define CONFIG_POWER_BATTERY_TRATS #define CONFIG_USB_GADGET +#define CONFIG_USB_UTIL #define CONFIG_USB_GADGET_S3C_UDC_OTG #define CONFIG_USB_GADGET_DUALSPEED #define CONFIG_USB_GADGET_VBUS_DRAW 2 -- 1.7.12 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 1/9] usb: Fix bug when both DFU & ETHER are defined 2012-11-30 18:01 ` [U-Boot] [PATCH v3 1/9] usb: Fix bug when both DFU & ETHER are defined Pantelis Antoniou @ 2012-12-01 5:30 ` Marek Vasut 2012-12-03 10:10 ` Pantelis Antoniou 0 siblings, 1 reply; 35+ messages in thread From: Marek Vasut @ 2012-12-01 5:30 UTC (permalink / raw) To: u-boot Dear Pantelis Antoniou, > When both CONFIG_USB_GADGET & CONFIG_USB_ETHER are defined > the makefile links objects twice. > > The cleanest way to fix is to use a new define, CONFIG_USB_UTIL > which must be defined when either CONFIG_USB_ETHER or > CONFIG_USB_GADGET are defined. > > All affected boards have been modified as well. > > Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> Quick google [1] http://old.nabble.com/if-defined%28a%29-||-defined%28b%29-td26806006.html This won't work? Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 1/9] usb: Fix bug when both DFU & ETHER are defined 2012-12-01 5:30 ` Marek Vasut @ 2012-12-03 10:10 ` Pantelis Antoniou 0 siblings, 0 replies; 35+ messages in thread From: Pantelis Antoniou @ 2012-12-03 10:10 UTC (permalink / raw) To: u-boot Hi Marek, On Dec 1, 2012, at 7:30 AM, Marek Vasut wrote: > Dear Pantelis Antoniou, > >> When both CONFIG_USB_GADGET & CONFIG_USB_ETHER are defined >> the makefile links objects twice. >> >> The cleanest way to fix is to use a new define, CONFIG_USB_UTIL >> which must be defined when either CONFIG_USB_ETHER or >> CONFIG_USB_GADGET are defined. >> >> All affected boards have been modified as well. >> >> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> > > Quick google [1] > > http://old.nabble.com/if-defined%28a%29-||-defined%28b%29-td26806006.html > > This won't work? > Somehow I missed that. Makes some kind of (awful) sense. Updated patch incoming... > Best regards, > Marek Vasut ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 2/9] g_dnl: Issue connect/disconnect as appropriate 2012-11-30 18:01 [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 1/9] usb: Fix bug when both DFU & ETHER are defined Pantelis Antoniou @ 2012-11-30 18:01 ` Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 3/9] g_dnl: Properly terminate string list Pantelis Antoniou ` (7 subsequent siblings) 9 siblings, 0 replies; 35+ messages in thread From: Pantelis Antoniou @ 2012-11-30 18:01 UTC (permalink / raw) To: u-boot Call usb_gadget_connect/usb_gadget_disconnect in g_dnl_bind/g_dnl_unbind. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> --- drivers/usb/gadget/g_dnl.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c index 7d87050..25da733 100644 --- a/drivers/usb/gadget/g_dnl.c +++ b/drivers/usb/gadget/g_dnl.c @@ -83,7 +83,12 @@ static struct usb_gadget_strings *g_dnl_composite_strings[] = { static int g_dnl_unbind(struct usb_composite_dev *cdev) { - debug("%s\n", __func__); + struct usb_gadget *gadget = cdev->gadget; + + debug("%s: calling usb_gadget_disconnect for " + "controller '%s'\n", shortname, gadget->name); + usb_gadget_disconnect(gadget); + return 0; } @@ -153,6 +158,10 @@ static int g_dnl_bind(struct usb_composite_dev *cdev) device_desc.bcdDevice = __constant_cpu_to_le16(0x9999); } + debug("%s: calling usb_gadget_connect for " + "controller '%s'\n", shortname, gadget->name); + usb_gadget_connect(gadget); + return 0; error: -- 1.7.12 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 3/9] g_dnl: Properly terminate string list. 2012-11-30 18:01 [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 1/9] usb: Fix bug when both DFU & ETHER are defined Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 2/9] g_dnl: Issue connect/disconnect as appropriate Pantelis Antoniou @ 2012-11-30 18:01 ` Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 4/9] dfu: Only perform DFU board_usb_init() for TRATS Pantelis Antoniou ` (6 subsequent siblings) 9 siblings, 0 replies; 35+ messages in thread From: Pantelis Antoniou @ 2012-11-30 18:01 UTC (permalink / raw) To: u-boot Well, not terminating the list causes very interesting crashes. As in changing the vendor & product ID crashes. Fun. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> --- drivers/usb/gadget/g_dnl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c index 25da733..a5a4c1f 100644 --- a/drivers/usb/gadget/g_dnl.c +++ b/drivers/usb/gadget/g_dnl.c @@ -69,6 +69,7 @@ static struct usb_device_descriptor device_desc = { static struct usb_string g_dnl_string_defs[] = { { 0, manufacturer, }, { 1, product, }, + { } /* end of list */ }; static struct usb_gadget_strings g_dnl_string_tab = { -- 1.7.12 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 4/9] dfu: Only perform DFU board_usb_init() for TRATS 2012-11-30 18:01 [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Pantelis Antoniou ` (2 preceding siblings ...) 2012-11-30 18:01 ` [U-Boot] [PATCH v3 3/9] g_dnl: Properly terminate string list Pantelis Antoniou @ 2012-11-30 18:01 ` Pantelis Antoniou 2012-12-01 5:31 ` Marek Vasut 2012-11-30 18:01 ` [U-Boot] [PATCH v3 5/9] dfu: Fix crash when wrong number of arguments given Pantelis Antoniou ` (5 subsequent siblings) 9 siblings, 1 reply; 35+ messages in thread From: Pantelis Antoniou @ 2012-11-30 18:01 UTC (permalink / raw) To: u-boot USB initialization shouldn't happen for all the boards. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> --- common/cmd_dfu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c index 01d6b3a..327c738 100644 --- a/common/cmd_dfu.c +++ b/common/cmd_dfu.c @@ -55,7 +55,10 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) goto done; } +#ifdef CONFIG_TRATS board_usb_init(); +#endif + g_dnl_register(s); while (1) { if (ctrlc()) -- 1.7.12 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 4/9] dfu: Only perform DFU board_usb_init() for TRATS 2012-11-30 18:01 ` [U-Boot] [PATCH v3 4/9] dfu: Only perform DFU board_usb_init() for TRATS Pantelis Antoniou @ 2012-12-01 5:31 ` Marek Vasut 0 siblings, 0 replies; 35+ messages in thread From: Marek Vasut @ 2012-12-01 5:31 UTC (permalink / raw) To: u-boot Dear Pantelis Antoniou, > USB initialization shouldn't happen for all the boards. > > Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> > --- > common/cmd_dfu.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c > index 01d6b3a..327c738 100644 > --- a/common/cmd_dfu.c > +++ b/common/cmd_dfu.c > @@ -55,7 +55,10 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, > char * const argv[]) goto done; > } > > +#ifdef CONFIG_TRATS > board_usb_init(); > +#endif > + Can this "board_usb_init()" _please_ be renamed? > g_dnl_register(s); > while (1) { > if (ctrlc()) Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 5/9] dfu: Fix crash when wrong number of arguments given 2012-11-30 18:01 [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Pantelis Antoniou ` (3 preceding siblings ...) 2012-11-30 18:01 ` [U-Boot] [PATCH v3 4/9] dfu: Only perform DFU board_usb_init() for TRATS Pantelis Antoniou @ 2012-11-30 18:01 ` Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup Pantelis Antoniou ` (4 subsequent siblings) 9 siblings, 0 replies; 35+ messages in thread From: Pantelis Antoniou @ 2012-11-30 18:01 UTC (permalink / raw) To: u-boot Fix obvious crash when not enough arguments are given to the dfu command. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> --- common/cmd_dfu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c index 327c738..83ef324 100644 --- a/common/cmd_dfu.c +++ b/common/cmd_dfu.c @@ -50,7 +50,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if (ret) return CMD_RET_FAILURE; - if (strcmp(argv[3], "list") == 0) { + if (argc > 3 && strcmp(argv[3], "list") == 0) { dfu_show_entities(); goto done; } -- 1.7.12 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-11-30 18:01 [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Pantelis Antoniou ` (4 preceding siblings ...) 2012-11-30 18:01 ` [U-Boot] [PATCH v3 5/9] dfu: Fix crash when wrong number of arguments given Pantelis Antoniou @ 2012-11-30 18:01 ` Pantelis Antoniou 2012-12-10 17:11 ` Lukasz Majewski 2012-11-30 18:01 ` [U-Boot] [PATCH v3 7/9] dfu: Properly zero out timeout value Pantelis Antoniou ` (3 subsequent siblings) 9 siblings, 1 reply; 35+ messages in thread From: Pantelis Antoniou @ 2012-11-30 18:01 UTC (permalink / raw) To: u-boot DFU is a bit peculiar. It needs to hook to composite setup and return it's function descriptor. So when get-descriptor request comes with a type of DFU_DT_FUNC we iterate over the configs, and functions, and when we find the DFU function we call the setup method which is prepared to return the appropriate function descriptor. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> --- drivers/usb/gadget/composite.c | 27 +++++++++++++++++++++++++++ drivers/usb/gadget/ep0.c | 1 + drivers/usb/gadget/f_dfu.c | 6 ++++-- 3 files changed, 32 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c index ebb5131..6496436 100644 --- a/drivers/usb/gadget/composite.c +++ b/drivers/usb/gadget/composite.c @@ -773,6 +773,33 @@ composite_setup(struct usb_gadget *gadget, const struct usb_ctrlrequest *ctrl) if (value >= 0) value = min(w_length, (u16) value); break; + +#ifdef CONFIG_DFU_FUNCTION + /* DFU is mighty weird */ + case DFU_DT_FUNC: + w_value &= 0xff; + list_for_each_entry(c, &cdev->configs, list) { + if (w_value != 0) { + w_value--; + continue; + } + + list_for_each_entry(f, &c->functions, list) { + + /* DFU function only */ + if (strcmp(f->name, "dfu") != 0) + continue; + + value = f->setup(f, ctrl); + goto dfu_func_done; + } + } +dfu_func_done: + if (value >= 0) + value = min(w_length, (u16) value); + break; +#endif + default: goto unknown; } diff --git a/drivers/usb/gadget/ep0.c b/drivers/usb/gadget/ep0.c index aa8f916..971d846 100644 --- a/drivers/usb/gadget/ep0.c +++ b/drivers/usb/gadget/ep0.c @@ -221,6 +221,7 @@ static int ep0_get_descriptor (struct usb_device_instance *device, break; case USB_DESCRIPTOR_TYPE_CONFIGURATION: + case USB_DESCRIPTOR_TYPE_OTHER_SPEED_CONFIGURATION: { struct usb_configuration_descriptor *configuration_descriptor; diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c index 10547e3..6494f5e 100644 --- a/drivers/usb/gadget/f_dfu.c +++ b/drivers/usb/gadget/f_dfu.c @@ -534,8 +534,10 @@ dfu_handle(struct usb_function *f, const struct usb_ctrlrequest *ctrl) value = min(len, (u16) sizeof(dfu_func)); memcpy(req->buf, &dfu_func, value); } - } else /* DFU specific request */ - value = dfu_state[f_dfu->dfu_state] (f_dfu, ctrl, gadget, req); + return value; + } + + value = dfu_state[f_dfu->dfu_state] (f_dfu, ctrl, gadget, req); if (value >= 0) { req->length = value; -- 1.7.12 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-11-30 18:01 ` [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup Pantelis Antoniou @ 2012-12-10 17:11 ` Lukasz Majewski 2012-12-10 18:21 ` Pantelis Antoniou 0 siblings, 1 reply; 35+ messages in thread From: Lukasz Majewski @ 2012-12-10 17:11 UTC (permalink / raw) To: u-boot Hi Pantelis, > DFU is a bit peculiar. It needs to hook to composite setup and > return it's function descriptor. > > So when get-descriptor request comes with a type of DFU_DT_FUNC > we iterate over the configs, and functions, and when we find > the DFU function we call the setup method which is prepared > to return the appropriate function descriptor. Sorry, but could you be more informative here? Have you had any non standard problems? I wonder why dfu-util on my linux works OK without this patch? > > Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> > --- > drivers/usb/gadget/composite.c | 27 +++++++++++++++++++++++++++ > drivers/usb/gadget/ep0.c | 1 + > drivers/usb/gadget/f_dfu.c | 6 ++++-- > 3 files changed, 32 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/gadget/composite.c > b/drivers/usb/gadget/composite.c index ebb5131..6496436 100644 > --- a/drivers/usb/gadget/composite.c > +++ b/drivers/usb/gadget/composite.c > @@ -773,6 +773,33 @@ composite_setup(struct usb_gadget *gadget, const > struct usb_ctrlrequest *ctrl) if (value >= 0) > value = min(w_length, (u16) value); > break; > + > +#ifdef CONFIG_DFU_FUNCTION > + /* DFU is mighty weird */ ^^^^^^ - please explain this "wiredness". I don't recall such a hacks in linux kernel composite.c (any special #ifdef). Am I missing something important in DFU? Does your device have any special requirement, so you need this hack? I generally don't like the idea to "patch" composite gadget code with #ifdefs for special function. Please convince me. > + case DFU_DT_FUNC: > + w_value &= 0xff; > + list_for_each_entry(c, &cdev->configs, list) > { > + if (w_value != 0) { > + w_value--; > + continue; > + } > + > + list_for_each_entry(f, > &c->functions, list) { + > + /* DFU function only */ > + if (strcmp(f->name, > "dfu") != 0) > + continue; > + > + value = f->setup(f, ctrl); > + goto dfu_func_done; > + } > + } > +dfu_func_done: > + if (value >= 0) > + value = min(w_length, (u16) value); > + break; > +#endif > + > default: > goto unknown; > } > diff --git a/drivers/usb/gadget/ep0.c b/drivers/usb/gadget/ep0.c > index aa8f916..971d846 100644 > --- a/drivers/usb/gadget/ep0.c > +++ b/drivers/usb/gadget/ep0.c > @@ -221,6 +221,7 @@ static int ep0_get_descriptor (struct > usb_device_instance *device, break; > > case USB_DESCRIPTOR_TYPE_CONFIGURATION: > + case USB_DESCRIPTOR_TYPE_OTHER_SPEED_CONFIGURATION: ^^^^^^^^^^^^^- why do you need that? > { > struct usb_configuration_descriptor > *configuration_descriptor; > diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c > index 10547e3..6494f5e 100644 > --- a/drivers/usb/gadget/f_dfu.c > +++ b/drivers/usb/gadget/f_dfu.c > @@ -534,8 +534,10 @@ dfu_handle(struct usb_function *f, const struct > usb_ctrlrequest *ctrl) value = min(len, (u16) sizeof(dfu_func)); > memcpy(req->buf, &dfu_func, value); > } > - } else /* DFU specific request */ > - value = dfu_state[f_dfu->dfu_state] (f_dfu, ctrl, > gadget, req); > + return value; > + } > + > + value = dfu_state[f_dfu->dfu_state] (f_dfu, ctrl, gadget, > req); Why do you change state even after receiving req_type == USB_TYPE_STANDARD? I would expect to change the dfu state only when DFU specific request appears. > if (value >= 0) { > req->length = value; -- Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-10 17:11 ` Lukasz Majewski @ 2012-12-10 18:21 ` Pantelis Antoniou 2012-12-10 19:26 ` Lukasz Majewski 0 siblings, 1 reply; 35+ messages in thread From: Pantelis Antoniou @ 2012-12-10 18:21 UTC (permalink / raw) To: u-boot Hi Lukasz, On Dec 10, 2012, at 7:11 PM, Lukasz Majewski wrote: > Hi Pantelis, > >> DFU is a bit peculiar. It needs to hook to composite setup and >> return it's function descriptor. >> >> So when get-descriptor request comes with a type of DFU_DT_FUNC >> we iterate over the configs, and functions, and when we find >> the DFU function we call the setup method which is prepared >> to return the appropriate function descriptor. > > Sorry, but could you be more informative here? Have you had any non > standard problems? I wonder why dfu-util on my linux works OK without > this patch? > I have absolutely no idea why it works at your side. At our side it just didn't work at all without the patches. If I had to guess maybe your gadget h/w takes care of replying properly for the DFU case. >> >> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> >> --- >> drivers/usb/gadget/composite.c | 27 +++++++++++++++++++++++++++ >> drivers/usb/gadget/ep0.c | 1 + >> drivers/usb/gadget/f_dfu.c | 6 ++++-- >> 3 files changed, 32 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/usb/gadget/composite.c >> b/drivers/usb/gadget/composite.c index ebb5131..6496436 100644 >> --- a/drivers/usb/gadget/composite.c >> +++ b/drivers/usb/gadget/composite.c >> @@ -773,6 +773,33 @@ composite_setup(struct usb_gadget *gadget, const >> struct usb_ctrlrequest *ctrl) if (value >= 0) >> value = min(w_length, (u16) value); >> break; >> + >> +#ifdef CONFIG_DFU_FUNCTION >> + /* DFU is mighty weird */ > ^^^^^^ - please explain this > "wiredness". > > I don't recall such a hacks in linux kernel composite.c (any special > #ifdef). Am I missing something important in DFU? > > > Does your device have any special requirement, so you need this hack? > > I generally don't like the idea to "patch" composite gadget code with > #ifdefs for special function. Please convince me. It doesn't work otherwise. I have no idea why you think I would be hacking around there if the thing worked at all. And trust me on that, it just doesn't without those patches, not to mention the way it unceremoniously blows up if you transfer anything larger than the buffer set aside originally. The way I see it, instead of complaining you should be rejoicing since now DFU will be used in an actual production environment. More users == less bugs. When I get a few free cycles I will post a tcpdump capture of the DFU USB transaction hanging. > >> + case DFU_DT_FUNC: >> + w_value &= 0xff; >> + list_for_each_entry(c, &cdev->configs, list) >> { >> + if (w_value != 0) { >> + w_value--; >> + continue; >> + } >> + >> + list_for_each_entry(f, >> &c->functions, list) { + >> + /* DFU function only */ >> + if (strcmp(f->name, >> "dfu") != 0) >> + continue; >> + >> + value = f->setup(f, ctrl); >> + goto dfu_func_done; >> + } >> + } >> +dfu_func_done: >> + if (value >= 0) >> + value = min(w_length, (u16) value); >> + break; >> +#endif >> + >> default: >> goto unknown; >> } >> diff --git a/drivers/usb/gadget/ep0.c b/drivers/usb/gadget/ep0.c >> index aa8f916..971d846 100644 >> --- a/drivers/usb/gadget/ep0.c >> +++ b/drivers/usb/gadget/ep0.c >> @@ -221,6 +221,7 @@ static int ep0_get_descriptor (struct >> usb_device_instance *device, break; >> >> case USB_DESCRIPTOR_TYPE_CONFIGURATION: >> + case USB_DESCRIPTOR_TYPE_OTHER_SPEED_CONFIGURATION: > ^^^^^^^^^^^^^- why do you need that? >> { >> struct usb_configuration_descriptor >> *configuration_descriptor; >> diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c >> index 10547e3..6494f5e 100644 >> --- a/drivers/usb/gadget/f_dfu.c >> +++ b/drivers/usb/gadget/f_dfu.c >> @@ -534,8 +534,10 @@ dfu_handle(struct usb_function *f, const struct >> usb_ctrlrequest *ctrl) value = min(len, (u16) sizeof(dfu_func)); >> memcpy(req->buf, &dfu_func, value); >> } >> - } else /* DFU specific request */ >> - value = dfu_state[f_dfu->dfu_state] (f_dfu, ctrl, >> gadget, req); >> + return value; >> + } >> + >> + value = dfu_state[f_dfu->dfu_state] (f_dfu, ctrl, gadget, >> req); > > Why do you change state even after receiving req_type == > USB_TYPE_STANDARD? I would expect to change the dfu state only when DFU > specific request appears. > > > >> if (value >= 0) { >> req->length = value; > > > > -- > Best regards, > > Lukasz Majewski > > Samsung Poland R&D Center | Linux Platform Group Regards -- Pantelis ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-10 18:21 ` Pantelis Antoniou @ 2012-12-10 19:26 ` Lukasz Majewski 2012-12-11 0:47 ` Marek Vasut ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Lukasz Majewski @ 2012-12-10 19:26 UTC (permalink / raw) To: u-boot Pantelis, > Hi Lukasz, > > On Dec 10, 2012, at 7:11 PM, Lukasz Majewski wrote: > > > Hi Pantelis, > > > >> DFU is a bit peculiar. It needs to hook to composite setup and > >> return it's function descriptor. > >> > >> So when get-descriptor request comes with a type of DFU_DT_FUNC > >> we iterate over the configs, and functions, and when we find > >> the DFU function we call the setup method which is prepared > >> to return the appropriate function descriptor. > > > > Sorry, but could you be more informative here? Have you had any non > > standard problems? I wonder why dfu-util on my linux works OK > > without this patch? > > > > I have absolutely no idea why it works at your side. > > At our side it just didn't work at all without the patches. > > If I had to guess maybe your gadget h/w takes care of replying > properly for the DFU case. > > >> > >> Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> > >> --- > >> drivers/usb/gadget/composite.c | 27 +++++++++++++++++++++++++++ > >> drivers/usb/gadget/ep0.c | 1 + > >> drivers/usb/gadget/f_dfu.c | 6 ++++-- > >> 3 files changed, 32 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/usb/gadget/composite.c > >> b/drivers/usb/gadget/composite.c index ebb5131..6496436 100644 > >> --- a/drivers/usb/gadget/composite.c > >> +++ b/drivers/usb/gadget/composite.c > >> @@ -773,6 +773,33 @@ composite_setup(struct usb_gadget *gadget, > >> const struct usb_ctrlrequest *ctrl) if (value >= 0) > >> value = min(w_length, (u16) value); > >> break; > >> + > >> +#ifdef CONFIG_DFU_FUNCTION > >> + /* DFU is mighty weird */ > > ^^^^^^ - please explain this > > "wiredness". > > > > I don't recall such a hacks in linux kernel composite.c (any special > > #ifdef). Am I missing something important in DFU? > > > > > > Does your device have any special requirement, so you need this > > hack? > > > > I generally don't like the idea to "patch" composite gadget code > > with #ifdefs for special function. Please convince me. > > It doesn't work otherwise. I have no idea why you think I would be > hacking around there if the thing worked at all. And trust me on > that, it just doesn't without those patches, not to mention the way > it unceremoniously blows up if you transfer anything larger than the > buffer set aside originally. > > The way I see it, instead of complaining you should be rejoicing > since now DFU will be used in an actual production environment. I'm not complaining. I try to resolve the problem, since this can make dfu support better at u-boot. Moreover I'm aware that USB is tricky, so I want to understand your problem. Tomorrow I will prepare output of USB Ellisys analizer on my side, so we could get clue what is going on. > > More users == less bugs. I'm really happy, that you have posted patches for NAND flashing. Without your determination at debugging, problem with buffer overflow wouldn't be discovered. We "only" needs to share knowledge and provide solution acceptable for community and us. I'm open. > > When I get a few free cycles I will post a tcpdump capture of the DFU > USB transaction hanging. Yes, please. > > > > >> + case DFU_DT_FUNC: > >> + w_value &= 0xff; > >> + list_for_each_entry(c, &cdev->configs, > >> list) { > >> + if (w_value != 0) { > >> + w_value--; > >> + continue; > >> + } > >> + > >> + list_for_each_entry(f, > >> &c->functions, list) { + > >> + /* DFU function only */ > >> + if (strcmp(f->name, > >> "dfu") != 0) > >> + continue; > >> + > >> + value = f->setup(f, ctrl); > >> + goto dfu_func_done; > >> + } > >> + } > >> +dfu_func_done: > >> + if (value >= 0) > >> + value = min(w_length, (u16) > >> value); > >> + break; > >> +#endif > >> + > >> default: > >> goto unknown; > >> } > >> diff --git a/drivers/usb/gadget/ep0.c b/drivers/usb/gadget/ep0.c > >> index aa8f916..971d846 100644 > >> --- a/drivers/usb/gadget/ep0.c > >> +++ b/drivers/usb/gadget/ep0.c > >> @@ -221,6 +221,7 @@ static int ep0_get_descriptor (struct > >> usb_device_instance *device, break; > >> > >> case USB_DESCRIPTOR_TYPE_CONFIGURATION: > >> + case USB_DESCRIPTOR_TYPE_OTHER_SPEED_CONFIGURATION: > > ^^^^^^^^^^^^^- why do you need that? > >> { > >> struct usb_configuration_descriptor > >> *configuration_descriptor; > >> diff --git a/drivers/usb/gadget/f_dfu.c > >> b/drivers/usb/gadget/f_dfu.c index 10547e3..6494f5e 100644 > >> --- a/drivers/usb/gadget/f_dfu.c > >> +++ b/drivers/usb/gadget/f_dfu.c > >> @@ -534,8 +534,10 @@ dfu_handle(struct usb_function *f, const > >> struct usb_ctrlrequest *ctrl) value = min(len, (u16) > >> sizeof(dfu_func)); memcpy(req->buf, &dfu_func, value); > >> } > >> - } else /* DFU specific request */ > >> - value = dfu_state[f_dfu->dfu_state] (f_dfu, ctrl, > >> gadget, req); > >> + return value; > >> + } > >> + > >> + value = dfu_state[f_dfu->dfu_state] (f_dfu, ctrl, gadget, > >> req); > > > > Why do you change state even after receiving req_type == > > USB_TYPE_STANDARD? I would expect to change the dfu state only when > > DFU specific request appears. > > > > > > > > >> if (value >= 0) { > >> req->length = value; > > > > > > > > -- > > Best regards, > > > > Lukasz Majewski > > > > Samsung Poland R&D Center | Linux Platform Group > > Regards > > -- Pantelis Regards, Lukasz Majewski ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-10 19:26 ` Lukasz Majewski @ 2012-12-11 0:47 ` Marek Vasut 2012-12-11 8:40 ` Lukasz Majewski ` (2 more replies) 2012-12-11 11:02 ` Lukasz Majewski 2012-12-11 11:18 ` Lukasz Majewski 2 siblings, 3 replies; 35+ messages in thread From: Marek Vasut @ 2012-12-11 0:47 UTC (permalink / raw) To: u-boot Dear Lukasz Majewski, > Pantelis, [...] Hm hm ... I suspect it'd be nice to have a separate DFU custodian. That'd leverage some burden from me. I like that idea. I wonder if it'd be nice to start building such bigger net of custodians. Hm ? Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-11 0:47 ` Marek Vasut @ 2012-12-11 8:40 ` Lukasz Majewski 2012-12-11 10:47 ` Wolfgang Denk 2012-12-11 13:44 ` Tom Rini 2 siblings, 0 replies; 35+ messages in thread From: Lukasz Majewski @ 2012-12-11 8:40 UTC (permalink / raw) To: u-boot Hi Marek, > Dear Lukasz Majewski, > > > Pantelis, > [...] > > Hm hm ... I suspect it'd be nice to have a separate DFU custodian. > That'd leverage some burden from me. I like that idea. I wonder if > it'd be nice to start building such bigger net of custodians. I think,that this (political) decision shall be made by Wolfgang or Tom. > > Hm ? No problem from my side. I would be honored to be DFU maintainer (as part of USB subsystem). > > Best regards, > Marek Vasut -- Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-11 0:47 ` Marek Vasut 2012-12-11 8:40 ` Lukasz Majewski @ 2012-12-11 10:47 ` Wolfgang Denk 2012-12-11 13:44 ` Tom Rini 2 siblings, 0 replies; 35+ messages in thread From: Wolfgang Denk @ 2012-12-11 10:47 UTC (permalink / raw) To: u-boot Dear Marek Vasut, In message <201212110147.49045.marex@denx.de> you wrote: > > Hm hm ... I suspect it'd be nice to have a separate DFU custodian. That'd > leverage some burden from me. I like that idea. I wonder if it'd be nice to > start building such bigger net of custodians. I'm not sure about what the limit for a managable number of custodians might be. If the number grows too far, we need additional levels in the hierarchy, concentrators of some kind - similar to what Albert is doing for ARM. My gut feeling is that we are not close to any such limit yet, on the other hand I seriously doubt that somethign like DFU really needs the formal establishment of a custodian. Who are the regular users and who the developers of this piece of code? Best regards, Wolfgang Denk PS: I'm always surprised how the random generator manages to pick the perfectly fitting quote for my signature :-) -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Conceptual integrity in turn dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. - Frederick Brooks Jr., "The Mythical Man Month" ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-11 0:47 ` Marek Vasut 2012-12-11 8:40 ` Lukasz Majewski 2012-12-11 10:47 ` Wolfgang Denk @ 2012-12-11 13:44 ` Tom Rini 2012-12-12 17:55 ` Marek Vasut 2 siblings, 1 reply; 35+ messages in thread From: Tom Rini @ 2012-12-11 13:44 UTC (permalink / raw) To: u-boot -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/10/12 19:47, Marek Vasut wrote: > Dear Lukasz Majewski, > >> Pantelis, > [...] > > Hm hm ... I suspect it'd be nice to have a separate DFU custodian. > That'd leverage some burden from me. I like that idea. I wonder if > it'd be nice to start building such bigger net of custodians. So long as everyone involved plays nice, we have a maintainer of the code (Lukasz) and another user / developer of the code (Pantelis). I don't think we need to go full on custodian right now. Lukasz is reviewing and trying to understand what Pantelis is seeing since we're seeing some odd issues on the second platform to add DFU support. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQxzi6AAoJENk4IS6UOR1WfOcP/3ix59xKvaGPxQcW9XLBbOjj XQC1jwqsJHTMlYY+gabgCH+A8sCiL8X5qHV7fbMu9RttS1cYvojxojk0dcIxpYdI bQCAnKFKBNCAHzbXSqFJPnfrw8tZs7c0Ug+KfzscG+W6jacrCyb0U+NEV6QJdO+y w+emS4zKFRMFxS6RSeAJcj5EKUa/ozn+O43oQamDl38MQ5Tut2UNZF6gf293Xw8E +mquY3vAQiDe05x1hEt7GALwgEWrwfFVU1l5c+Xs75ERFhC2boDd8EL42GRz2HRq X9flEOiF8za+CojRJ3yLR67jMgP4p+zmWUSPQdbqnRjrw5rzM/o2K3fSFlykmQeW SmMaaB/imf3kJPskMsEQu9CGAJl/jWvUhM+wsaVp+YEMLTcOrQt9AzPFOGS/Zpee hvIYdTrhGaXNDGo02kCBIvp/X2/rVBt8x4r3zhB3dDZHGxE3c4bGed6iftO8cBxA 2NODvJ2ZDGgN8i3WKo18sg4K4W5ocGck77iBFx1grfja6jr9Xcwsn3h1QIVePTXe qMMjO7h58VrRojOr1+UwWECEbZXqr0wV8HAzTtu0KgQ4v6AcD43bHjaCg9gwWJ74 aCMmvTpW96l/8m1NAIeAWmX3fgzriMUsI/06aIpEQdFsmRF+BC452YgcyRHJbeBT vE06Y5LBMbtGFixSgq5b =gqji -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-11 13:44 ` Tom Rini @ 2012-12-12 17:55 ` Marek Vasut 2012-12-12 18:03 ` Tom Rini 0 siblings, 1 reply; 35+ messages in thread From: Marek Vasut @ 2012-12-12 17:55 UTC (permalink / raw) To: u-boot Dear Tom Rini, > On 12/10/12 19:47, Marek Vasut wrote: > > Dear Lukasz Majewski, > > > >> Pantelis, > > > > [...] > > > > Hm hm ... I suspect it'd be nice to have a separate DFU custodian. > > That'd leverage some burden from me. I like that idea. I wonder if > > it'd be nice to start building such bigger net of custodians. > > So long as everyone involved plays nice, we have a maintainer of the > code (Lukasz) and another user / developer of the code (Pantelis). I > don't think we need to go full on custodian right now. Lukasz is > reviewing and trying to understand what Pantelis is seeing since we're > seeing some odd issues on the second platform to add DFU support. WFM, but it'd leverage burden from me. And I honestly dont understand the DFU as much as Lukasz does. Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-12 17:55 ` Marek Vasut @ 2012-12-12 18:03 ` Tom Rini 0 siblings, 0 replies; 35+ messages in thread From: Tom Rini @ 2012-12-12 18:03 UTC (permalink / raw) To: u-boot -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/12/12 12:55, Marek Vasut wrote: > Dear Tom Rini, > >> On 12/10/12 19:47, Marek Vasut wrote: >>> Dear Lukasz Majewski, >>> >>>> Pantelis, >>> >>> [...] >>> >>> Hm hm ... I suspect it'd be nice to have a separate DFU >>> custodian. That'd leverage some burden from me. I like that >>> idea. I wonder if it'd be nice to start building such bigger >>> net of custodians. >> >> So long as everyone involved plays nice, we have a maintainer of >> the code (Lukasz) and another user / developer of the code >> (Pantelis). I don't think we need to go full on custodian right >> now. Lukasz is reviewing and trying to understand what Pantelis >> is seeing since we're seeing some odd issues on the second >> platform to add DFU support. > > WFM, but it'd leverage burden from me. And I honestly dont > understand the DFU as much as Lukasz does. That's fine. Lean on maintainers as much as they're agreeable to. I'm sure (well, I hope and assume) Lukasz would like to ack anything DFU related that goes in and if you don't want to pull for u-boot-usb until he does, that's fine and good with me. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQyMbsAAoJENk4IS6UOR1W/nUP/05xGbixnO450kJyxMCQZGc2 0QHAy41jTqGnBKGLutZE0ged/lKxo2UwNbAklJc/EixILFLIjOaRpNlKARo7G4hH NHX8SXYgHVUY4R1fWgciH/gMO+lNAsLOP30peR0KtQyL6EBmC7fEUxjEPUKsCKWy RA8AOG9QBD88k1wt2GxEkuXlONpPO9/LTb39ZPrUgfo9iG8oTEcYWq98OfitWKvf Rd3q2XxUpu1UxUxh4ThPE1uj9V5l+d5eeTYismOcB/WvjAAJ0o6H26MDov1Z49TP 9ezB++NEzAoh5VO2WMBmruLBUBZkvl+XQLHCLgGy62Zvw5EYolYdQu0+2TYsNB17 kxWDdZEi0t+y+uZ3qSXcxnTta/yAwvv0LeE6mODA1h8Q717qlBSkCch2Nr3jwYU5 LbPvnAVHX+f1gslGmiL192uCpQ0YtNE+0McHSQ55/P9s+aZrOnlkZApLvAfKyQJr E9bufbgeey3JXa8O64mVNX8rDcvVPXftdP1Hqbrw42UkCK89KiskTjQ7PYO2yVpq Ge/JnJzNnYDtf3YCbM8iIM7rUo228ugG8d7Wd9t0ISimT3zU05KoNdOOIqiCsmAd FLyC9tjQqctic1kh2+KBBAaNy3rpKaDDb2LOpjYjaQsftDOUJ0zBxcCinh5GPI7n yYnG1XxwV1sqT1Fov49x =YfYD -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-10 19:26 ` Lukasz Majewski 2012-12-11 0:47 ` Marek Vasut @ 2012-12-11 11:02 ` Lukasz Majewski 2012-12-11 11:23 ` Pantelis Antoniou ` (2 more replies) 2012-12-11 11:18 ` Lukasz Majewski 2 siblings, 3 replies; 35+ messages in thread From: Lukasz Majewski @ 2012-12-11 11:02 UTC (permalink / raw) To: u-boot Hi Pantelis, > Tomorrow I will prepare output of USB Ellisys analizer on my side, so > we could get clue what is going on. Please find attached output from USB ellisys analizer. (It is possible to download WinXP based program to view logs without USB analizer box). What I see in the current implementation stalls on GetDescriptor (Class: 0x21),but afterwards transmission is performed. -- Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group -------------- next part -------------- A non-text attachment was scrubbed... Name: DFU_mainline_trats.tar Type: application/x-tar Size: 5478400 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121211/80c30953/attachment-0001.tar> ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-11 11:02 ` Lukasz Majewski @ 2012-12-11 11:23 ` Pantelis Antoniou 2012-12-11 11:28 ` Robert P. J. Day 2012-12-12 21:40 ` Marek Vasut 2 siblings, 0 replies; 35+ messages in thread From: Pantelis Antoniou @ 2012-12-11 11:23 UTC (permalink / raw) To: u-boot Hi Lukasz, I bet transmission is performed, but with the default settings of dfu. The DFU function descriptor is completely ignored. An easy way to verify it is to check if the DFU version of the device is the same one as the one stored in the descriptor. Same with the transmission block size. It might work, but only by accident. I sure hope I'll have time today to send my captures as well. Regards -- Pantelis On Dec 11, 2012, at 1:02 PM, Lukasz Majewski wrote: > Hi Pantelis, > >> Tomorrow I will prepare output of USB Ellisys analizer on my side, so >> we could get clue what is going on. > > Please find attached output from USB ellisys analizer. > > (It is possible to download WinXP based program to view logs without > USB analizer box). > > What I see in the current implementation stalls on GetDescriptor > (Class: 0x21),but afterwards transmission is performed. > > > > -- > Best regards, > > Lukasz Majewski > > Samsung Poland R&D Center | Linux Platform Group > <DFU_mainline_trats.tar> ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-11 11:02 ` Lukasz Majewski 2012-12-11 11:23 ` Pantelis Antoniou @ 2012-12-11 11:28 ` Robert P. J. Day 2012-12-12 21:42 ` Marek Vasut 2012-12-12 21:40 ` Marek Vasut 2 siblings, 1 reply; 35+ messages in thread From: Robert P. J. Day @ 2012-12-11 11:28 UTC (permalink / raw) To: u-boot On Tue, 11 Dec 2012, Lukasz Majewski wrote: > Hi Pantelis, > > > Tomorrow I will prepare output of USB Ellisys analizer on my side, so > > we could get clue what is going on. > > Please find attached output from USB ellisys analizer. is it really appropriate to post 8M of output to a mailing list? what's wrong with pastebin? rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-11 11:28 ` Robert P. J. Day @ 2012-12-12 21:42 ` Marek Vasut 0 siblings, 0 replies; 35+ messages in thread From: Marek Vasut @ 2012-12-12 21:42 UTC (permalink / raw) To: u-boot Dear Robert P. J. Day, > On Tue, 11 Dec 2012, Lukasz Majewski wrote: > > Hi Pantelis, > > > > > Tomorrow I will prepare output of USB Ellisys analizer on my side, so > > > we could get clue what is going on. > > > > Please find attached output from USB ellisys analizer. > > is it really appropriate to post 8M of output to a mailing > list? what's wrong with pastebin? :rageface: http://www.ietf.org/rfc/rfc1855.txt > rday Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-11 11:02 ` Lukasz Majewski 2012-12-11 11:23 ` Pantelis Antoniou 2012-12-11 11:28 ` Robert P. J. Day @ 2012-12-12 21:40 ` Marek Vasut 2 siblings, 0 replies; 35+ messages in thread From: Marek Vasut @ 2012-12-12 21:40 UTC (permalink / raw) To: u-boot Dear Lukasz Majewski, > Hi Pantelis, > > > Tomorrow I will prepare output of USB Ellisys analizer on my side, so > > we could get clue what is going on. > > Please find attached output from USB ellisys analizer. > > (It is possible to download WinXP based program to view logs without > USB analizer box). > > What I see in the current implementation stalls on GetDescriptor > (Class: 0x21),but afterwards transmission is performed. Or run u-boot in qemu and tunnel it through usbmon :p Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup 2012-12-10 19:26 ` Lukasz Majewski 2012-12-11 0:47 ` Marek Vasut 2012-12-11 11:02 ` Lukasz Majewski @ 2012-12-11 11:18 ` Lukasz Majewski 2 siblings, 0 replies; 35+ messages in thread From: Lukasz Majewski @ 2012-12-11 11:18 UTC (permalink / raw) To: u-boot Hi Lukasz, > Tomorrow I will prepare output of USB Ellisys analizer on my side, so > we could get clue what is going on. Since log itself waits for moderator approval, I will be more precise: 1. dfu-util version 0.1+svnexported 2. u-boot-denx master branch: SHA1: d987274e214cbfc7a56504fb3f0575fc6d2c587a -- Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 7/9] dfu: Properly zero out timeout value 2012-11-30 18:01 [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Pantelis Antoniou ` (5 preceding siblings ...) 2012-11-30 18:01 ` [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup Pantelis Antoniou @ 2012-11-30 18:01 ` Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 8/9] dfu: Add a partition type target Pantelis Antoniou ` (2 subsequent siblings) 9 siblings, 0 replies; 35+ messages in thread From: Pantelis Antoniou @ 2012-11-30 18:01 UTC (permalink / raw) To: u-boot Zero out timeout value; letting it filled with undefined values ends up with the dfu host hanging. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> --- drivers/usb/gadget/f_dfu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c index 6494f5e..c15585c 100644 --- a/drivers/usb/gadget/f_dfu.c +++ b/drivers/usb/gadget/f_dfu.c @@ -164,6 +164,9 @@ static void handle_getstatus(struct usb_request *req) /* send status response */ dstat->bStatus = f_dfu->dfu_status; + dstat->bwPollTimeout[0] = 0; + dstat->bwPollTimeout[1] = 0; + dstat->bwPollTimeout[2] = 0; dstat->bState = f_dfu->dfu_state; dstat->iString = 0; } -- 1.7.12 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 8/9] dfu: Add a partition type target 2012-11-30 18:01 [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Pantelis Antoniou ` (6 preceding siblings ...) 2012-11-30 18:01 ` [U-Boot] [PATCH v3 7/9] dfu: Properly zero out timeout value Pantelis Antoniou @ 2012-11-30 18:01 ` Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers Pantelis Antoniou 2012-12-01 5:32 ` [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Marek Vasut 9 siblings, 0 replies; 35+ messages in thread From: Pantelis Antoniou @ 2012-11-30 18:01 UTC (permalink / raw) To: u-boot Dealing with raw block numbers with the dfu is very annoying. Introduce a partition method. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> --- drivers/dfu/dfu_mmc.c | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c index 5d504df..083d745 100644 --- a/drivers/dfu/dfu_mmc.c +++ b/drivers/dfu/dfu_mmc.c @@ -21,6 +21,7 @@ #include <common.h> #include <malloc.h> +#include <errno.h> #include <dfu.h> enum dfu_mmc_op { @@ -153,6 +154,10 @@ int dfu_read_medium_mmc(struct dfu_entity *dfu, void *buf, long *len) int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *s) { + int dev, part; + struct mmc *mmc; + block_dev_desc_t *blk_dev; + disk_partition_t partinfo; char *st; dfu->dev_type = DFU_DEV_MMC; @@ -166,8 +171,34 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *s) dfu->layout = DFU_FS_FAT; } else if (!strcmp(st, "ext4")) { dfu->layout = DFU_FS_EXT4; + } else if (!strcmp(st, "part")) { + + dfu->layout = DFU_RAW_ADDR; + + dev = simple_strtoul(s, &s, 10); + s++; + part = simple_strtoul(s, &s, 10); + + mmc = find_mmc_device(dev); + if (mmc == NULL || mmc_init(mmc)) { + printf("%s: could not find mmc device #%d!\n", __func__, dev); + return -ENODEV; + } + + blk_dev = &mmc->block_dev; + if (get_partition_info(blk_dev, part, &partinfo) != 0) { + printf("%s: could not find partition #%d on mmc device #%d!\n", + __func__, part, dev); + return -ENODEV; + } + + dfu->data.mmc.lba_start = partinfo.start; + dfu->data.mmc.lba_size = partinfo.size; + dfu->data.mmc.lba_blk_size = partinfo.blksz; + } else { printf("%s: Memory layout (%s) not supported!\n", __func__, st); + return -ENODEV; } if (dfu->layout == DFU_FS_EXT4 || dfu->layout == DFU_FS_FAT) { -- 1.7.12 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers. 2012-11-30 18:01 [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Pantelis Antoniou ` (7 preceding siblings ...) 2012-11-30 18:01 ` [U-Boot] [PATCH v3 8/9] dfu: Add a partition type target Pantelis Antoniou @ 2012-11-30 18:01 ` Pantelis Antoniou 2013-02-12 20:51 ` Tom Rini 2012-12-01 5:32 ` [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Marek Vasut 9 siblings, 1 reply; 35+ messages in thread From: Pantelis Antoniou @ 2012-11-30 18:01 UTC (permalink / raw) To: u-boot We didn't support upload/download larger than available memory. This is pretty bad when you have to update your root filesystem for example. This patch removes the limitation (and the crashes when you transfered any file larger than 4MB). On top of that reduces the huge dfu buffer from 4MB to just 64K, which was over the top. The sequence number is a 16 bit counter; make sure we handle rollover correctly. This fixes the wrong transfers for large (> 256MB) images. Also utilize a variable to handle initialization, so that we don't rely on just the counter sent by the host. Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> --- drivers/dfu/dfu.c | 244 +++++++++++++++++++++++++++++++++++++++----------- drivers/dfu/dfu_mmc.c | 82 +++++++++++------ include/dfu.h | 21 ++++- 3 files changed, 264 insertions(+), 83 deletions(-) diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c index e8477fb..fb9b417 100644 --- a/drivers/dfu/dfu.c +++ b/drivers/dfu/dfu.c @@ -44,90 +44,228 @@ static int dfu_find_alt_num(const char *s) static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE) dfu_buf[DFU_DATA_BUF_SIZE]; +static int dfu_write_buffer_flush(struct dfu_entity *dfu) +{ + long w_size; + int ret; + + /* flush size? */ + w_size = dfu->i_buf - dfu->i_buf_start; + if (w_size == 0) + return 0; + + /* update CRC32 */ + dfu->crc = crc32(dfu->crc, dfu->i_buf_start, w_size); + + ret = dfu->write_medium(dfu, dfu->offset, dfu->i_buf_start, &w_size); + if (ret) + debug("%s: Write error!\n", __func__); + + /* point back */ + dfu->i_buf = dfu->i_buf_start; + + /* update offset */ + dfu->offset += w_size; + + puts("#"); + + return ret; +} + int dfu_write(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num) { - static unsigned char *i_buf; - static int i_blk_seq_num; - long w_size = 0; int ret = 0; + int tret; + + debug("%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x " + "offset: 0x%llx bufoffset: 0x%x\n", + __func__, dfu->name, buf, size, blk_seq_num, dfu->offset, + dfu->i_buf - dfu->i_buf_start); + + if (!dfu->inited) { + /* initial state */ + dfu->crc = 0; + dfu->offset = 0; + dfu->i_blk_seq_num = 0; + dfu->i_buf_start = dfu_buf; + dfu->i_buf_end = dfu_buf + sizeof(dfu_buf); + dfu->i_buf = dfu->i_buf_start; + + dfu->inited = 1; + } - debug("%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x i_buf: 0x%p\n", - __func__, dfu->name, buf, size, blk_seq_num, i_buf); + if (dfu->i_blk_seq_num != blk_seq_num) { + printf("%s: Wrong sequence number! [%d] [%d]\n", + __func__, dfu->i_blk_seq_num, blk_seq_num); + return -1; + } - if (blk_seq_num == 0) { - i_buf = dfu_buf; - i_blk_seq_num = 0; + /* DFU 1.1 standard says: + * The wBlockNum field is a block sequence number. It increments each + * time a block is transferred, wrapping to zero from 65,535. It is used + * to provide useful context to the DFU loader in the device." + * + * This means that it's a 16 bit counter that roll-overs at + * 0xffff -> 0x0000. By having a typical 4K transfer block + * we roll-over at exactly 256MB. Not very fun to debug. + * + * Handling rollover, and having an inited variable, + * makes things work. + */ + + /* handle rollover */ + dfu->i_blk_seq_num = (dfu->i_blk_seq_num + 1) & 0xffff; + + /* flush buffer if overflow */ + if ((dfu->i_buf + size) > dfu->i_buf_end) { + tret = dfu_write_buffer_flush(dfu); + if (ret == 0) + ret = tret; } - if (i_blk_seq_num++ != blk_seq_num) { - printf("%s: Wrong sequence number! [%d] [%d]\n", - __func__, i_blk_seq_num, blk_seq_num); + /* we should be in buffer now (if not then size too large) */ + if ((dfu->i_buf + size) > dfu->i_buf_end) { + printf("%s: Wrong size! [%d] [%d] - %d\n", + __func__, dfu->i_blk_seq_num, blk_seq_num, size); return -1; } - memcpy(i_buf, buf, size); - i_buf += size; + memcpy(dfu->i_buf, buf, size); + dfu->i_buf += size; + /* if end or if buffer full flush */ + if (size == 0 || (dfu->i_buf + size) > dfu->i_buf_end) { + tret = dfu_write_buffer_flush(dfu); + if (ret == 0) + ret = tret; + } + + /* end? */ if (size == 0) { - /* Integrity check (if needed) */ - debug("%s: %s %d [B] CRC32: 0x%x\n", __func__, dfu->name, - i_buf - dfu_buf, crc32(0, dfu_buf, i_buf - dfu_buf)); + debug("%s: DFU complete CRC32: 0x%x\n", __func__, dfu->crc); - w_size = i_buf - dfu_buf; - ret = dfu->write_medium(dfu, dfu_buf, &w_size); - if (ret) - debug("%s: Write error!\n", __func__); + printf("\nDownload complete (CRC32 0x%04x)\n", dfu->crc); + + /* clear everything */ + dfu->crc = 0; + dfu->offset = 0; + dfu->i_blk_seq_num = 0; + dfu->i_buf_start = dfu_buf; + dfu->i_buf_end = dfu_buf + sizeof(dfu_buf); + dfu->i_buf = dfu->i_buf_start; + + dfu->inited = 0; - i_blk_seq_num = 0; - i_buf = NULL; - return ret; } - return ret; + return ret = 0 ? size : ret; +} + +static int dfu_read_buffer_fill(struct dfu_entity *dfu, void *buf, int size) +{ + long chunk; + int ret, readn; + + readn = 0; + while (size > 0) { + + /* get chunk that can be read */ + chunk = min(size, dfu->b_left); + /* consume */ + if (chunk > 0) { + memcpy(buf, dfu->i_buf, chunk); + dfu->crc = crc32(dfu->crc, buf, chunk); + dfu->i_buf += chunk; + dfu->b_left -= chunk; + size -= chunk; + buf += chunk; + readn += chunk; + } + + /* all done */ + if (size > 0) { + /* no more to read */ + if (dfu->r_left == 0) + break; + + dfu->i_buf = dfu->i_buf_start; + dfu->b_left = dfu->i_buf_end - dfu->i_buf_start; + + /* got to read, but buffer is empty */ + if (dfu->b_left > dfu->r_left) + dfu->b_left = dfu->r_left; + ret = dfu->read_medium(dfu, dfu->offset, dfu->i_buf, + &dfu->b_left); + if (ret != 0) { + debug("%s: Read error!\n", __func__); + return ret; + } + dfu->offset += dfu->b_left; + dfu->r_left -= dfu->b_left; + + puts("#"); + } + } + + return readn; } int dfu_read(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num) { - static unsigned char *i_buf; - static int i_blk_seq_num; - static long r_size; - static u32 crc; int ret = 0; debug("%s: name: %s buf: 0x%p size: 0x%x p_num: 0x%x i_buf: 0x%p\n", - __func__, dfu->name, buf, size, blk_seq_num, i_buf); - - if (blk_seq_num == 0) { - i_buf = dfu_buf; - ret = dfu->read_medium(dfu, i_buf, &r_size); - debug("%s: %s %ld [B]\n", __func__, dfu->name, r_size); - i_blk_seq_num = 0; - /* Integrity check (if needed) */ - crc = crc32(0, dfu_buf, r_size); + __func__, dfu->name, buf, size, blk_seq_num, dfu->i_buf); + + if (!dfu->inited) { + ret = dfu->read_medium(dfu, 0, NULL, &dfu->r_left); + if (ret != 0) { + debug("%s: failed to get r_left\n", __func__); + return ret; + } + + debug("%s: %s %ld [B]\n", __func__, dfu->name, dfu->r_left); + + dfu->i_blk_seq_num = 0; + dfu->crc = 0; + dfu->offset = 0; + dfu->i_buf_start = dfu_buf; + dfu->i_buf_end = dfu_buf + sizeof(dfu_buf); + dfu->i_buf = dfu->i_buf_start; + dfu->b_left = 0; + + dfu->inited = 1; } - if (i_blk_seq_num++ != blk_seq_num) { + if (dfu->i_blk_seq_num != blk_seq_num) { printf("%s: Wrong sequence number! [%d] [%d]\n", - __func__, i_blk_seq_num, blk_seq_num); + __func__, dfu->i_blk_seq_num, blk_seq_num); return -1; } + /* handle rollover */ + dfu->i_blk_seq_num = (dfu->i_blk_seq_num + 1) & 0xffff; - if (r_size >= size) { - memcpy(buf, i_buf, size); - i_buf += size; - r_size -= size; - return size; - } else { - memcpy(buf, i_buf, r_size); - i_buf += r_size; - debug("%s: %s CRC32: 0x%x\n", __func__, dfu->name, crc); - puts("UPLOAD ... done\nCtrl+C to exit ...\n"); + ret = dfu_read_buffer_fill(dfu, buf, size); + if (ret < 0) { + printf("%s: Failed to fill buffer\n", __func__); + return -1; + } + + if (ret < size) { + debug("%s: %s CRC32: 0x%x\n", __func__, dfu->name, dfu->crc); + puts("\nUPLOAD ... done\nCtrl+C to exit ...\n"); - i_buf = NULL; - i_blk_seq_num = 0; - crc = 0; - return r_size; + dfu->i_blk_seq_num = 0; + dfu->crc = 0; + dfu->offset = 0; + dfu->i_buf_start = dfu_buf; + dfu->i_buf_end = dfu_buf + sizeof(dfu_buf); + dfu->i_buf = dfu->i_buf_start; + dfu->b_left = 0; + + dfu->inited = 0; } + return ret; } diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c index 083d745..29a2c2e 100644 --- a/drivers/dfu/dfu_mmc.c +++ b/drivers/dfu/dfu_mmc.c @@ -22,6 +22,7 @@ #include <common.h> #include <malloc.h> #include <errno.h> +#include <div64.h> #include <dfu.h> enum dfu_mmc_op { @@ -30,35 +31,48 @@ enum dfu_mmc_op { }; static int mmc_block_op(enum dfu_mmc_op op, struct dfu_entity *dfu, - void *buf, long *len) + u64 offset, void *buf, long *len) { char cmd_buf[DFU_CMD_BUF_SIZE]; + u32 blk_start, blk_count; - sprintf(cmd_buf, "mmc %s 0x%x %x %x", - op == DFU_OP_READ ? "read" : "write", - (unsigned int) buf, - dfu->data.mmc.lba_start, - dfu->data.mmc.lba_size); - - if (op == DFU_OP_READ) + /* if buf == NULL return total size of the area */ + if (buf == NULL) { *len = dfu->data.mmc.lba_blk_size * dfu->data.mmc.lba_size; + return 0; + } + + blk_start = dfu->data.mmc.lba_start + + (u32)lldiv(offset, dfu->data.mmc.lba_blk_size); + blk_count = *len / dfu->data.mmc.lba_blk_size; + if (blk_start + blk_count > + dfu->data.mmc.lba_start + dfu->data.mmc.lba_size) { + debug("%s: block_op out of bounds\n", __func__); + return -1; + } + + sprintf(cmd_buf, "mmc %s %p %x %x", + op == DFU_OP_READ ? "read" : "write", + buf, blk_start, blk_count); debug("%s: %s 0x%p\n", __func__, cmd_buf, cmd_buf); return run_command(cmd_buf, 0); } -static inline int mmc_block_write(struct dfu_entity *dfu, void *buf, long *len) +static inline int mmc_block_write(struct dfu_entity *dfu, + u64 offset, void *buf, long *len) { - return mmc_block_op(DFU_OP_WRITE, dfu, buf, len); + return mmc_block_op(DFU_OP_WRITE, dfu, offset, buf, len); } -static inline int mmc_block_read(struct dfu_entity *dfu, void *buf, long *len) +static inline int mmc_block_read(struct dfu_entity *dfu, + u64 offset, void *buf, long *len) { - return mmc_block_op(DFU_OP_READ, dfu, buf, len); + return mmc_block_op(DFU_OP_READ, dfu, offset, buf, len); } static int mmc_file_op(enum dfu_mmc_op op, struct dfu_entity *dfu, - void *buf, long *len) + u64 offset, void *buf, long *len) { char cmd_buf[DFU_CMD_BUF_SIZE]; char *str_env; @@ -66,12 +80,17 @@ static int mmc_file_op(enum dfu_mmc_op op, struct dfu_entity *dfu, switch (dfu->layout) { case DFU_FS_FAT: - sprintf(cmd_buf, "fat%s mmc %d:%d 0x%x %s %lx", + sprintf(cmd_buf, "fat%s mmc %d:%d 0x%x %s %lx %llx", op == DFU_OP_READ ? "load" : "write", dfu->data.mmc.dev, dfu->data.mmc.part, - (unsigned int) buf, dfu->name, *len); + (unsigned int) buf, dfu->name, *len, offset); break; case DFU_FS_EXT4: + if (offset != 0) { + debug("%s: Offset value %llx != 0 not supported!\n", + __func__, offset); + return -1; + } sprintf(cmd_buf, "ext4%s mmc %d:%d /%s 0x%x %ld", op == DFU_OP_READ ? "load" : "write", dfu->data.mmc.dev, dfu->data.mmc.part, @@ -80,6 +99,7 @@ static int mmc_file_op(enum dfu_mmc_op op, struct dfu_entity *dfu, default: printf("%s: Layout (%s) not (yet) supported!\n", __func__, dfu_get_layout(dfu->layout)); + return -1; } debug("%s: %s 0x%p\n", __func__, cmd_buf, cmd_buf); @@ -102,27 +122,30 @@ static int mmc_file_op(enum dfu_mmc_op op, struct dfu_entity *dfu, return ret; } -static inline int mmc_file_write(struct dfu_entity *dfu, void *buf, long *len) +static inline int mmc_file_write(struct dfu_entity *dfu, + u64 offset, void *buf, long *len) { - return mmc_file_op(DFU_OP_WRITE, dfu, buf, len); + return mmc_file_op(DFU_OP_WRITE, dfu, offset, buf, len); } -static inline int mmc_file_read(struct dfu_entity *dfu, void *buf, long *len) +static inline int mmc_file_read(struct dfu_entity *dfu, + u64 offset, void *buf, long *len) { - return mmc_file_op(DFU_OP_READ, dfu, buf, len); + return mmc_file_op(DFU_OP_READ, dfu, offset, buf, len); } -int dfu_write_medium_mmc(struct dfu_entity *dfu, void *buf, long *len) +int dfu_write_medium_mmc(struct dfu_entity *dfu, + u64 offset, void *buf, long *len) { int ret = -1; switch (dfu->layout) { case DFU_RAW_ADDR: - ret = mmc_block_write(dfu, buf, len); + ret = mmc_block_write(dfu, offset, buf, len); break; case DFU_FS_FAT: case DFU_FS_EXT4: - ret = mmc_file_write(dfu, buf, len); + ret = mmc_file_write(dfu, offset, buf, len); break; default: printf("%s: Layout (%s) not (yet) supported!\n", __func__, @@ -132,17 +155,17 @@ int dfu_write_medium_mmc(struct dfu_entity *dfu, void *buf, long *len) return ret; } -int dfu_read_medium_mmc(struct dfu_entity *dfu, void *buf, long *len) +int dfu_read_medium_mmc(struct dfu_entity *dfu, u64 offset, void *buf, long *len) { int ret = -1; switch (dfu->layout) { case DFU_RAW_ADDR: - ret = mmc_block_read(dfu, buf, len); + ret = mmc_block_read(dfu, offset, buf, len); break; case DFU_FS_FAT: case DFU_FS_EXT4: - ret = mmc_file_read(dfu, buf, len); + ret = mmc_file_read(dfu, offset, buf, len); break; default: printf("%s: Layout (%s) not (yet) supported!\n", __func__, @@ -181,13 +204,15 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *s) mmc = find_mmc_device(dev); if (mmc == NULL || mmc_init(mmc)) { - printf("%s: could not find mmc device #%d!\n", __func__, dev); + printf("%s: could not find mmc device #%d!\n", + __func__, dev); return -ENODEV; } blk_dev = &mmc->block_dev; if (get_partition_info(blk_dev, part, &partinfo) != 0) { - printf("%s: could not find partition #%d on mmc device #%d!\n", + printf("%s: could not find partition #%d " + "on mmc device #%d!\n", __func__, part, dev); return -ENODEV; } @@ -209,5 +234,8 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *s) dfu->read_medium = dfu_read_medium_mmc; dfu->write_medium = dfu_write_medium_mmc; + /* initial state */ + dfu->inited = 0; + return 0; } diff --git a/include/dfu.h b/include/dfu.h index 5350d79..2847ef8 100644 --- a/include/dfu.h +++ b/include/dfu.h @@ -59,7 +59,7 @@ static inline unsigned int get_mmc_blk_size(int dev) #define DFU_NAME_SIZE 32 #define DFU_CMD_BUF_SIZE 128 -#define DFU_DATA_BUF_SIZE (1024*1024*4) /* 4 MiB */ +#define DFU_DATA_BUF_SIZE (1024*64) /* 64 KB (the huge buffer is overkill) */ struct dfu_entity { char name[DFU_NAME_SIZE]; @@ -73,10 +73,25 @@ struct dfu_entity { struct mmc_internal_data mmc; } data; - int (*read_medium)(struct dfu_entity *dfu, void *buf, long *len); - int (*write_medium)(struct dfu_entity *dfu, void *buf, long *len); + int (*read_medium)(struct dfu_entity *dfu, + u64 offset, void *buf, long *len); + + int (*write_medium)(struct dfu_entity *dfu, + u64 offset, void *buf, long *len); struct list_head list; + + /* on the fly state */ + u32 crc; + u64 offset; + int i_blk_seq_num; + u8 *i_buf; + u8 *i_buf_start; + u8 *i_buf_end; + long r_left; + long b_left; + + unsigned int inited : 1; }; int dfu_config_entities(char *s, char *interface, int num); -- 1.7.12 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers. 2012-11-30 18:01 ` [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers Pantelis Antoniou @ 2013-02-12 20:51 ` Tom Rini 2013-02-18 10:01 ` Lukasz Majewski 0 siblings, 1 reply; 35+ messages in thread From: Tom Rini @ 2013-02-12 20:51 UTC (permalink / raw) To: u-boot On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote: > We didn't support upload/download larger than available memory. > This is pretty bad when you have to update your root filesystem for > example. > > This patch removes the limitation (and the crashes when you transfered > any file larger than 4MB). > On top of that reduces the huge dfu buffer from 4MB to just 64K, which > was over the top. > > The sequence number is a 16 bit counter; make sure we > handle rollover correctly. This fixes the wrong transfers for > large (> 256MB) images. > > Also utilize a variable to handle initialization, so that we > don't rely on just the counter sent by the host. > > Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> To be clear, patches 1-8 are good and we should take, but this one means we can't use FAT/EXT* partitions without more work. I would suggest that we set this part aside for a moment and perhaps limit transfers that are larget than RAM to RAW only where we can write in chunks today. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130212/5e95fa9a/attachment.pgp> ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers. 2013-02-12 20:51 ` Tom Rini @ 2013-02-18 10:01 ` Lukasz Majewski 2013-02-18 12:38 ` Marek Vasut ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: Lukasz Majewski @ 2013-02-18 10:01 UTC (permalink / raw) To: u-boot Hi Tom, > On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote: > > > We didn't support upload/download larger than available memory. > > This is pretty bad when you have to update your root filesystem for > > example. > > > > This patch removes the limitation (and the crashes when you > > transfered any file larger than 4MB). > > On top of that reduces the huge dfu buffer from 4MB to just 64K, > > which was over the top. > > > > The sequence number is a 16 bit counter; make sure we > > handle rollover correctly. This fixes the wrong transfers for > > large (> 256MB) images. > > > > Also utilize a variable to handle initialization, so that we > > don't rely on just the counter sent by the host. > > > > Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> > > To be clear, patches 1-8 are good and we should take, but this one > means we can't use FAT/EXT* partitions without more work. I would > suggest that we set this part aside for a moment and perhaps limit > transfers that are larget than RAM to RAW only where we can write in > chunks today. > As fair as I remember, some additional work needs to be done with composite.c file (to remove nasty #ifdefs). There was a problem with newer version of dfu-utils (new handling of descriptors). It is on top of my queue, but I'm currently buried with other work and need to postpone this. However it is still on the back of my head and I push myself to fix this. -- Best regards, Lukasz Majewski Samsung R&D Poland (SRPOL) | Linux Platform Group ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers. 2013-02-18 10:01 ` Lukasz Majewski @ 2013-02-18 12:38 ` Marek Vasut 2013-02-18 13:51 ` Tom Rini 2013-02-18 21:08 ` Tom Rini 2 siblings, 0 replies; 35+ messages in thread From: Marek Vasut @ 2013-02-18 12:38 UTC (permalink / raw) To: u-boot Dear Lukasz Majewski, > Hi Tom, > > > On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote: > > > We didn't support upload/download larger than available memory. > > > This is pretty bad when you have to update your root filesystem for > > > example. > > > > > > This patch removes the limitation (and the crashes when you > > > transfered any file larger than 4MB). > > > On top of that reduces the huge dfu buffer from 4MB to just 64K, > > > which was over the top. > > > > > > The sequence number is a 16 bit counter; make sure we > > > handle rollover correctly. This fixes the wrong transfers for > > > large (> 256MB) images. > > > > > > Also utilize a variable to handle initialization, so that we > > > don't rely on just the counter sent by the host. > > > > > > Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> > > > > To be clear, patches 1-8 are good and we should take, but this one > > means we can't use FAT/EXT* partitions without more work. I would > > suggest that we set this part aside for a moment and perhaps limit > > transfers that are larget than RAM to RAW only where we can write in > > chunks today. > > As fair as I remember, some additional work needs to be done with > composite.c file (to remove nasty #ifdefs). There was a problem with > newer version of dfu-utils (new handling of descriptors). > > It is on top of my queue, but I'm currently buried with other work and > need to postpone this. > > However it is still on the back of my head and I push myself to fix > this. Guys, can you just tell me what I should drop from u-boot-usb to submit a pullRQ with the rest ? Otherwise I'll drop the whole DFU stuff and be done with it. Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers. 2013-02-18 10:01 ` Lukasz Majewski 2013-02-18 12:38 ` Marek Vasut @ 2013-02-18 13:51 ` Tom Rini 2013-02-18 21:08 ` Tom Rini 2 siblings, 0 replies; 35+ messages in thread From: Tom Rini @ 2013-02-18 13:51 UTC (permalink / raw) To: u-boot -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/18/2013 05:01 AM, Lukasz Majewski wrote: > Hi Tom, > >> On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou >> wrote: >> >>> We didn't support upload/download larger than available >>> memory. This is pretty bad when you have to update your root >>> filesystem for example. >>> >>> This patch removes the limitation (and the crashes when you >>> transfered any file larger than 4MB). On top of that reduces >>> the huge dfu buffer from 4MB to just 64K, which was over the >>> top. >>> >>> The sequence number is a 16 bit counter; make sure we handle >>> rollover correctly. This fixes the wrong transfers for large (> >>> 256MB) images. >>> >>> Also utilize a variable to handle initialization, so that we >>> don't rely on just the counter sent by the host. >>> >>> Signed-off-by: Pantelis Antoniou >>> <panto@antoniou-consulting.com> >> >> To be clear, patches 1-8 are good and we should take, but this >> one means we can't use FAT/EXT* partitions without more work. I >> would suggest that we set this part aside for a moment and >> perhaps limit transfers that are larget than RAM to RAW only >> where we can write in chunks today. >> > > As fair as I remember, some additional work needs to be done with > composite.c file (to remove nasty #ifdefs). There was a problem > with newer version of dfu-utils (new handling of descriptors). I thought it ended up being resolved. I'll have to re-read the thread again I guess. - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIjHWAAoJENk4IS6UOR1WEs0P/07uTOJRh+8hBgnpcXwBZ8zD keEtN8vHs3JYOjW1k6styAFNGXy+PBhOJNOIx6ClsdTvCRU8FtGh09SZUAYBrZEj 5WbfqGaeFWY9bpgAhwsNRMXD3mcHq3EGvRm0Ga+ep/EDFd+lgswvfx9EtgxkOjy5 MM0G4BnjwJxWM4DW2Wkk/rXI7Xy8jpVn3abUPLva4iY8X5L6ez9GXp/VNv6nCoNI i+LuGXEnv7BsO9g+x5pvYlnQeMC5BPC7vKNMq9dj8o6MZ/Q7jCQkqz85GIqyDTta UByzr24G4xK5m7V0iFSlV7fnRHjcg7q+uAB6u2YSibssyibIuLoJA2VdiGZqp8oH OUBQ3L2v84QHhcKTQm/yqcQ4FWHaHQ369v4QwnON29yFqtb7Z/M3GEKCqPbPIlge eg+Bb8fymdjELQT4Bo0+EkydlvaQOhkSjxBlVa9GTkRyoPxpE7RNY5lgciseVZO4 hKG/Xfnce7fpQNoE8fJCWRslQp3sOiDE65gFRzNJN/15i+my+xYmN5HiNPWhcgmI 2EVJGx9/LXqZ6yGZh8bQCC3yvNnshG+cm4qAj58ytkLjVSVnsd7yxFYbexUTEJ0q YwOmE/72cgL/3IzpRUmh4o5G+uFJqhFx7zndMQyItdTN09mhZu7dCUtgud66A1Qg wUiQkeF4sWubUMIpYUvz =L9X2 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers. 2013-02-18 10:01 ` Lukasz Majewski 2013-02-18 12:38 ` Marek Vasut 2013-02-18 13:51 ` Tom Rini @ 2013-02-18 21:08 ` Tom Rini 2013-02-20 7:17 ` Lukasz Majewski 2 siblings, 1 reply; 35+ messages in thread From: Tom Rini @ 2013-02-18 21:08 UTC (permalink / raw) To: u-boot On Mon, Feb 18, 2013 at 11:01:42AM +0100, Lukasz Majewski wrote: > Hi Tom, > > > On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote: > > > > > We didn't support upload/download larger than available memory. > > > This is pretty bad when you have to update your root filesystem for > > > example. > > > > > > This patch removes the limitation (and the crashes when you > > > transfered any file larger than 4MB). > > > On top of that reduces the huge dfu buffer from 4MB to just 64K, > > > which was over the top. > > > > > > The sequence number is a 16 bit counter; make sure we > > > handle rollover correctly. This fixes the wrong transfers for > > > large (> 256MB) images. > > > > > > Also utilize a variable to handle initialization, so that we > > > don't rely on just the counter sent by the host. > > > > > > Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> > > > > To be clear, patches 1-8 are good and we should take, but this one > > means we can't use FAT/EXT* partitions without more work. I would > > suggest that we set this part aside for a moment and perhaps limit > > transfers that are larget than RAM to RAW only where we can write in > > chunks today. > > > > As fair as I remember, some additional work needs to be done with > composite.c file (to remove nasty #ifdefs). There was a problem with > newer version of dfu-utils (new handling of descriptors). I see you and Pantelis talking about if some changes were really needed in composite.c or not, but nothing about dfu-utils. Were you objecting to the composite.c changes because you didn't need them, or because they in turn broke trats (can I get one of these somewhere?) The only other unresolved thing was about board_usb_init() which I think was settled on trats needing to change behavior. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130218/f5452add/attachment.pgp> ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers. 2013-02-18 21:08 ` Tom Rini @ 2013-02-20 7:17 ` Lukasz Majewski 0 siblings, 0 replies; 35+ messages in thread From: Lukasz Majewski @ 2013-02-20 7:17 UTC (permalink / raw) To: u-boot Hi Tom, First of all, sorry for late reply. > On Mon, Feb 18, 2013 at 11:01:42AM +0100, Lukasz Majewski wrote: > > Hi Tom, > > > > > On Fri, Nov 30, 2012 at 08:01:12PM +0200, Pantelis Antoniou wrote: > > > > > > > We didn't support upload/download larger than available memory. > > > > This is pretty bad when you have to update your root filesystem > > > > for example. > > > > > > > > This patch removes the limitation (and the crashes when you > > > > transfered any file larger than 4MB). > > > > On top of that reduces the huge dfu buffer from 4MB to just 64K, > > > > which was over the top. > > > > > > > > The sequence number is a 16 bit counter; make sure we > > > > handle rollover correctly. This fixes the wrong transfers for > > > > large (> 256MB) images. > > > > > > > > Also utilize a variable to handle initialization, so that we > > > > don't rely on just the counter sent by the host. > > > > > > > > Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com> > > > > > > To be clear, patches 1-8 are good and we should take, but this one > > > means we can't use FAT/EXT* partitions without more work. I would > > > suggest that we set this part aside for a moment and perhaps limit > > > transfers that are larget than RAM to RAW only where we can write > > > in chunks today. > > > > > > > As fair as I remember, some additional work needs to be done with > > composite.c file (to remove nasty #ifdefs). There was a problem with > > newer version of dfu-utils (new handling of descriptors). > > I see you and Pantelis talking about if some changes were really > needed in composite.c or not, but nothing about dfu-utils. Changes in composite.c (adding some #ifdefs) were made because dfu-util developers made the significant change in descriptors handling between dfu-utils ver. 0.1 (which I've been using on my antic/test machine debian) and the newest dfu-utils (which Pantelis was using, and which is now available on recent debian). To be honest the current DFU code (v2013.01) works with the dfu-utils ver 0.1 (the old one). It breaks with new one. > Were you > objecting to the composite.c changes because you didn't need them, or > because they in turn broke trats (can I get one of these somewhere?) I'm objecting to adding a "quick hack style" #ifdefs to generic composite.c code. As fair as I remember this corrected code works with DFU, but I'd need to check if those composite.c changes will not break the UMS patches posted recently. Regarding TRATS: It is an official Tizen development board (mobile phone): http://www.youtube.com/watch?v=ya7ucT1wzOA It was distributed on some fair show, but I cannot tell how to obtain one. > The only other unresolved thing was about board_usb_init() which I > think was settled on trats needing to change behavior. As fair as I remember trats follows u-boot policy to enable things only when they are really needed. But I will not be stubborn here. On the end I might end up with a weak function (or enabling USB by default). I think, that this is a minor issue when compared to composite.c My proposition: - Now we have middle of Feb, we can add Pantelis Patches, UMS patches to u-boot tree (from Marek's USB tree) and fix conflicts up till v2013.03 release. I can point two big sets of patches (related only to Samsung boards) floating around without a common "base": Pantelis DFU work and UMS support patches. - I plan to work on composite/DFU (and potential UMS problems) at next week (up Friday I'm totally buried with other work) -- Best regards, Lukasz Majewski Samsung R&D Poland (SRPOL) | Linux Platform Group ^ permalink raw reply [flat|nested] 35+ messages in thread
* [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes 2012-11-30 18:01 [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Pantelis Antoniou ` (8 preceding siblings ...) 2012-11-30 18:01 ` [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers Pantelis Antoniou @ 2012-12-01 5:32 ` Marek Vasut 9 siblings, 0 replies; 35+ messages in thread From: Marek Vasut @ 2012-12-01 5:32 UTC (permalink / raw) To: u-boot Dear Pantelis Antoniou, > Third take of USB + DFU updates. > > Changelog for the pendants: > > changes from v2: > * Handle large transfers properly take #2 > * Different method of avoid double linking of > usb gadget & usb ether. > > changes from v1: > * Properly terminate terminate string list. > * Handle large transfers properly take #1 [...] I applied all but 1/9, that needs proper fixing. Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2013-02-20 7:17 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-11-30 18:01 [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 1/9] usb: Fix bug when both DFU & ETHER are defined Pantelis Antoniou 2012-12-01 5:30 ` Marek Vasut 2012-12-03 10:10 ` Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 2/9] g_dnl: Issue connect/disconnect as appropriate Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 3/9] g_dnl: Properly terminate string list Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 4/9] dfu: Only perform DFU board_usb_init() for TRATS Pantelis Antoniou 2012-12-01 5:31 ` Marek Vasut 2012-11-30 18:01 ` [U-Boot] [PATCH v3 5/9] dfu: Fix crash when wrong number of arguments given Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 6/9] dfu: Send correct DFU response from composite_setup Pantelis Antoniou 2012-12-10 17:11 ` Lukasz Majewski 2012-12-10 18:21 ` Pantelis Antoniou 2012-12-10 19:26 ` Lukasz Majewski 2012-12-11 0:47 ` Marek Vasut 2012-12-11 8:40 ` Lukasz Majewski 2012-12-11 10:47 ` Wolfgang Denk 2012-12-11 13:44 ` Tom Rini 2012-12-12 17:55 ` Marek Vasut 2012-12-12 18:03 ` Tom Rini 2012-12-11 11:02 ` Lukasz Majewski 2012-12-11 11:23 ` Pantelis Antoniou 2012-12-11 11:28 ` Robert P. J. Day 2012-12-12 21:42 ` Marek Vasut 2012-12-12 21:40 ` Marek Vasut 2012-12-11 11:18 ` Lukasz Majewski 2012-11-30 18:01 ` [U-Boot] [PATCH v3 7/9] dfu: Properly zero out timeout value Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 8/9] dfu: Add a partition type target Pantelis Antoniou 2012-11-30 18:01 ` [U-Boot] [PATCH v3 9/9] dfu: Support larger than memory transfers Pantelis Antoniou 2013-02-12 20:51 ` Tom Rini 2013-02-18 10:01 ` Lukasz Majewski 2013-02-18 12:38 ` Marek Vasut 2013-02-18 13:51 ` Tom Rini 2013-02-18 21:08 ` Tom Rini 2013-02-20 7:17 ` Lukasz Majewski 2012-12-01 5:32 ` [U-Boot] [PATCH v3 0/9] USB: Gadget & DFU related fixes Marek Vasut
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.