dfu:usb: Composite USB download gadget with DFU function
cover dfu:usb: Composite USB download gadget with DFU function
Those patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
A separate DFU back-end and front-end have been added.
Back-end is placed at ./drivers/dfu directory. The front-end is implemented as USB function.
The back-end is written in a generic manner with storage device specific code separated (eMMC).
DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_standard
Example usage:
u-boot side: dfu mmc 0
PC: dfu-util -U IMAGE.bin -a uImage (for upload)
dfu-util -D uImage -a uImage (download)
To list the alt settings:
dfu mmc 0 list
Test HW:
Exynos4210 Trats board
Lukasz Majewski (7):
dfu:usb: Support for g_dnl composite download gadget. dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
dfu: DFU backend implementation
dfu: MMC specific routines for DFU operation
dfu:cmd: Support for DFU u-boot command
arm:trats: Support for USB UDC driver at TRATS board. arm:trats: Enable g_dnl composite USB gadget with embedded DFU
function on TRATS
Makefile | 1 + board/samsung/trats/trats.c | 9 + common/Makefile | 1 + common/cmd_dfu.c | 81 ++++++ drivers/dfu/Makefile | 44 +++ drivers/dfu/dfu.c | 259 +++++++++++++++++ drivers/dfu/dfu_mmc.c | 126 ++++++++ drivers/usb/gadget/Makefile | 2 + drivers/usb/gadget/f_dfu.c | 666 +++++++++++++++++++++++++++++++++++++++++++ drivers/usb/gadget/f_dfu.h | 100 +++++++ drivers/usb/gadget/g_dnl.c | 235 +++++++++++++++ include/configs/trats.h | 19 ++- include/dfu.h | 99 +++++++ include/g_dnl.h | 33 +++ 14 files changed, 1674 insertions(+), 1 deletions(-) create mode 100644 common/cmd_dfu.c create mode 100644 drivers/dfu/Makefile create mode 100644 drivers/dfu/dfu.c create mode 100644 drivers/dfu/dfu_mmc.c create mode 100644 drivers/usb/gadget/f_dfu.c create mode 100644 drivers/usb/gadget/f_dfu.h create mode 100644 drivers/usb/gadget/g_dnl.c create mode 100644 include/dfu.h create mode 100644 include/g_dnl.h
Signature · 1 line
1.7.2.3
PATCH 1/7 dfu:usb: Support for g_dnl composite download gadget.
Composite USB download gadget support (g_dnl) for download functions. This code works on top of composite gadget.
--- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/g_dnl.c | 235 +++++++++++++++++++++++++++++++++++++++++++ include/g_dnl.h | 33 ++++++ 3 files changed, 269 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/g_dnl.c create mode 100644 include/g_dnl.h
drivers/usb/gadget/Makefile +1 -0
@@ -29,6 +29,7 @@ LIB := $(obj)libusb_gadget.o 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 endif ifdef CONFIG_USB_ETHER COBJS-y += ether.o epautoconf.o config.o usbstring.o
drivers/usb/gadget/g_dnl.c new file +235 -0
235 lines not on this page · raw message
include/g_dnl.h new file +33 -0
@@ -0,0 +1,33 @@ +/* +* Copyright (C) 2012 Samsung Electronics +* Lukasz Majewski <[email protected]> +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License as +* published by the Free Software Foundation; either version 2 of +* the License, or (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, +* MA 02111-1307 USA +*/ + +#ifndef __G_DOWNLOAD_H_ +#define __G_DOWNLOAD_H_ + +#include <linux/usb/ch9.h> +#include <usbdescriptors.h> +#include <linux/usb/gadget.h> + +int g_dnl_init (char *s); +void g_dnl_cleanup (void ); + +/* USB initialization declaration - board specific*/ +void board_usb_init (void ); +#endif /* __G_DOWNLOAD_H_ */
Signature · 1 line
1.7.2.3
PATCH 1/7 dfu:usb: Support for g_dnl composite download gadget.
Dear Lukasz Majewski,
Quoted 63 lines
Composite USB download gadget support (
g_dnl) for download functions. This code works on top of composite gadget.Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>--- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/g_dnl.c | 235 +++++++++++++++++++++++++++++++++++++++++++ include/g_dnl.h | 33 ++++++ 3 files changed, 269 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/g_dnl.c create mode 100644 include/g_dnl.hdrivers/usb/gadget/Makefile +1
-0@@ -29,6 +29,7 @@ LIB := $(obj)libusb_gadget.o 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 endif ifdef CONFIG_USB_ETHER COBJS-y += ether.o epautoconf.o config.o usbstring.odrivers/usb/gadget/g_dnl.c new file +19
-0@@ -0,0 +1,235 @@ +/* +* g_dnl.c -- USB Downloader Gadget +* +* Copyright (C) 2012 Samsung Electronics +* Lukasz Majewski <[email protected]> +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation; either version 2 of the License, or +* (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */
drivers/usb/gadget/g_dnl.c new file +10
-0+ +#include <errno.h> +#include <common.h> +#include <malloc.h> +#include <linux/usb/ch9.h> +#include <usbdescriptors.h> +#include <linux/usb/gadget.h> + +#include <mmc.h> +#include <part.h>
drivers/usb/gadget/g_dnl.c line 40
Quoted 10 lines
drivers/usb/gadget/g_dnl.c new file +10
-0+ +#include <g_dnl.h> +#include "f_dfu.h" + +#include "gadget_chips.h" +#include "composite.c" + +/* Samsung's IDs */ +#define DRIVER_VENDOR_NUM 0x04E8 +#define DRIVER_PRODUCT_NUM 0x6601
Is it samsung specific? Or can we use some USB IDs that are not bound to samsung?
drivers/usb/gadget/g_dnl.c line 51
Quoted 10 lines
drivers/usb/gadget/g_dnl.c new file +10
-0+#define STRING_MANUFACTURER 25 +#define STRING_PRODUCT 2 +#define STRING_USBDOWN 2 +#define CONFIG_USBDOWNLOADER 2 + +#define DRIVER_VERSION "usb_dnl 2.0" + +static const char shortname[] ="usb_dnl_" ; +static const char product[] ="SLP USB download gadget" ; +static const char manufacturer[] ="Samsung" ;
DITTO?
Quoted 42 lines
drivers/usb/gadget/g_dnl.c new file +42
-0+ +static struct usb_device_descriptor device_desc = { + .bLength =sizeof device_desc, + .bDescriptorType =USB_DT_DEVICE , + + .bcdUSB =__constant_cpu_to_le16 (0x0200 ), + .bDeviceClass =USB_CLASS_COMM , + .bDeviceSubClass =0x02 ,/*0x02:CDC-modem , 0x00:CDC-serial*/ + + .idVendor =__constant_cpu_to_le16 (DRIVER_VENDOR_NUM ), + .idProduct =__constant_cpu_to_le16 (DRIVER_PRODUCT_NUM ), + .iProduct =STRING_PRODUCT , + .bNumConfigurations =1 , +}; + +static const struct usb_descriptor_header *otg_desc[] = { + (struct usb_descriptor_header *) &(struct usb_otg_descriptor ){ + .bLength =sizeof (struct usb_otg_descriptor ), + .bDescriptorType =USB_DT_OTG , + .bmAttributes =USB_OTG_SRP , + }, +NULL , +}; + +/* static strings, in UTF-8 */ +static struct usb_string odin_string_defs[] = { + {0 , manufacturer, }, + {1 , product, }, +}; + +static struct usb_gadget_strings odin_string_tab = { + .language =0x0409 ,/* en-us */ + .strings = odin_string_defs, +}; + +static struct usb_gadget_strings *g_dnl_composite_strings[] = { + &odin_string_tab, +NULL , +}; + +static int g_dnl_unbind (struct usb_composite_dev *cdev) +{
drivers/usb/gadget/g_dnl.c line 103
Quoted 10 lines
drivers/usb/gadget/g_dnl.c new file +10
-0+debug ("%s\n" , __func__); +return 0 ; +} + +static int g_dnl_do_config (struct usb_configuration *c) +{ +int ret =-1 ; +char *s = (char *) c->cdev->driver->name; + +debug ("%s: c: 0x%p cdev: 0x%p\n" , __func__, c, c->cdev);
Can you elaborate in that debug message more? It's not really useful ;-)
drivers/usb/gadget/g_dnl.c line 113
Quoted 9 lines
drivers/usb/gadget/g_dnl.c new file +9
-0+if (gadget_is_otg (c->cdev->gadget)) { + c->descriptors = otg_desc; + c->bmAttributes |=USB_CONFIG_ATT_WAKEUP ; + } + +printf ("GADGET DRIVER: %s\n" , s); + +if (!strcmp (s,"usb_dnl_dfu" )) + ret =dfu_add (c);
And if this fails, we should set ret= as well, no?
Quoted 36 lines
drivers/usb/gadget/g_dnl.c new file +36
-0+ +return ret; +} + +static int g_dnl_config_register (struct usb_composite_dev *cdev) +{ +debug ("%s:\n" , __func__); +static struct usb_configuration config = { + .label ="usb_dnload" , + .bmAttributes =USB_CONFIG_ATT_ONE |USB_CONFIG_ATT_SELFPOWER , + .bConfigurationValue =CONFIG_USBDOWNLOADER , + .iConfiguration =STRING_USBDOWN , + + .bind = g_dnl_do_config, + }; + +return usb_add_config (cdev, &config); +} + +static int g_dnl_bind (struct usb_composite_dev *cdev) +{ +int gcnum; +int id, ret; +struct usb_gadget *gadget = cdev->gadget; + +debug ("%s: gadget: 0x%p cdev: 0x%p\n" , __func__, gadget, cdev); + + id =usb_string_id (cdev); + +if (id <0 ) +return id; + odin_string_defs[0 ].id = id; + device_desc.iManufacturer = id; + + id =usb_string_id (cdev); +if (id <0 )
drivers/usb/gadget/g_dnl.c line 159
Quoted 10 lines
drivers/usb/gadget/g_dnl.c new file +10
-0+return id; + + odin_string_defs[1 ].id = id; + device_desc.iProduct = id; + + ret =g_dnl_config_register (cdev); +if (ret) + goto error; + +
Two newlines
Quoted 20 lines
drivers/usb/gadget/g_dnl.c new file +20
-0+ gcnum =usb_gadget_controller_number (gadget); + +debug ("gcnum: %d\n" , gcnum); +if (gcnum >=0 ) + device_desc.bcdDevice =cpu_to_le16 (0x0200 + gcnum); +else { +debug ("%s: controller '%s' not recognized\n" , + shortname, gadget->name); + device_desc.bcdDevice =__constant_cpu_to_le16 (0x9999 ); + } + +return 0 ; + + error: +g_dnl_unbind (cdev); +return -ENOMEM ; +} + +static void g_dnl_suspend (struct usb_composite_dev *cdev) +{
drivers/usb/gadget/g_dnl.c line 189
Quoted 10 lines
drivers/usb/gadget/g_dnl.c new file +10
-0+if (cdev->gadget->speed ==USB_SPEED_UNKNOWN ) +return ; + +debug ("suspend\n" ); +} + +static void g_dnl_resume (struct usb_composite_dev *cdev) +{ +debug ("resume\n" ); +}
Maybe you should check if suspend/resume are set at all. Then you won't need the above stubs.
Quoted 7 lines
drivers/usb/gadget/g_dnl.c new file +7
-0+static struct usb_composite_driver g_dnl_driver = { + .name =NULL , + .dev = &device_desc, + .strings = g_dnl_composite_strings, + + .bind = g_dnl_bind, + .unbind = g_dnl_unbind,
drivers/usb/gadget/g_dnl.c line 207
Quoted 10 lines
drivers/usb/gadget/g_dnl.c new file +10
-0+ + .suspend = g_dnl_suspend, + .resume = g_dnl_resume, +}; + +int g_dnl_init (char *s) +{ +int ret; +static char str[16 ]; +
Why use '\0' if you can just use 0 ?
Quoted 8 lines
drivers/usb/gadget/g_dnl.c new file +8
-0+memset (str,'\0' ,sizeof (str)); + +strncpy (str, shortname,sizeof (shortname)); + +if (!strncmp (s,"dfu" ,sizeof (s))) { +strncat (str, s,sizeof (str)); + }else { +printf ("%s: unknown command: %s\n" , __func__, s);
drivers/usb/gadget/g_dnl.c line 225
Quoted 10 lines
drivers/usb/gadget/g_dnl.c new file +10
-0+return -EINVAL ; + } + + g_dnl_driver.name = str; + +debug ("%s: g_dnl_driver.name: %s\n" , __func__, g_dnl_driver.name); + ret =usb_composite_register (&g_dnl_driver); + +if (ret) { +printf ("%s: failed!, error:%d " , __func__, ret);
Missing newline in printf() (...error:%d ").
Quoted 49 lines
drivers/usb/gadget/g_dnl.c new file +10
-0+return ret; + } + +return 0 ; +} + +void g_dnl_cleanup (void ) +{ +usb_composite_unregister (&g_dnl_driver); +}include/g_dnl.h new file +33
-0@@ -0,0 +1,33 @@ +/* +* Copyright (C) 2012 Samsung Electronics +* Lukasz Majewski <[email protected]> +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License as +* published by the Free Software Foundation; either version 2 of +* the License, or (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, +* MA 02111-1307 USA +*/ + +#ifndef __G_DOWNLOAD_H_ +#define __G_DOWNLOAD_H_ + +#include <linux/usb/ch9.h> +#include <usbdescriptors.h> +#include <linux/usb/gadget.h> + +int g_dnl_init (char *s); +void g_dnl_cleanup (void ); + +/* USB initialization declaration - board specific*/ +void board_usb_init (void ); +#endif /* __G_DOWNLOAD_H_ */
PATCH 1/7 dfu:usb: Support for g_dnl composite download gadget.
Hi Marek,
Thanks for review.
Quoted 74 lines
Dear Lukasz Majewski,
Quoted 72 lines
Composite USB download gadget support (
g_dnl) for download functions. This code works on top of composite gadget.Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>--- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/g_dnl.c | 235 +++++++++++++++++++++++++++++++++++++++++++ include/g_dnl.h | 33 ++++++ 3 files changed, 269 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/g_dnl.c create mode 100644 include/g_dnl.h(quoted diff) +0
-0b/drivers/usb/gadget/Makefile index 87d1918..2c067c8 100644
drivers/usb/gadget/Makefile +1
-0@@ -29,6 +29,7 @@ LIB := $(obj)libusb_gadget.o 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 endif ifdef CONFIG_USB_ETHER COBJS-y += ether.o epautoconf.o config.o usbstring.odrivers/usb/gadget/g_dnl.c new file +7
-0@@ -0,0 +1,235 @@ +/* +* g_dnl.c -- USB Downloader Gadget +* +* Copyright (C) 2012 Samsung Electronics +* Lukasz Majewski <[email protected]> +* +* This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */drivers/usb/gadget/g_dnl.c new file +15
-0+ +#include <errno.h> +#include <common.h> +#include <malloc.h> +#include <linux/usb/ch9.h> +#include <usbdescriptors.h> +#include <linux/usb/gadget.h> + +#include <mmc.h> +#include <part.h> + +#include <g_dnl.h> +#include "f_dfu.h" + +#include "gadget_chips.h"
Quoted 8 lines
drivers/usb/gadget/g_dnl.c line 40
Quoted 5 lines
drivers/usb/gadget/g_dnl.c new file +5
-0+#include "composite.c" + +/* Samsung's IDs */ +#define DRIVER_VENDOR_NUM 0x04E8 +#define DRIVER_PRODUCT_NUM 0x6601Is it samsung specific? Or can we use some USB IDs that are not bound to samsung?
I think, that those IDs shall be defined at include/configs/<board>.h In that way one can use any ID.
Quoted 13 lines
drivers/usb/gadget/g_dnl.c line 51
Quoted 11 lines
drivers/usb/gadget/g_dnl.c new file +10
-0+#define STRING_MANUFACTURER 25 +#define STRING_PRODUCT 2 +#define STRING_USBDOWN 2 +#define CONFIG_USBDOWNLOADER 2 + +#define DRIVER_VERSION "usb_dnl 2.0" + +static const char shortname[] ="usb_dnl_" ; +static const char product[] ="SLP USB download gadget" ; +static const char manufacturer[] ="Samsung" ;DITTO?
Manufacturer field can be either omitted or changed to other name.
Quoted 52 lines
Quoted 52 lines
drivers/usb/gadget/g_dnl.c new file +8
-0+ +static struct usb_device_descriptor device_desc = { + .bLength =sizeof device_desc, + .bDescriptorType =USB_DT_DEVICE , + + .bcdUSB =__constant_cpu_to_le16 (0x0200 ), + .bDeviceClass =USB_CLASS_COMM , + .bDeviceSubClass =0x02 ,/*0x02:CDC-modem , 0x00:CDC-serial*/ +
drivers/usb/gadget/g_dnl.c new file +1
-0+ .idVendor =
__constant_cpu_to_le16(DRIVER_VENDOR_NUM),drivers/usb/gadget/g_dnl.c new file +1
-0+ .idProduct =
__constant_cpu_to_le16(DRIVER_PRODUCT_NUM),drivers/usb/gadget/g_dnl.c new file +6
-0+ .iProduct = STRING_PRODUCT, + .bNumConfigurations = 1, +}; + +static const struct usb_descriptor_header *otg_desc[] = { + (struct usb_descriptor_header *) &(structusb_otg_descriptor){
drivers/usb/gadget/g_dnl.c new file +1
-0+ .bLength = sizeof(struct
usb_otg_descriptor),drivers/usb/gadget/g_dnl.c new file +29
-0+ .bDescriptorType = USB_DT_OTG, + .bmAttributes = USB_OTG_SRP, + }, + NULL, +}; + +/* static strings, in UTF-8 */ +static struct usb_string odin_string_defs[] = { + {0 , manufacturer, }, + {1 , product, }, +}; + +static struct usb_gadget_strings odin_string_tab = { + .language =0x0409 ,/* en-us */ + .strings = odin_string_defs, +}; + +static struct usb_gadget_strings *g_dnl_composite_strings[] = { + &odin_string_tab, +NULL , +}; + +static int g_dnl_unbind (struct usb_composite_dev *cdev) +{ +debug ("%s\n" , __func__); +return 0 ; +} + +static int g_dnl_do_config (struct usb_configuration *c)
Quoted 8 lines
drivers/usb/gadget/g_dnl.c line 103
Quoted 5 lines
drivers/usb/gadget/g_dnl.c new file +5
-0+{ +int ret =-1 ; +char *s = (char *) c->cdev->driver->name; + +debug ("%s: c: 0x%p cdev: 0x%p\n" , __func__, c, c->cdev);Can you elaborate in that debug message more? It's not really useful ;-)
I will correct that.
Quoted 12 lines
drivers/usb/gadget/g_dnl.c line 113
Quoted 10 lines
drivers/usb/gadget/g_dnl.c new file +9
-0+if (gadget_is_otg (c->cdev->gadget)) { + c->descriptors = otg_desc; + c->bmAttributes |=USB_CONFIG_ATT_WAKEUP ; + } + +printf ("GADGET DRIVER: %s\n" , s); + +if (!strcmp (s,"usb_dnl_dfu" )) + ret =dfu_add (c);And if this fails, we should set ret= as well, no?
The dynamic variable "ret" is defined with -1 value on the beginning of the function. When comparison fails, the -1 value is returned.
Quoted 42 lines
Quoted 42 lines
drivers/usb/gadget/g_dnl.c new file +10
-0+ +return ret; +} + +static int g_dnl_config_register(struct usb_composite_dev *cdev) +{ + debug("%s:\n", __func__); + static struct usb_configuration config = { + .label = "usb_dnload", + .bmAttributes = USB_CONFIG_ATT_ONE |
USB_CONFIG_ATT_SELFPOWER,drivers/usb/gadget/g_dnl.c new file +16
-0+ .bConfigurationValue = CONFIG_USBDOWNLOADER, + .iConfiguration = STRING_USBDOWN, + + .bind = g_dnl_do_config, + }; + +return usb_add_config (cdev, &config); +} + +static int g_dnl_bind (struct usb_composite_dev *cdev) +{ +int gcnum; +int id, ret; +struct usb_gadget *gadget = cdev->gadget; + + debug("%s: gadget: 0x%p cdev: 0x%p\n", __func__, gadget,cdev); +
drivers/usb/gadget/g_dnl.c new file +13
-0+ id =usb_string_id (cdev); + +if (id <0 ) +return id; + odin_string_defs[0 ].id = id; + device_desc.iManufacturer = id; + + id =usb_string_id (cdev); +if (id <0 ) +return id; + + odin_string_defs[1 ].id = id; + device_desc.iProduct = id;
Quoted 8 lines
drivers/usb/gadget/g_dnl.c line 159
Quoted 6 lines
drivers/usb/gadget/g_dnl.c new file +6
-0+ + ret =g_dnl_config_register (cdev); +if (ret) + goto error; + +Two newlines
Will fix.
Quoted 28 lines
Quoted 28 lines
drivers/usb/gadget/g_dnl.c new file +5
-0+ gcnum =usb_gadget_controller_number (gadget); + +debug ("gcnum: %d\n" , gcnum); +if (gcnum >=0 ) + device_desc.bcdDevice = cpu_to_le16(0x0200 +gcnum);
drivers/usb/gadget/g_dnl.c new file +4
-0+else { +debug ("%s: controller '%s' not recognized\n" , + shortname, gadget->name); + device_desc.bcdDevice =
__constant_cpu_to_le16(0x9999);drivers/usb/gadget/g_dnl.c new file +16
-0+ } + +return 0 ; + + error: +g_dnl_unbind (cdev); +return -ENOMEM ; +} + +static void g_dnl_suspend (struct usb_composite_dev *cdev) +{ +if (cdev->gadget->speed ==USB_SPEED_UNKNOWN ) +return ; + +debug ("suspend\n" ); +}
Quoted 8 lines
drivers/usb/gadget/g_dnl.c line 189
Quoted 5 lines
drivers/usb/gadget/g_dnl.c new file +5
-0+ +static void g_dnl_resume (struct usb_composite_dev *cdev) +{ +debug ("resume\n" ); +}Maybe you should check if suspend/resume are set at all. Then you won't need the above stubs.
I will remove them.
Quoted 12 lines
Quoted 12 lines
drivers/usb/gadget/g_dnl.c new file +11
-0+static struct usb_composite_driver g_dnl_driver = { + .name =NULL , + .dev = &device_desc, + .strings = g_dnl_composite_strings, + + .bind = g_dnl_bind, + .unbind = g_dnl_unbind, + + .suspend = g_dnl_suspend, + .resume = g_dnl_resume, +};
Quoted 8 lines
drivers/usb/gadget/g_dnl.c line 207
Quoted 6 lines
drivers/usb/gadget/g_dnl.c new file +6
-0+ +int g_dnl_init (char *s) +{ +int ret; +static char str[16 ]; +Why use '\0' if you can just use 0 ?
I will change.
Quoted 14 lines
Quoted 14 lines
drivers/usb/gadget/g_dnl.c new file +13
-0+memset (str,'\0' ,sizeof (str)); + +strncpy (str, shortname,sizeof (shortname)); + +if (!strncmp (s,"dfu" ,sizeof (s))) { +strncat (str, s,sizeof (str)); + }else { +printf ("%s: unknown command: %s\n" , __func__, s); +return -EINVAL ; + } + + g_dnl_driver.name = str; +
Quoted 8 lines
drivers/usb/gadget/g_dnl.c line 225
Quoted 6 lines
drivers/usb/gadget/g_dnl.c new file +1
-0+ debug("%s: g_dnl_driver.name: %s\n", __func__,g_dnl_driver.name);
drivers/usb/gadget/g_dnl.c new file +4
-0+ ret =usb_composite_register (&g_dnl_driver); + +if (ret) { +printf ("%s: failed!, error:%d " , __func__, ret);Missing newline in
printf()(...error:%d ").
I will change that.
Quoted 51 lines
Quoted 51 lines
drivers/usb/gadget/g_dnl.c new file +10
-0+return ret; + } + +return 0 ; +} + +void g_dnl_cleanup (void ) +{ +usb_composite_unregister (&g_dnl_driver); +}include/g_dnl.h new file +15
-0@@ -0,0 +1,33 @@ +/* +* Copyright (C) 2012 Samsung Electronics +* Lukasz Majewski <[email protected]> +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License as +* published by the Free Software Foundation; either version 2 of +* the License, or (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */include/g_dnl.h new file +14
-0+ +#ifndef __G_DOWNLOAD_H_ +#define __G_DOWNLOAD_H_ + +#include <linux/usb/ch9.h> +#include <usbdescriptors.h> +#include <linux/usb/gadget.h> + +int g_dnl_init (char *s); +void g_dnl_cleanup (void ); + +/* USB initialization declaration - board specific*/ +void board_usb_init (void ); +#endif /* __G_DOWNLOAD_H_ */
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH 1/7 dfu:usb: Support for g_dnl composite download gadget.
In reply to Lukasz Majewskidrivers/usb/gadget/g_dnl.c
Quoted 4 lines · On Tuesday 03 July 2012 05:38:05 Lukasz Majewski wrote:
drivers/usb/gadget/g_dnl.c new file +1
-0+static const char shortname[] ="usb_dnl_" ;
shortname -> gadget_name_prefix
drivers/usb/gadget/g_dnl.c line 189
Quoted 12 lines
drivers/usb/gadget/g_dnl.c new file +12
-0+static void g_dnl_suspend (struct usb_composite_dev *cdev) +{ +if (cdev->gadget->speed ==USB_SPEED_UNKNOWN ) +return ; + +debug ("suspend\n" ); +} + +static void g_dnl_resume (struct usb_composite_dev *cdev) +{ +debug ("resume\n" ); +}
do suspend/resume funcs make any sense in u-boot ?
Quoted 1 line
+int
g_dnl_init(char *s)
const char
drivers/usb/gadget/g_dnl.c line 210
Quoted 7 lines
drivers/usb/gadget/g_dnl.c new file +7
-0+{ +int ret; +static char str[16 ]; + +memset (str,'\0' ,sizeof (str)); + +strncpy (str, shortname,sizeof (shortname));
no need for the memset. this strncpy looks broken -- the 3rd arg is for how many bytes are available in the *dest* buffer, not how long the source is.
drivers/usb/gadget/g_dnl.c line 212
Quoted 1 line
drivers/usb/gadget/g_dnl.c new file +1
-0+if (!strncmp (s,"dfu" ,sizeof (s))) {
sizeof() here is wrong -- that gives you back 4 (the size of a pointer) on 32bit systems
drivers/usb/gadget/g_dnl.c line 213
Quoted 1 line
drivers/usb/gadget/g_dnl.c new file +1
-0+strncat (str, s,sizeof (str));
this is also incorrect. the length given to strncat is how many bytes are left, not the total length.
since this string parsing logic is all just completely broken, i'd suggest replacing it all with:
{
int ret;
/* We only allow "dfu" atm, so 3 should be enough */
static char name[sizeof(shortname) + 3];
if (strcmp(s, "dfu")) {
printf("%s: unknown command: %s\n", __func__, s);
return -EINVAL;
}
strcpy(name, shortname);
strcat(name, s);drivers/usb/gadget/g_dnl.c line 225
Quoted 2 lines
drivers/usb/gadget/g_dnl.c new file +2
-0+if (ret) { +printf ("%s: failed!, error:%d " , __func__, ret);
needs a space between "error:" and "%d"
include/g_dnl.h
Quoted 6 lines
include/g_dnl.h new file +3
-0+#include <linux/usb/ch9.h> +#include <usbdescriptors.h> +#include <linux/usb/gadget.h>
unused -> delete
Quoted 1 line
+int
g_dnl_init(char *s);
int g_dnl_register(const char *type);
this also needs documentation in the header explaining how to use this func
Quoted 1 line
+void
g_dnl_cleanup(void);
void g_dnl_unregister(void);
include/g_dnl.h line 32
Quoted 2 lines
include/g_dnl.h new file +2
-0+/* USB initialization declaration - board specific*/ +void board_usb_init (void );
not used in these files -> delete
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120720/587193d8/attachment.pgp>
PATCH 1/7 dfu:usb: Support for g_dnl composite download gadget.
Dear Mike Frysinger,
Thank you for thorough review.
Quoted 7 lines · On Tuesday 03 July 2012 05:38:05 Lukasz Majewski wrote:
drivers/usb/gadget/g_dnl.c
Quoted 4 lines
drivers/usb/gadget/g_dnl.c new file +1
-0+static const char shortname[] ="usb_dnl_" ;shortname ->
gadget_name_prefix
This might be only matter of taste, but in my opinion this name is more readable.
Quoted 15 lines
drivers/usb/gadget/g_dnl.c line 189
Quoted 13 lines
drivers/usb/gadget/g_dnl.c new file +12
-0+static void g_dnl_suspend (struct usb_composite_dev *cdev) +{ +if (cdev->gadget->speed ==USB_SPEED_UNKNOWN ) +return ; + +debug ("suspend\n" ); +} + +static void g_dnl_resume (struct usb_composite_dev *cdev) +{ +debug ("resume\n" ); +}do suspend/resume funcs make any sense in u-boot ?
You have reviewed the v1 of this patch series. Marek Vasut has already pointed out this problem and it has been resoled with v2.
Quoted 4 lines
Quoted 2 lines
+int
g_dnl_init(char *s)const char
Ok.
Quoted 10 lines
drivers/usb/gadget/g_dnl.c line 210
Quoted 8 lines
drivers/usb/gadget/g_dnl.c new file +7
-0+{ +int ret; +static char str[16 ]; + +memset (str,'\0' ,sizeof (str)); + +strncpy (str, shortname,sizeof (shortname));no need for the memset.
The gadget can be called from many separate commands (e.g. command "dfu" and command "ums") and those commands can be executed without power cycle. Thereof I need to be sure, that str is not polluted by previous name.
Quoted 3 lines
this strncpy looks broken -- the 3rd arg is
for how many bytes are available in the *dest* buffer, not how long the source is.
After looking deeply into the source I admit that providing the upper bound on the dest is more safe.
Quoted 5 lines
drivers/usb/gadget/g_dnl.c line 212
Quoted 2 lines
drivers/usb/gadget/g_dnl.c new file +1
-0+if (!strncmp (s,"dfu" ,sizeof (s))) {
sizeof()here is wrong -- that gives you back 4 (the size of a pointer) on 32bit systems
... and it works only because the "dfu\0" and "ums\0" is 4 lenght. :/
Quoted 5 lines
drivers/usb/gadget/g_dnl.c line 213
Quoted 2 lines
drivers/usb/gadget/g_dnl.c new file +1
-0+strncat (str, s,sizeof (str));this is also incorrect. the length given to strncat is how many bytes are left, not the total length.
I cannot agree. sizeof(str) return 16, which is the destination buffer size.
Quoted 4 lines
since this string parsing logic is all just completely broken, i'd suggest replacing it all with:
Quoted 13 lines
{
int ret;
/* We only allow "dfu" atm, so 3 should be enough */
static char name[sizeof(shortname) + 3];
if (strcmp(s, "dfu")) {
printf("%s: unknown command: %s\n", __func__, s);
return -EINVAL;
}
strcpy(name, shortname);
strcat(name, s);This is a very neat design, but it assumes that there will be only one function ("dfu" in this case). For this particular function +3 applies, but what if another function (like "usb_storage") will be defined?
I'm now working on another function - the USB Mass Storage (named "ums" ;-) ).
Another issue is omitting the strncmp/strncpy functions and depending on
the: static char name[sizeof(shortname) + 3]; definition to prevent buffer overflow.
The +3 magic number worries me a bit...
Quoted 4 lines
drivers/usb/gadget/g_dnl.c line 225
Quoted 2 lines
drivers/usb/gadget/g_dnl.c new file +2
-0+if (ret) { +printf ("%s: failed!, error:%d " , __func__, ret);needs a space between "error:" and "%d"
Will be fixed
Quoted 9 lines
include/g_dnl.h
Quoted 7 lines
include/g_dnl.h new file +3
-0+#include <linux/usb/ch9.h> +#include <usbdescriptors.h> +#include <linux/usb/gadget.h> unused -> delete
I will remove those includes from g_dnl.c file
Quoted 7 lines
Quoted 2 lines
+int
g_dnl_init(char *s);int
g_dnl_register(const char *type);this also needs documentation in the header explaining how to use this func
I will provide the working example of this gadget. I will not insist on the function name. It can be g_dnl_register().
Quoted 4 lines
Quoted 2 lines
+void
g_dnl_cleanup(void);void
g_dnl_unregister(void);
Can be g_dnl_unregister() as well.
Quoted 5 lines
include/g_dnl.h line 32
Quoted 3 lines
include/g_dnl.h new file +2
-0+/* USB initialization declaration - board specific*/ +void board_usb_init (void );not used in these files -> delete
But it is used at e.g. samsung/trats/trats.c I think that g_dnl.h is a good place for this.
Quoted 1 line
-mike
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH 1/7 dfu:usb: Support for g_dnl composite download gadget.
Quoted 12 lines · On Monday 23 July 2012 11:25:25 Lukasz Majewski wrote:
Dear Mike Frysinger,
Quoted 10 lines · On Tuesday 03 July 2012 05:38:05 Lukasz Majewski wrote:
drivers/usb/gadget/g_dnl.c line 210
Quoted 7 lines
drivers/usb/gadget/g_dnl.c new file +7
-0+{ +int ret; +static char str[16 ]; + +memset (str,'\0' ,sizeof (str)); + +strncpy (str, shortname,sizeof (shortname));no need for the memset.
Quoted 4 lines
The gadget can be called from many separate commands (e.g. command "dfu" and command "ums") and those commands can be executed without power cycle. Thereof I need to be sure, that str is not polluted by previous name.
that makes no sense. please read the documentation of the str*cpy functions -- they do no analysis of the target string and merely copy the source to the destination. thus this code is basically:
str[0] = '\0'; str[1] = '\0'; str[...] = '\0'; str[0] = shortname[0]; str[1] = shortname[1]; str[...] = shortname[...];
it should be fairly obvious now why that memset is pointless.
Quoted 6 lines
Quoted 3 lines
this strncpy looks broken -- the 3rd arg is
for how many bytes are available in the *dest* buffer, not how long the source is.After looking deeply into the source I admit that providing the upper bound on the dest is more safe.
it isn't a matter of being safe, it's a matter of correctness
Quoted 7 lines
Quoted 4 lines
drivers/usb/gadget/g_dnl.c line 213
Quoted 1 line
drivers/usb/gadget/g_dnl.c new file +1
-0+strncat (str, s,sizeof (str));this is also incorrect. the length given to strncat is how many bytes are left, not the total length.
I cannot agree. sizeof(str) return 16, which is the destination buffer size.
which is wrong. please read the strncat specification.
Quoted 13 lines
Quoted 13 lines
since this string parsing logic is all just completely broken, i'd suggest replacing it all with:
{ int ret; /* We only allow "dfu" atm, so 3 should be enough */ static char name[sizeof(shortname) + 3]; if (strcmp(s, "dfu")) { printf("%s: unknown command: %s\n", __func__, s); return -EINVAL; }
Quoted 7 lines
Quoted 2 lines
strcpy(name, shortname); strcat(name, s);This is a very neat design, but it assumes that there will be only one function ("dfu" in this case). For this particular function +3 applies, but what if another function (like "
usb_storage") will be defined?
why does that matter ? the snippet i posted above is trivial to extend to support any number of functions. increase the "3" to the max you care about, and then add more strcmp() to the if statement.
Quoted 6 lines
I'm now working on another function - the USB Mass Storage (named "ums" ;-) ).
Another issue is omitting the strncmp/strncpy functions and depending on
the: static char name[sizeof(shortname) + 3]; definition to prevent buffer overflow.
your existing code is already full of bugs that don't prevent overflow, and having the "3" right next to the "dfu" with a comment makes it pretty clear what is going on.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120724/a538543b/attachment.pgp>
PATCH 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
In reply to Lukasz MajewskiSupport for f_dfu USB function.
--- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/f_dfu.c | 666 +++++++++++++++++++++++++++++++++++++++++++ drivers/usb/gadget/f_dfu.h | 100 +++++++ 3 files changed, 767 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/f_dfu.c create mode 100644 drivers/usb/gadget/f_dfu.h
drivers/usb/gadget/Makefile +1 -0
@@ -30,6 +30,7 @@ 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
drivers/usb/gadget/f_dfu.c new file +666 -0
666 lines not on this page · raw message
drivers/usb/gadget/f_dfu.h new file +100 -0
100 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
Dear Lukasz Majewski,
Quoted 6 lines
Support for
f_dfuUSB function.Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
drivers/usb/gadget/f_dfu.c line 95
Quoted 6 lines
drivers/usb/gadget/f_dfu.c new file +6
-0+ +static const char dfu_name[] ="Device Firmware Upgrade" ; + +/* static strings, in UTF-8 */ +/* +* dfu_genericiguration specific
generi....what?
Quoted 47 lines
+ */
drivers/usb/gadget/f_dfu.c new file +36
-1+static struct usb_string strings_dfu_generic[] = { + [0 ].s = dfu_name, + { }/* end of list */ +}; + +static struct usb_gadget_strings stringtab_dfu_generic = { + .language =0x0409 ,/* en-us */ + .strings = strings_dfu_generic, +}; + +static struct usb_gadget_strings *dfu_generic_strings[] = { + &stringtab_dfu_generic, +NULL , +}; + +/* +* usb_function specific +*/ +static struct usb_gadget_strings stringtab_dfu = { + .language =0x0409 ,/* en-us */ +/* +* .strings +* +* assigned during initialization, +* depends on number of flash entities +* +*/ +}; + +static struct usb_gadget_strings *dfu_strings[] = { + &stringtab_dfu, +NULL , +}; + +/*------------------------------------------------------------------------ -*/ + +static void dnload_request_complete(struct usb_ep *ep, struct usb_request *req) +{
drivers/usb/gadget/f_dfu.c new file +8
-0+struct f_dfu *f_dfu = req->context; + +dfu_write (dfu_get_entity (f_dfu->altsetting), req->buf, + req->length, f_dfu->blk_seq_num); + +if (req->length ==0 ) { +puts ("DOWNLOAD ... OK\n" ); +puts ("Ctrl+C to exit ...\n" );
drivers/usb/gadget/f_dfu.c line 152
Quoted 10 lines
drivers/usb/gadget/f_dfu.c new file +10
-0+ } +} + +static void handle_getstatus (struct usb_request *req) +{ +struct dfu_status *dstat = (struct dfu_status *)req->buf; +struct f_dfu *f_dfu = req->context; + +switch (f_dfu->dfu_state) { +case DFU_STATE_dfuDNLOAD_SYNC:
What's this crazy cammel case in here ? :-)
drivers/usb/gadget/f_dfu.c line 164
Quoted 12 lines
drivers/usb/gadget/f_dfu.c new file +12
-0+case DFU_STATE_dfuDNBUSY: + f_dfu->dfu_state = DFU_STATE_dfuDNLOAD_IDLE; +break ; +case DFU_STATE_dfuMANIFEST_SYNC: +break ; +default : +break ; + } + +/* send status response */ + dstat->bStatus = f_dfu->dfu_status; +/* FIXME: set dstat->bwPollTimeout */
FIXME ... so fix it ;-)
drivers/usb/gadget/f_dfu.c line 173
Quoted 9 lines
drivers/usb/gadget/f_dfu.c new file +9
-0+ dstat->bState = f_dfu->dfu_state; + dstat->iString =0 ; +} + +static void handle_getstate (struct usb_request *req) +{ +struct f_dfu *f_dfu = req->context; + + ((u8 *)req->buf)[0 ] = f_dfu->dfu_state &0xff ;
Now ... this is ubercrazy ... can't this be made without this typecasting voodoo?
Quoted 3 lines
drivers/usb/gadget/f_dfu.c new file +3
-0+ req->actual =sizeof (u8); +} +
[...]
drivers/usb/gadget/f_dfu.c line 209
Quoted 13 lines
drivers/usb/gadget/f_dfu.c new file +13
-0+static int handle_dnload (struct usb_gadget *gadget,u16 len) +{ +struct usb_composite_dev *cdev =get_gadget_data (gadget); +struct usb_request *req = cdev->req; +struct f_dfu *f_dfu = req->context; + +if (len ==0 ) + f_dfu->dfu_state = DFU_STATE_dfuMANIFEST_SYNC; + + req->complete = dnload_request_complete; + +return len; +}
One newline too much below.
Quoted 11 lines
drivers/usb/gadget/f_dfu.c new file +11
-0+ + +static int +dfu_handle (struct usb_function *f,const struct usb_ctrlrequest *ctrl) +{ +struct usb_gadget *gadget = f->config->cdev->gadget; +struct usb_request *req = f->config->cdev->req; +struct f_dfu *f_dfu = f->config->cdev->req->context; +u16 len =le16_to_cpu (ctrl->wLength); +u16 w_value =le16_to_cpu (ctrl->wValue); +int value =0 ;
drivers/usb/gadget/f_dfu.c line 230
Quoted 10 lines
drivers/usb/gadget/f_dfu.c new file +10
-0+int standard; + + standard = (ctrl->bRequestType &USB_TYPE_MASK ) + ==USB_TYPE_STANDARD ; + +debug ("w_value: 0x%x len: 0x%x\n" , w_value, len); +debug ("standard: 0x%x ctrl->bRequest: 0x%x f_dfu->dfu_state: 0x%x\n" , + standard, ctrl->bRequest, f_dfu->dfu_state); + +if (!standard) {
This function doesn't fit on my screen ... that means it's waaaay too long and shall be split into more functions ;-)
That's also remove the need for your crazy conditional assignment of standard.
Quoted 7 lines
drivers/usb/gadget/f_dfu.c new file +7
-0+switch (f_dfu->dfu_state) { +case DFU_STATE_appIDLE: +switch (ctrl->bRequest) { +case USB_REQ_DFU_GETSTATUS : +handle_getstatus (req); + value =RET_STAT_LEN ; +break ;
[...]
drivers/usb/gadget/f_dfu.c line 478
Quoted 10 lines
drivers/usb/gadget/f_dfu.c new file +9
-1+ +/*------------------------------------------------------------------------ -*/ + +static int +dfu_prepare_strings(struct f_dfu *f_dfu, int n) +{ +struct dfu_entity *de = NULL; +int i = 0; + +f_dfu->strings = calloc(((n + 1) * sizeof(struct usb_string)), 1);
calloc(n, 1) ... that's the same as malloc(), isn't it ?
Quoted 18 lines
drivers/usb/gadget/f_dfu.c new file +18
-0+if (!f_dfu->strings) + goto enomem; + +for (i =0 ; i < n; ++i) { + de =dfu_get_entity (i); + f_dfu->strings[i].s = de->name; + } + + f_dfu->strings[i].id =0 ; + f_dfu->strings[i].s =NULL ; + +return 0 ; + +enomem: +while (i) + f_dfu->strings[--i].s =NULL ; + +kfree (f_dfu->strings);
drivers/usb/gadget/f_dfu.c line 506
Quoted 10 lines
drivers/usb/gadget/f_dfu.c new file +10
-0+ +return -ENOMEM ; +} + +static int dfu_prepare_function (struct f_dfu *f_dfu,int n) +{ +struct usb_interface_descriptor *d; +int i =0 ; + + f_dfu->function =calloc (n *sizeof (struct usb_descriptor_header *),1 );
DITTO
drivers/usb/gadget/f_dfu.c line 511
Quoted 5 lines
drivers/usb/gadget/f_dfu.c new file +5
-0+if (!f_dfu->function) + goto enomem; + +for (i =0 ; i < n; ++i) { + d =kzalloc (sizeof (*d),GFP_KERNEL );
Why use the kernel alternatives ? just use malloc()/free() ?
Quoted 55 lines
drivers/usb/gadget/f_dfu.c new file +55
-0+if (!d) + goto enomem; + + d->bLength =sizeof (*d); + d->bDescriptorType =USB_DT_INTERFACE ; + d->bAlternateSetting = i; + d->bNumEndpoints =0 ; + d->bInterfaceClass =USB_CLASS_APP_SPEC ; + d->bInterfaceSubClass =1 ; + d->bInterfaceProtocol =2 ; + + f_dfu->function[i] = (struct usb_descriptor_header *)d; + } + f_dfu->function[i] =NULL ; + +return 0 ; + +enomem: +while (i) { +kfree (f_dfu->function[--i]); + f_dfu->function[i] =NULL ; + } +kfree (f_dfu->function); + +return -ENOMEM ; +} + +static int dfu_bind (struct usb_configuration *c,struct usb_function *f) +{ +struct usb_composite_dev *cdev = c->cdev; +struct f_dfu *f_dfu =func_to_dfu (f); +int alt_num =dfu_get_alt_number (); +int rv, id, i; + + id =usb_interface_id (c, f); +if (id <0 ) +return id; + dfu_intf_runtime.bInterfaceNumber = id; + + f_dfu->dfu_state = DFU_STATE_appIDLE; + f_dfu->dfu_status =DFU_STATUS_OK ; + + rv =dfu_prepare_function (f_dfu, alt_num); +if (rv) + goto error; + + rv =dfu_prepare_strings (f_dfu, alt_num); +if (rv) + goto error; +for (i =0 ; i < alt_num; i++) { + id =usb_string_id (cdev); +if (id <0 ) +return id; + f_dfu->strings[i].id = id; + ((struct usb_interface_descriptor *)f_dfu->function[i])
drivers/usb/gadget/f_dfu.c line 576
Quoted 10 lines
drivers/usb/gadget/f_dfu.c new file +10
-0+ ->iInterface = id; + } + + stringtab_dfu.strings = f_dfu->strings; + + cdev->req->context = f_dfu; + +return 0 ; +error: +return rv;
So just return the retval ...
Review
Quoted 2 lines
(quoted diff) +2
-0+} +
Every time I review patches and find multiple small issues, I feel bad :-(
PATCH 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
Hi Marek,
Quoted 9 lines
Dear Lukasz Majewski,
Quoted 6 lines
Support for
f_dfuUSB function.Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
Quoted 9 lines
drivers/usb/gadget/f_dfu.c line 95
Quoted 6 lines
drivers/usb/gadget/f_dfu.c new file +6
-0+ +static const char dfu_name[] ="Device Firmware Upgrade" ; + +/* static strings, in UTF-8 */ +/* +* dfu_genericiguration specific generi....what?
Misspelled, fixed.
Quoted 52 lines
Quoted 52 lines
+ */
drivers/usb/gadget/f_dfu.c new file +36
-1+static struct usb_string strings_dfu_generic[] = { + [0 ].s = dfu_name, + { }/* end of list */ +}; + +static struct usb_gadget_strings stringtab_dfu_generic = { + .language =0x0409 ,/* en-us */ + .strings = strings_dfu_generic, +}; + +static struct usb_gadget_strings *dfu_generic_strings[] = { + &stringtab_dfu_generic, +NULL , +}; + +/* +* usb_function specific +*/ +static struct usb_gadget_strings stringtab_dfu = { + .language =0x0409 ,/* en-us */ +/* +* .strings +* +* assigned during initialization, +* depends on number of flash entities +* +*/ +}; + +static struct usb_gadget_strings *dfu_strings[] = { + &stringtab_dfu, +NULL , +}; + +/*------------------------------------------------------------------------ -*/ + +static void dnload_request_complete(struct usb_ep *ep, struct
usb_request*req) +{drivers/usb/gadget/f_dfu.c new file +12
-0+struct f_dfu *f_dfu = req->context; + +dfu_write (dfu_get_entity (f_dfu->altsetting), req->buf, + req->length, f_dfu->blk_seq_num); + +if (req->length ==0 ) { +puts ("DOWNLOAD ... OK\n" ); +puts ("Ctrl+C to exit ...\n" ); + } +} + +static void handle_getstatus (struct usb_request *req)
Quoted 8 lines
drivers/usb/gadget/f_dfu.c line 152
Quoted 6 lines
drivers/usb/gadget/f_dfu.c new file +6
-0+{ +struct dfu_status *dstat = (struct dfu_status *)req->buf; +struct f_dfu *f_dfu = req->context; + +switch (f_dfu->dfu_state) { +case DFU_STATE_dfuDNLOAD_SYNC:What's this crazy cammel case in here ? :-)
I know, that camel case descriptions are not welcome :-), but those are written in this way for purpose.
dfuDNLOAD_SYNC is the exact state name mentioned at DFU specification. Other states - like dfuDNBUSY are exactly the same.
From mine experience it is more readable. Please consider for example the Fig. A1 - Interface state transition diagram from page 28 at DFU_1.1.pdf spec (link below).
http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf
Quoted 15 lines
drivers/usb/gadget/f_dfu.c line 164
Quoted 13 lines
drivers/usb/gadget/f_dfu.c new file +12
-0+case DFU_STATE_dfuDNBUSY: + f_dfu->dfu_state = DFU_STATE_dfuDNLOAD_IDLE; +break ; +case DFU_STATE_dfuMANIFEST_SYNC: +break ; +default : +break ; + } + +/* send status response */ + dstat->bStatus = f_dfu->dfu_status; +/* FIXME: set dstat->bwPollTimeout */ FIXME ... so fix it ;-)
This is not u-boot related - will be removed
Quoted 13 lines
drivers/usb/gadget/f_dfu.c line 173
Quoted 10 lines
drivers/usb/gadget/f_dfu.c new file +9
-0+ dstat->bState = f_dfu->dfu_state; + dstat->iString =0 ; +} + +static void handle_getstate (struct usb_request *req) +{ +struct f_dfu *f_dfu = req->context; + + ((u8 *)req->buf)[0 ] = f_dfu->dfu_state &0xff ;Now ... this is ubercrazy ... can't this be made without this typecasting voodoo?
The problem is that req->buf is a void pointer. And the goal is to store dfu state at 8 bits.
Quoted 5 lines
Quoted 4 lines
drivers/usb/gadget/f_dfu.c new file +3
-0+ req->actual =sizeof (u8); +} +[...]
Quoted 15 lines
drivers/usb/gadget/f_dfu.c line 209
Quoted 13 lines
drivers/usb/gadget/f_dfu.c new file +13
-0+static int handle_dnload (struct usb_gadget *gadget,u16 len) +{ +struct usb_composite_dev *cdev =get_gadget_data (gadget); +struct usb_request *req = cdev->req; +struct f_dfu *f_dfu = req->context; + +if (len ==0 ) + f_dfu->dfu_state = DFU_STATE_dfuMANIFEST_SYNC; + + req->complete = dnload_request_complete; + +return len; +}One newline too much below.
Fixed.
Quoted 27 lines
Quoted 20 lines
drivers/usb/gadget/f_dfu.c new file +4
-0+ + +static int +dfu_handle(struct usb_function *f, const struct usb_ctrlrequest*ctrl) +{
drivers/usb/gadget/f_dfu.c new file +10
-0+struct usb_gadget *gadget = f->config->cdev->gadget; +struct usb_request *req = f->config->cdev->req; +struct f_dfu *f_dfu = f->config->cdev->req->context; +u16 len =le16_to_cpu (ctrl->wLength); +u16 w_value =le16_to_cpu (ctrl->wValue); +int value =0 ; +int standard; + + standard = (ctrl->bRequestType &USB_TYPE_MASK ) + ==
USB_TYPE_STANDARD; +(quoted diff) +2
-0+ debug("w_value: 0x%x len: 0x%x\n", w_value, len); + debug("standard: 0x%x ctrl->bRequest: 0x%x
f_dfu->dfu_state: 0x%x\n",drivers/usb/gadget/f_dfu.c line 230
Quoted 3 lines
drivers/usb/gadget/f_dfu.c new file +3
-0+ standard, ctrl->bRequest, f_dfu->dfu_state); + +if (!standard) {This function doesn't fit on my screen ... that means it's waaaay too long and shall be split into more functions ;-)
Quoted 2 lines
That's also remove the need for your crazy conditional assignment of standard.
You are correct :-). I will split the if(!standard) clause to two separate. It shall improve readability.
Quoted 10 lines
Quoted 8 lines
drivers/usb/gadget/f_dfu.c new file +7
-0+switch (f_dfu->dfu_state) { +case DFU_STATE_appIDLE: +switch (ctrl->bRequest) { +case USB_REQ_DFU_GETSTATUS : +handle_getstatus (req); + value =RET_STAT_LEN ; +break ;[...]
Quoted 13 lines
Quoted 11 lines
drivers/usb/gadget/f_dfu.c new file +9
-1+ +/*------------------------------------------------------------------------ -*/ + +static int +dfu_prepare_strings(struct f_dfu *f_dfu, int n) +{ +struct dfu_entity *de = NULL; +int i = 0; + +f_dfu->strings = calloc(((n + 1) * sizeof(struct
usb_string)), 1);
calloc(n, 1)... that's the same asmalloc(), isn't it ?
I now wonder how mine mind produced this :-)
Correct version:
f_dfu->strings = calloc(sizeof(struct usb_string), n + 1);
I prefer calloc, since it delivers zeroed memory.
Quoted 24 lines
Quoted 24 lines
drivers/usb/gadget/f_dfu.c new file +23
-0+if (!f_dfu->strings) + goto enomem; + +for (i =0 ; i < n; ++i) { + de =dfu_get_entity (i); + f_dfu->strings[i].s = de->name; + } + + f_dfu->strings[i].id =0 ; + f_dfu->strings[i].s =NULL ; + +return 0 ; + +enomem: +while (i) + f_dfu->strings[--i].s =NULL ; + +kfree (f_dfu->strings); + +return -ENOMEM ; +} + +static int dfu_prepare_function (struct f_dfu *f_dfu,int n)
Quoted 8 lines
Quoted 6 lines
drivers/usb/gadget/f_dfu.c new file +5
-0+{ +struct usb_interface_descriptor *d; +int i =0 ; + + f_dfu->function = calloc(n * sizeof(struct
usb_descriptor_header*), 1);DITTO
As above.
Quoted 8 lines
drivers/usb/gadget/f_dfu.c line 511
Quoted 6 lines
drivers/usb/gadget/f_dfu.c new file +5
-0+if (!f_dfu->function) + goto enomem; + +for (i =0 ; i < n; ++i) { + d =kzalloc (sizeof (*d),GFP_KERNEL );Why use the kernel alternatives ? just use malloc()/free() ?
I will use calloc(sizeof(*d), 1) to receive cleared memory.
Quoted 62 lines
Quoted 62 lines
drivers/usb/gadget/f_dfu.c new file +12
-0+if (!d) + goto enomem; + + d->bLength =sizeof (*d); + d->bDescriptorType =USB_DT_INTERFACE ; + d->bAlternateSetting = i; + d->bNumEndpoints =0 ; + d->bInterfaceClass =USB_CLASS_APP_SPEC ; + d->bInterfaceSubClass =1 ; + d->bInterfaceProtocol =2 ; + + f_dfu->function[i] = (struct usb_descriptor_header*)d;
drivers/usb/gadget/f_dfu.c new file +16
-0+ } + f_dfu->function[i] =NULL ; + +return 0 ; + +enomem: +while (i) { +kfree (f_dfu->function[--i]); + f_dfu->function[i] =NULL ; + } +kfree (f_dfu->function); + +return -ENOMEM ; +} + +static int dfu_bind(struct usb_configuration *c, struct
usb_function*f) +{drivers/usb/gadget/f_dfu.c new file +26
-0+struct usb_composite_dev *cdev = c->cdev; +struct f_dfu *f_dfu =func_to_dfu (f); +int alt_num =dfu_get_alt_number (); +int rv, id, i; + + id =usb_interface_id (c, f); +if (id <0 ) +return id; + dfu_intf_runtime.bInterfaceNumber = id; + + f_dfu->dfu_state = DFU_STATE_appIDLE; + f_dfu->dfu_status =DFU_STATUS_OK ; + + rv =dfu_prepare_function (f_dfu, alt_num); +if (rv) + goto error; + + rv =dfu_prepare_strings (f_dfu, alt_num); +if (rv) + goto error; +for (i =0 ; i < alt_num; i++) { + id =usb_string_id (cdev); +if (id <0 ) +return id; + f_dfu->strings[i].id = id; + ((struct usb_interface_descriptor*)f_dfu->function[i])
drivers/usb/gadget/f_dfu.c new file +4
-0+ ->iInterface = id; + } + + stringtab_dfu.strings = f_dfu->strings;
Quoted 8 lines
drivers/usb/gadget/f_dfu.c line 576
Quoted 6 lines
drivers/usb/gadget/f_dfu.c new file +6
-0+ + cdev->req->context = f_dfu; + +return 0 ; +error: +return rv;So just return the retval ...
Fixed.
Quoted 6 lines
Review
Quoted 3 lines
(quoted diff) +2
-0+} +Every time I review patches and find multiple small issues, I feel bad :-(
All will be OK :-)
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
Dear Lukasz Majewski,
[...]
Quoted 13 lines
Quoted 9 lines
drivers/usb/gadget/f_dfu.c line 152
Quoted 8 lines
drivers/usb/gadget/f_dfu.c new file +7
-0+static void handle_getstatus (struct usb_request *req) +{ +struct dfu_status *dstat = (struct dfu_status *)req->buf; +struct f_dfu *f_dfu = req->context; + +switch (f_dfu->dfu_state) { +case DFU_STATE_dfuDNLOAD_SYNC:What's this crazy cammel case in here ? :-)
I know, that camel case descriptions are not welcome :-), but those are written in this way for purpose.
Quoted 8 lines
dfuDNLOAD_SYNCis the exact state name mentioned at DFU specification. Other states - like dfuDNBUSY are exactly the same.From mine experience it is more readable. Please consider for example the Fig. A1 - Interface state transition diagram from page 28 at DFU_1.1.pdf spec (link below).
OK, good.
Quoted 30 lines
Quoted 6 lines
Quoted 6 lines
drivers/usb/gadget/f_dfu.c new file +6
-0+case DFU_STATE_dfuDNBUSY: + f_dfu->dfu_state = DFU_STATE_dfuDNLOAD_IDLE; +break ; +case DFU_STATE_dfuMANIFEST_SYNC: +break ; +default :Quoted 8 lines
drivers/usb/gadget/f_dfu.c line 164
Quoted 6 lines
drivers/usb/gadget/f_dfu.c new file +6
-0+break ; + } + +/* send status response */ + dstat->bStatus = f_dfu->dfu_status; +/* FIXME: set dstat->bwPollTimeout */ FIXME ... so fix it ;-)
This is not u-boot related - will be removed
Quoted 4 lines
Quoted 4 lines
drivers/usb/gadget/f_dfu.c new file +4
-0+ dstat->bState = f_dfu->dfu_state; + dstat->iString =0 ; +} +Quoted 8 lines
drivers/usb/gadget/f_dfu.c line 173
Quoted 5 lines
drivers/usb/gadget/f_dfu.c new file +5
-0+static void handle_getstate (struct usb_request *req) +{ +struct f_dfu *f_dfu = req->context; + + ((u8 *)req->buf)[0 ] = f_dfu->dfu_state &0xff ;Now ... this is ubercrazy ... can't this be made without this typecasting voodoo?
Quoted 2 lines
The problem is that
req->bufis a void pointer. And the goal is to store dfu state at 8 bits.
Sure, but why not make the buffer u8 ?
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
drivers/usb/gadget/f_dfu.c new file +3
-0+ req->actual =sizeof (u8); +} +
[...]
Quoted 11 lines
Quoted 10 lines
Quoted 8 lines
drivers/usb/gadget/f_dfu.c new file +7
-0+static int +dfu_prepare_strings (struct f_dfu *f_dfu,int n) +{ +struct dfu_entity *de =NULL ; +int i =0 ; + + f_dfu->strings = calloc(((n + 1) * sizeof(struct
usb_string)), 1);
calloc(n, 1)... that's the same asmalloc(), isn't it ?
Quoted 7 lines
I now wonder how mine mind produced this :-)
Correct version:
f_dfu->strings=calloc(sizeof(struct usb_string), n + 1);I prefer calloc, since it delivers zeroed memory.
ok, that's better :)
[...]
PATCH 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
Hi Marek,
Quoted 59 lines
Dear Lukasz Majewski,
[...]
Quoted 14 lines
Quoted 10 lines
drivers/usb/gadget/f_dfu.c line 152
Quoted 9 lines
drivers/usb/gadget/f_dfu.c new file +3
-0+static void handle_getstatus (struct usb_request *req) +{ + struct dfu_status *dstat = (struct dfu_status*)req->buf;
drivers/usb/gadget/f_dfu.c new file +4
-0+struct f_dfu *f_dfu = req->context; + +switch (f_dfu->dfu_state) { +case DFU_STATE_dfuDNLOAD_SYNC:What's this crazy cammel case in here ? :-)
I know, that camel case descriptions are not welcome :-), but those are written in this way for purpose.
Quoted 8 lines
dfuDNLOAD_SYNCis the exact state name mentioned at DFU specification. Other states - like dfuDNBUSY are exactly the same.From mine experience it is more readable. Please consider for example the Fig. A1 - Interface state transition diagram from page 28 at DFU_1.1.pdf spec (link below).
OK, good.
Quoted 30 lines
Quoted 6 lines
Quoted 6 lines
drivers/usb/gadget/f_dfu.c new file +6
-0+case DFU_STATE_dfuDNBUSY: + f_dfu->dfu_state = DFU_STATE_dfuDNLOAD_IDLE; +break ; +case DFU_STATE_dfuMANIFEST_SYNC: +break ; +default :Quoted 8 lines
drivers/usb/gadget/f_dfu.c line 164
Quoted 6 lines
drivers/usb/gadget/f_dfu.c new file +6
-0+break ; + } + +/* send status response */ + dstat->bStatus = f_dfu->dfu_status; +/* FIXME: set dstat->bwPollTimeout */ FIXME ... so fix it ;-)
This is not u-boot related - will be removed
Quoted 12 lines
drivers/usb/gadget/f_dfu.c line 173
Quoted 9 lines
drivers/usb/gadget/f_dfu.c new file +9
-0+ dstat->bState = f_dfu->dfu_state; + dstat->iString =0 ; +} + +static void handle_getstate (struct usb_request *req) +{ +struct f_dfu *f_dfu = req->context; + + ((u8 *)req->buf)[0 ] = f_dfu->dfu_state &0xff ;Now ... this is ubercrazy ... can't this be made without this typecasting voodoo?
Quoted 4 lines
Quoted 2 lines
The problem is that
req->bufis a void pointer. And the goal is to store dfu state at 8 bits.Sure, but why not make the buffer u8 ?
The req->buf is a member of usb_request defined at gadget.h.
It represents the request from USB. I cannot guarantee, that we will always regard data pointed by buf as u8. For flexibility of gadget usage it is safer to leave it as void pointer.
Quoted 29 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
drivers/usb/gadget/f_dfu.c new file +3
-0+ req->actual =sizeof (u8); +} +[...]
Quoted 11 lines
Quoted 10 lines
Quoted 8 lines
drivers/usb/gadget/f_dfu.c new file +7
-0+static int +dfu_prepare_strings (struct f_dfu *f_dfu,int n) +{ +struct dfu_entity *de =NULL ; +int i =0 ; + + f_dfu->strings = calloc(((n + 1) * sizeof(struct
usb_string)), 1);
calloc(n, 1)... that's the same asmalloc(), isn't it ?Quoted 7 lines
I now wonder how mine mind produced this :-)
Correct version:
f_dfu->strings=calloc(sizeof(struct usb_string), n + 1);I prefer calloc, since it delivers zeroed memory.
ok, that's better :)
[...]
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
Dear Lukasz Majewski,
[...]
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
Now ... this is ubercrazy ... can't this be made without this typecasting voodoo?
The problem is that
req->bufis a void pointer. And the goal is to store dfu state at 8 bits.
Quoted 7 lines
Quoted 1 line
Sure, but why not make the buffer u8 ?
The
req->bufis a member ofusb_requestdefined atgadget.h.It represents the request from USB. I cannot guarantee, that we will always regard data pointed by buf as u8. For flexibility of gadget usage it is safer to leave it as void pointer.
OK, then it's good :)
[...]
Best regards,
Marek Vasut
PATCH 3/7 dfu: DFU backend implementation
In reply to Lukasz MajewskiNew, separate driver at ./drivers/dfu has been added. It allows platform and storage independent operation of DFU.
--- Makefile | 1 + drivers/dfu/Makefile | 43 ++++++++ drivers/dfu/dfu.c | 259 ++++++++++++++++++++++++++++++++++++++++++++++++++ include/dfu.h | 99 +++++++++++++++++++ 4 files changed, 402 insertions(+), 0 deletions(-) create mode 100644 drivers/dfu/Makefile create mode 100644 drivers/dfu/dfu.c create mode 100644 include/dfu.h
Makefile +1 -0
@@ -271,6 +271,7 @@ LIBS += drivers/pci/libpci.o LIBS += drivers/pcmcia/libpcmcia.o LIBS += drivers/power/libpower.o LIBS += drivers/spi/libspi.o +LIBS += drivers/dfu/libdfu.o ifeq ($(CPU),mpc83xx) LIBS += drivers/qe/libqe.o LIBS += arch/powerpc/cpu/mpc8xxx/ddr/libddr.o
drivers/dfu/Makefile new file +43 -0
43 lines not on this page · raw message
drivers/dfu/dfu.c new file +259 -0
259 lines not on this page · raw message
include/dfu.h new file +99 -0
99 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH 3/7 dfu: DFU backend implementation
Dear Lukasz Majewski,
Quoted 7 lines
New, separate driver at
./drivers/dfuhas been added. It allows platform and storage independent operation of DFU.Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
Quoted 19 lines
drivers/dfu/dfu.c new file +19
-0+#include <common.h> +#include <malloc.h> +#include <mmc.h> +#include <fat.h> +#include <dfu.h> +#include <linux/list.h> +#include <linux/compiler.h> + +static LIST_HEAD (dfu_list); +static int dfu_alt_num; + +static int dfu_find_alt_num (char *s) +{ +int i =0 ; + +for (; *s; s++) +if (*s ==';' ) + i++; +
drivers/dfu/dfu.c line 51
Quoted 10 lines
drivers/dfu/dfu.c new file +10
-0+return ++i; +} + +static char *dfu_extract_entity (char ** env) +{ +char *s = *env; + +strsep (env,";" ); +return s; +}
Shall we not make these all generic? They seem to be quite helpful components.
Quoted 5 lines
drivers/dfu/dfu.c new file +5
-0+ +char *dfu_extract_token (char ** e,int *n) +{ +char *st = *e; +
drivers/dfu/dfu.c line 66
Quoted 10 lines
drivers/dfu/dfu.c new file +10
-0+debug ("%s: %s\n" , __func__, st); + +strsep (e," " ); + *n = *e - st; + +return st; +} + +static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE) + dfu_buf[DFU_DATA_BUF_SIZE ];
Can we not stack-allocate it with ALLOC_CACHE_ALIGN_BUFFER()?
[...]
Quoted 5 lines
include/dfu.h new file +0
-0
[...]
include/dfu.h line 71
Quoted 10 lines
include/dfu.h new file +10
-0+struct dfu_entity { +char name[DFU_NAME_SIZE ]; +int alt; +void *dev_private; +int dev_num; +enum dfu_device_type dev_type; +enum dfu_layout layout; + +union { +struct mmc_internal_data mmc;
This union seems redundant ;-)
[...]
PATCH 3/7 dfu: DFU backend implementation
Hi Marek,
Quoted 36 lines
Dear Lukasz Majewski,
Quoted 7 lines
New, separate driver at
./drivers/dfuhas been added. It allows platform and storage independent operation of DFU.Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
Quoted 24 lines
drivers/dfu/dfu.c new file +24
-0+#include <common.h> +#include <malloc.h> +#include <mmc.h> +#include <fat.h> +#include <dfu.h> +#include <linux/list.h> +#include <linux/compiler.h> + +static LIST_HEAD (dfu_list); +static int dfu_alt_num; + +static int dfu_find_alt_num (char *s) +{ +int i =0 ; + +for (; *s; s++) +if (*s ==';' ) + i++; + +return ++i; +} + +static char *dfu_extract_entity (char ** env) +{
Quoted 8 lines
drivers/dfu/dfu.c line 51
Quoted 5 lines
drivers/dfu/dfu.c new file +5
-0+char *s = *env; + +strsep (env,";" ); +return s; +}Shall we not make these all generic? They seem to be quite helpful components.
It is a good topic for a discussion if those functions shall be moved to ./lib/string.c.
I regarded them as a "little" helper functions for parsing DFU alt setting env variable. Those are very short and build with methods exported from string.c
Quoted 10 lines
Quoted 10 lines
drivers/dfu/dfu.c new file +9
-0+ +char *dfu_extract_token (char ** e,int *n) +{ +char *st = *e; + +debug ("%s: %s\n" , __func__, st); + +strsep (e," " ); + *n = *e - st;
Quoted 8 lines
drivers/dfu/dfu.c line 66
Quoted 6 lines
drivers/dfu/dfu.c new file +6
-0+ +return st; +} + +static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE) + dfu_buf[DFU_DATA_BUF_SIZE ];Can we not stack-allocate it with
ALLOC_CACHE_ALIGN_BUFFER()?
The dfu_buf is 4 MiB (this is the size of DFU_DATA_BUF_SIZE). I don't think, that allocating it on the stack (for stack allocation the ALLOC_CACHE_ALIGN_BUFFER() is designed) is a good idea.
Quoted 11 lines
[...]
Quoted 5 lines
include/dfu.h new file +0
-0[...]
Quoted 12 lines
include/dfu.h line 71
Quoted 10 lines
include/dfu.h new file +10
-0+struct dfu_entity { +char name[DFU_NAME_SIZE ]; +int alt; +void *dev_private; +int dev_num; +enum dfu_device_type dev_type; +enum dfu_layout layout; + +union { +struct mmc_internal_data mmc;This union seems redundant ;-)
Good point :-), but I predict, that DFU will be used to program other memory types (OneNAND, or NAND). To support those, one needs to extend the union with e.g struct onenand_internal_data onenand.
Since we don't have so many memory types, I think that union usage is acceptable.
Quoted 2 lines
[...]
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH 3/7 dfu: DFU backend implementation
Dear Lukasz Majewski,
Quoted 47 lines
Hi Marek,
Quoted 36 lines
Dear Lukasz Majewski,
Quoted 7 lines
New, separate driver at
./drivers/dfuhas been added. It allows platform and storage independent operation of DFU.Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
Quoted 24 lines
drivers/dfu/dfu.c new file +24
-0+#include <common.h> +#include <malloc.h> +#include <mmc.h> +#include <fat.h> +#include <dfu.h> +#include <linux/list.h> +#include <linux/compiler.h> + +static LIST_HEAD (dfu_list); +static int dfu_alt_num; + +static int dfu_find_alt_num (char *s) +{ +int i =0 ; + +for (; *s; s++) +if (*s ==';' ) + i++; + +return ++i; +} + +static char *dfu_extract_entity (char ** env) +{Quoted 8 lines
drivers/dfu/dfu.c line 51
Quoted 5 lines
drivers/dfu/dfu.c new file +5
-0+char *s = *env; + +strsep (env,";" ); +return s; +}Shall we not make these all generic? They seem to be quite helpful components.
Quoted 5 lines
It is a good topic for a discussion if those functions shall be moved to
./lib/string.c.
I regarded them as a "little" helper functions for parsing DFU alt setting env variable. Those are very short and build with methods exported fromstring.c
Good point
Quoted 18 lines
Quoted 9 lines
Quoted 9 lines
drivers/dfu/dfu.c new file +9
-0+ +char *dfu_extract_token (char ** e,int *n) +{ +char *st = *e; + +debug ("%s: %s\n" , __func__, st); + +strsep (e," " ); + *n = *e - st;Quoted 8 lines
drivers/dfu/dfu.c line 66
Quoted 6 lines
drivers/dfu/dfu.c new file +6
-0+ +return st; +} + +static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE) + dfu_buf[DFU_DATA_BUF_SIZE ];Can we not stack-allocate it with
ALLOC_CACHE_ALIGN_BUFFER()?
Quoted 3 lines
The
dfu_bufis 4 MiB (this is the size ofDFU_DATA_BUF_SIZE). I don't think, that allocating it on the stack (for stack allocation theALLOC_CACHE_ALIGN_BUFFER()is designed) is a good idea.
Heh, agreed :-)
Quoted 23 lines
Quoted 10 lines
[...]
Quoted 5 lines
include/dfu.h new file +0
-0[...]
Quoted 12 lines
include/dfu.h line 71
Quoted 10 lines
include/dfu.h new file +10
-0+struct dfu_entity { +char name[DFU_NAME_SIZE ]; +int alt; +void *dev_private; +int dev_num; +enum dfu_device_type dev_type; +enum dfu_layout layout; + +union { +struct mmc_internal_data mmc;This union seems redundant ;-)
Quoted 6 lines
Good point :-), but I predict, that DFU will be used to program other memory types (OneNAND, or NAND). To support those, one needs to extend the union with e.g struct
onenand_internal_dataonenand.Since we don't have so many memory types, I think that union usage is acceptable.
And will those pieces be implemented any soon ? :)
Quoted 1 line
Quoted 1 line
[...]
Best regards,
Marek Vasut
PATCH 3/7 dfu: DFU backend implementation
Hi Marek,
Quoted 105 lines
Dear Lukasz Majewski,
Quoted 47 lines
Hi Marek,
Quoted 36 lines
Dear Lukasz Majewski,
Quoted 7 lines
New, separate driver at
./drivers/dfuhas been added. It allows platform and storage independent operation of DFU.Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
Quoted 24 lines
drivers/dfu/dfu.c new file +24
-0+#include <common.h> +#include <malloc.h> +#include <mmc.h> +#include <fat.h> +#include <dfu.h> +#include <linux/list.h> +#include <linux/compiler.h> + +static LIST_HEAD (dfu_list); +static int dfu_alt_num; + +static int dfu_find_alt_num (char *s) +{ +int i =0 ; + +for (; *s; s++) +if (*s ==';' ) + i++; + +return ++i; +} + +static char *dfu_extract_entity (char ** env) +{Quoted 8 lines
drivers/dfu/dfu.c line 51
Quoted 5 lines
drivers/dfu/dfu.c new file +5
-0+char *s = *env; + +strsep (env,";" ); +return s; +}Shall we not make these all generic? They seem to be quite helpful components.
Quoted 5 lines
It is a good topic for a discussion if those functions shall be moved to
./lib/string.c.
I regarded them as a "little" helper functions for parsing DFU alt setting env variable. Those are very short and build with methods exported fromstring.cGood point
Quoted 19 lines
Quoted 10 lines
Quoted 10 lines
drivers/dfu/dfu.c new file +10
-0+ +char *dfu_extract_token (char ** e,int *n) +{ +char *st = *e; + +debug ("%s: %s\n" , __func__, st); + +strsep (e," " ); + *n = *e - st; +Quoted 8 lines
Quoted 6 lines
drivers/dfu/dfu.c new file +5
-0+return st; +} + +static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE) +dfu_buf[DFU_DATA_BUF_SIZE];
Can we not stack-allocate it with
ALLOC_CACHE_ALIGN_BUFFER()?Quoted 3 lines
The
dfu_bufis 4 MiB (this is the size ofDFU_DATA_BUF_SIZE). I don't think, that allocating it on the stack (for stack allocation theALLOC_CACHE_ALIGN_BUFFER()is designed) is a good idea.Heh, agreed :-)
Quoted 23 lines
Quoted 22 lines
[...]
Quoted 5 lines
include/dfu.h new file +0
-0[...]
include/dfu.h line 71
Quoted 10 lines
include/dfu.h new file +10
-0+struct dfu_entity { +char name[DFU_NAME_SIZE ]; +int alt; +void *dev_private; +int dev_num; +enum dfu_device_type dev_type; +enum dfu_layout layout; + +union { +struct mmc_internal_data mmc;This union seems redundant ;-)
Quoted 8 lines
Quoted 6 lines
Good point :-), but I predict, that DFU will be used to program other memory types (OneNAND, or NAND). To support those, one needs to extend the union with e.g struct
onenand_internal_dataonenand.Since we don't have so many memory types, I think that union usage is acceptable.
And will those pieces be implemented any soon ? :)
:-). Since I'm the OneNAND custodian I shall keep in the back of my head, that support for this memory is important :-)
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
[...]
Best regards,
Marek Vasut
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH 3/7 dfu: DFU backend implementation
Dear Lukasz Majewski,
[...]
Quoted 6 lines
Quoted 2 lines
And will those pieces be implemented any soon ? :)
:
:-). Since I'm the OneNAND custodian I shall keep in the back of myhead, that support for this memory is important :-)
Good, will look forward to it :)
Best regards,
Marek Vasut
PATCH 3/7 dfu: DFU backend implementation
In reply to Lukasz Majewskidrivers/dfu/dfu.c line 148
Quoted 2 lines · On Tuesday 03 July 2012 05:38:07 Lukasz Majewski wrote:
drivers/dfu/dfu.c new file +2
-0+puts ("UPLOAD ... done\n" ); +puts ("Ctrl+C to exit ...\n" );
combine into a single puts() ?
drivers/dfu/dfu.c line 167
Quoted 10 lines
drivers/dfu/dfu.c new file +10
-0+static int dfu_fill_entity (struct dfu_entity *dfu,char * s,int alt, +char *interface,int num) +{ +char *st =NULL ; +int n =0 ; + +debug ("%s: %s interface: %s num: %d\n" , __func__, s, interface, num); + + st =dfu_extract_token (&s, &n); +strncpy ((char *) &dfu->name, st, n);
what's with the pointless cast ? just do:
strncpy(dfu->name, st, n);
also, "n" here is wrong. it should be sizeof(dfu->name), not (presumably) the length of st. considering this is the 2nd time i noticed this bug in the dfu patchset, you might want to do a grep on your patches to see if your other string related usage is wrong.
drivers/dfu/dfu.c line 209
Quoted 3 lines
drivers/dfu/dfu.c new file +3
-0+void dfu_free_entities (void ) +{ +struct dfu_entity *dfu =NULL , *p =NULL ;
no point in assigning to NULL here
Quoted 1 line
+static char *dfu_get_dev_type(enum
dfu_device_typet)
static const char *...
Review
Quoted 2 lines
(quoted diff) +2
-0+{ + static char *dev_t[] = {NULL, "MMC", "ONENAND", "NAND" };
static const char * const dev_t[] = {...}
Quoted 1 line
+static char *dfu_get_layout(enum
dfu_device_typel)
static const char *...
Review
Quoted 2 lines
(quoted diff) +2
-0+{ + static char *dfu_layout[] = {NULL, "RAW_ADDR", "FAT", "EXT" };
static const char * const dfu_layout[] = {...}
drivers/dfu/dfu.c line 233
Quoted 3 lines
drivers/dfu/dfu.c new file +3
-0+void dfu_show_entities (void ) +{ +struct dfu_entity *dfu =NULL ;
no point in assigning to NULL
drivers/dfu/dfu.c line 251
Quoted 3 lines
drivers/dfu/dfu.c new file +3
-0+struct dfu_entity *dfu_get_entity (int alt) +{ +struct dfu_entity *dfu =NULL ;
no point in assigning to NULL
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120720/97ce9d54/attachment.pgp>
PATCH 3/7 dfu: DFU backend implementation
Dear Mike Frysinger,
Quoted 5 lines · On Tuesday 03 July 2012 05:38:07 Lukasz Majewski wrote:
drivers/dfu/dfu.c line 148
Quoted 2 lines
drivers/dfu/dfu.c new file +2
-0+puts ("UPLOAD ... done\n" ); +puts ("Ctrl+C to exit ...\n" );combine into a single
puts()?
Ok, will be done
Quoted 14 lines
drivers/dfu/dfu.c line 167
Quoted 12 lines
+static int dfu_fill_entity(struct
dfu_entity*dfu, char* s, int alt,drivers/dfu/dfu.c new file +6
-0+ char *interface, int num) +{ + char *st = NULL; +int n =0 ; + + debug("%s: %s interface: %s num: %d\n", __func__, s,interface, num); +
drivers/dfu/dfu.c new file +2
-0+ st =dfu_extract_token (&s, &n); +strncpy ((char *) &dfu->name, st, n);what's with the pointless cast ? just do:
Quoted 1 line
strncpy(dfu->name, st, n);
Yes, you are right.
Quoted 5 lines
also, "n" here is wrong. it should be
sizeof(dfu->name), not (presumably) the length of st. considering this is the 2nd time i noticed this bug in the dfu patchset, you might want to do a grep on your patches to see if your other string related usage is wrong.
I will double-check the string operations.
Quoted 6 lines
drivers/dfu/dfu.c line 209
Quoted 4 lines
drivers/dfu/dfu.c new file +3
-0+void dfu_free_entities (void ) +{ +struct dfu_entity *dfu =NULL , *p =NULL ;no point in assigning to NULL here
Will remove.
Quoted 4 lines
Quoted 2 lines
+static char *dfu_get_dev_type(enum
dfu_device_typet)static const char *...
Will correct.
Quoted 5 lines
Review
Quoted 3 lines
(quoted diff) +2
-0+{ + static char *dev_t[] = {NULL, "MMC", "ONENAND", "NAND" };static const char * const dev_t[] = {...}
Ok
Quoted 5 lines
Quoted 2 lines
+static char *dfu_get_layout(enum
dfu_device_typel)static const char *...
Ok
Quoted 6 lines
Quoted 3 lines
(quoted diff) +2
-0+{ + static char *dfu_layout[] = {NULL, "RAW_ADDR", "FAT","EXT" };
static const char * const dfu_layout[] = {...}
OK
Quoted 5 lines
drivers/dfu/dfu.c line 233
Quoted 3 lines
drivers/dfu/dfu.c new file +3
-0+void dfu_show_entities (void ) +{ +struct dfu_entity *dfu =NULL ;no point in assigning to NULL
OK
Quoted 6 lines
drivers/dfu/dfu.c line 251
Quoted 4 lines
drivers/dfu/dfu.c new file +3
-0+struct dfu_entity *dfu_get_entity (int alt) +{ +struct dfu_entity *dfu =NULL ;no point in assigning to NULL
OK
Quoted 1 line
-mike
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH 4/7 dfu: MMC specific routines for DFU operation
In reply to Lukasz MajewskiSupport for MMC storage devices to work with DFU framework.
--- drivers/dfu/Makefile | 1 + drivers/dfu/dfu_mmc.c | 126 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 127 insertions(+), 0 deletions(-) create mode 100644 drivers/dfu/dfu_mmc.c
drivers/dfu/Makefile +1 -0
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk LIB = $(obj)libdfu.o COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o +COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o SRCS := $(COBJS-y:.o=.c) OBJS := $(addprefix $(obj),$(COBJS-y))
drivers/dfu/dfu_mmc.c new file +126 -0
126 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH 4/7 dfu: MMC specific routines for DFU operation
Dear Lukasz Majewski,
Quoted 6 lines
Support for MMC storage devices to work with DFU framework.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
Quoted 17 lines
drivers/dfu/dfu_mmc.c new file +17
-0+ +#include <common.h> +#include <malloc.h> +#include <dfu.h> + +int dfu_write_medium_mmc (struct dfu_entity *dfu,void *buf,long *len) +{ +ALLOC_CACHE_ALIGN_BUFFER (char, cmd_buf,DFU_CMD_BUF_SIZE ); + +memset (cmd_buf,'\0' ,sizeof (cmd_buf)); + +switch (dfu->layout) { +case RAW_ADDR : +sprintf (cmd_buf,"mmc write 0x%x %x %x" , (unsigned int ) buf, + dfu->data.mmc.lba_start, dfu->data.mmc.lba_size); +break ; +case FAT :
drivers/dfu/dfu_mmc.c line 48
Quoted 10 lines
drivers/dfu/dfu_mmc.c new file +10
-0+sprintf (cmd_buf,"fatwrite mmc %d:%d 0x%x %s %lx" , + dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int ) buf, dfu->name, *len); +break ; +default : +printf ("%s: Wrong layout!\n" , __func__); + } + +debug ("%s: %s 0x%p\n" , __func__, cmd_buf, cmd_buf); +run_command (cmd_buf,0 );
Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
[...]
Best regards,
Marek Vasut
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Quoted 33 lines · Marek Vasut
Dear Lukasz Majewski,
Quoted 6 lines
Support for MMC storage devices to work with DFU framework.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
Quoted 22 lines
drivers/dfu/dfu_mmc.c new file +22
-0+ +#include <common.h> +#include <malloc.h> +#include <dfu.h> + +int dfu_write_medium_mmc (struct dfu_entity *dfu,void *buf,long *len) +{ +ALLOC_CACHE_ALIGN_BUFFER (char, cmd_buf,DFU_CMD_BUF_SIZE ); + +memset (cmd_buf,'\0' ,sizeof (cmd_buf)); + +switch (dfu->layout) { +case RAW_ADDR : +sprintf (cmd_buf,"mmc write 0x%x %x %x" , (unsigned int ) buf, + dfu->data.mmc.lba_start, dfu->data.mmc.lba_size); +break ; +case FAT : +sprintf (cmd_buf,"fatwrite mmc %d:%d 0x%x %s %lx" , + dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int ) buf, dfu->name, *len); +break ; +default :
Quoted 8 lines
drivers/dfu/dfu_mmc.c line 48
Quoted 5 lines
drivers/dfu/dfu_mmc.c new file +5
-0+printf ("%s: Wrong layout!\n" , __func__); + } + +debug ("%s: %s 0x%p\n" , __func__, cmd_buf, cmd_buf); +run_command (cmd_buf,0 );Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
Are they really simple? There's a few other places we do this, and so long as it's documented that DFU depends on CONFIG_FAT_WRITE for writing to fat and so forth.
Signature · 1 line
Tom
PATCH 4/7 dfu: MMC specific routines for DFU operation
Dear Tom Rini,
Quoted 43 lines · Marek Vasut
Quoted 33 lines
Dear Lukasz Majewski,
Quoted 6 lines
Support for MMC storage devices to work with DFU framework.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
Quoted 22 lines
drivers/dfu/dfu_mmc.c new file +22
-0+ +#include <common.h> +#include <malloc.h> +#include <dfu.h> + +int dfu_write_medium_mmc (struct dfu_entity *dfu,void *buf,long *len) +{ +ALLOC_CACHE_ALIGN_BUFFER (char, cmd_buf,DFU_CMD_BUF_SIZE ); + +memset (cmd_buf,'\0' ,sizeof (cmd_buf)); + +switch (dfu->layout) { +case RAW_ADDR : +sprintf (cmd_buf,"mmc write 0x%x %x %x" , (unsigned int ) buf, + dfu->data.mmc.lba_start, dfu->data.mmc.lba_size); +break ; +case FAT : +sprintf (cmd_buf,"fatwrite mmc %d:%d 0x%x %s %lx" , + dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int ) buf, dfu->name, *len); +break ; +default :Quoted 8 lines
drivers/dfu/dfu_mmc.c line 48
Quoted 5 lines
drivers/dfu/dfu_mmc.c new file +5
-0+printf ("%s: Wrong layout!\n" , __func__); + } + +debug ("%s: %s 0x%p\n" , __func__, cmd_buf, cmd_buf); +run_command (cmd_buf,0 );Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
Quoted 3 lines
Are they really simple? There's a few other places we do this, and so long as it's documented that DFU depends on
CONFIG_FAT_WRITEfor writing to fat and so forth.
Well ain't it easier to call fat_write() or similar?
Best regards,
Marek Vasut
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Quoted 45 lines · Marek Vasut
Dear Tom Rini,
Quoted 43 lines · Marek Vasut
Quoted 41 lines
Dear Lukasz Majewski,
Quoted 6 lines
Support for MMC storage devices to work with DFU framework.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
Quoted 17 lines
drivers/dfu/dfu_mmc.c new file +17
-0+ +#include <common.h> +#include <malloc.h> +#include <dfu.h> + +int dfu_write_medium_mmc (struct dfu_entity *dfu,void *buf,long *len) +{ +ALLOC_CACHE_ALIGN_BUFFER (char, cmd_buf,DFU_CMD_BUF_SIZE ); + +memset (cmd_buf,'\0' ,sizeof (cmd_buf)); + +switch (dfu->layout) { +case RAW_ADDR : +sprintf (cmd_buf,"mmc write 0x%x %x %x" , (unsigned int ) buf, + dfu->data.mmc.lba_start, dfu->data.mmc.lba_size); +break ; +case FAT :drivers/dfu/dfu_mmc.c line 48
Quoted 10 lines
drivers/dfu/dfu_mmc.c new file +10
-0+sprintf (cmd_buf,"fatwrite mmc %d:%d 0x%x %s %lx" , + dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int ) buf, dfu->name, *len); +break ; +default : +printf ("%s: Wrong layout!\n" , __func__); + } + +debug ("%s: %s 0x%p\n" , __func__, cmd_buf, cmd_buf); +run_command (cmd_buf,0 );Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
Quoted 5 lines
Quoted 3 lines
Are they really simple? There's a few other places we do this, and so long as it's documented that DFU depends on
CONFIG_FAT_WRITEfor writing to fat and so forth.Well ain't it easier to call
fat_write()or similar?
Assuming that most of the logic in do_fat_fswrite is needed, no. And I think a good portion of it is, at first glance at least.
Signature · 1 line
Tom
PATCH 4/7 dfu: MMC specific routines for DFU operation
Dear Tom Rini,
[...]
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
drivers/dfu/dfu_mmc.c line 48
Quoted 2 lines
drivers/dfu/dfu_mmc.c new file +2
-0+debug ("%s: %s 0x%p\n" , __func__, cmd_buf, cmd_buf); +run_command (cmd_buf,0 );Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Are they really simple? There's a few other places we do this, and so long as it's documented that DFU depends on
CONFIG_FAT_WRITEfor writing to fat and so forth.Well ain't it easier to call
fat_write()or similar?Assuming that most of the logic in
do_fat_fswriteis needed, no. And I think a good portion of it is, at first glance at least.
Abstracting it out into a function won't cut it?
Best regards,
Marek Vasut
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Quoted 14 lines · Marek Vasut
Dear Tom Rini,
[...]
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
drivers/dfu/dfu_mmc.c line 48
Quoted 2 lines
drivers/dfu/dfu_mmc.c new file +2
-0+debug ("%s: %s 0x%p\n" , __func__, cmd_buf, cmd_buf); +run_command (cmd_buf,0 );Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
Are they really simple? There's a few other places we do this, and so long as it's documented that DFU depends on
CONFIG_FAT_WRITEfor writing to fat and so forth.
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
Well ain't it easier to call
fat_write()or similar?Assuming that most of the logic in
do_fat_fswriteis needed, no. And I think a good portion of it is, at first glance at least.Abstracting it out into a function won't cut it?
My inclination would be to say that seems a bit sillier than just using run_command(...) to call the existing command.
Signature · 1 line
Tom
PATCH 4/7 dfu: MMC specific routines for DFU operation
Quoted 17 lines · Tom Rini
Quoted 16 lines · Marek Vasut
Dear Tom Rini,
[...]
Quoted 12 lines
Quoted 11 lines
Quoted 9 lines
Quoted 5 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ debug("%s: %s 0x%p\n", __func__, cmd_buf, cmd_buf); + run_command(cmd_buf, 0);Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
Are they really simple? There's a few other places we do this, and so long as it's documented that DFU depends on
CONFIG_FAT_WRITEfor writing to fat and so forth.Well ain't it easier to call
fat_write()or similar?
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Assuming that most of the logic in
do_fat_fswriteis needed, no. And I think a good portion of it is, at first glance at least.Abstracting it out into a function won't cut it?
My inclination would be to say that seems a bit sillier than just using
run_command(...)to call the existing command.
Abstracting into a function definitely means the compiler will be able to type-check all the arguments to the function. Is the same true using run_command; I assume everything gets serialized to an array of strings and hence any validation is deferred until run-time then?
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Quoted 23 lines · Stephen Warren
Quoted 22 lines · Tom Rini
Quoted 20 lines · Marek Vasut
Dear Tom Rini,
[...]
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ debug("%s: %s 0x%p\n", __func__, cmd_buf, cmd_buf); + run_command(cmd_buf, 0);Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Are they really simple? There's a few other places we do this, and so long as it's documented that DFU depends on
CONFIG_FAT_WRITEfor writing to fat and so forth.Well ain't it easier to call
fat_write()or similar?Assuming that most of the logic in
do_fat_fswriteis needed, no. And I think a good portion of it is, at first glance at least.Abstracting it out into a function won't cut it?
Quoted 7 lines
Quoted 2 lines
My inclination would be to say that seems a bit sillier than just using
run_command(...)to call the existing command.Abstracting into a function definitely means the compiler will be able to type-check all the arguments to the function. Is the same true using
run_command; I assume everything gets serialized to an array of strings and hence any validation is deferred until run-time then?
string is constructed with sprintf and that gives us some type checking. Only cast today is buf to an unsigned int. And the information either comes from tools that should/must have done sanity checking or from the 'dfu' command which again should (didn't verify that patch yet) have done sanity checking to get us this far.
Signature · 1 line
Tom
PATCH 4/7 dfu: MMC specific routines for DFU operation
Quoted 32 lines · Tom Rini
Quoted 23 lines · Stephen Warren
Quoted 22 lines · Tom Rini
Quoted 20 lines · Marek Vasut
Dear Tom Rini,
[...]
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ debug("%s: %s 0x%p\n", __func__, cmd_buf, cmd_buf); + run_command(cmd_buf, 0);Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Are they really simple? There's a few other places we do this, and so long as it's documented that DFU depends on
CONFIG_FAT_WRITEfor writing to fat and so forth.Well ain't it easier to call
fat_write()or similar?Assuming that most of the logic in
do_fat_fswriteis needed, no. And I think a good portion of it is, at first glance at least.Abstracting it out into a function won't cut it?
Quoted 7 lines
Quoted 2 lines
My inclination would be to say that seems a bit sillier than just using
run_command(...)to call the existing command.Abstracting into a function definitely means the compiler will be able to type-check all the arguments to the function. Is the same true using
run_command; I assume everything gets serialized to an array of strings and hence any validation is deferred until run-time then?
Quoted 5 lines
string is constructed with sprintf and that gives us some type checking. Only cast today is buf to an unsigned int. And the information either comes from tools that should/must have done sanity checking or from the 'dfu' command which again should (didn't verify that patch yet) have done sanity checking to get us this far.
So that checks the parameters against the sprintf format string, but what checks that you chose the right format string for the command?
PATCH 4/7 dfu: MMC specific routines for DFU operation
In reply to Tom RiniDear Tom Rini,
Quoted 17 lines · Marek Vasut
Quoted 16 lines
Dear Tom Rini,
[...]
Quoted 12 lines
Quoted 11 lines
Quoted 9 lines
Quoted 5 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ debug("%s: %s 0x%p\n", __func__, cmd_buf, cmd_buf); + run_command(cmd_buf, 0);Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
Are they really simple? There's a few other places we do this, and so long as it's documented that DFU depends on
CONFIG_FAT_WRITEfor writing to fat and so forth.Well ain't it easier to call
fat_write()or similar?
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
Assuming that most of the logic in
do_fat_fswriteis needed, no. And I think a good portion of it is, at first glance at least.Abstracting it out into a function won't cut it?
My inclination would be to say that seems a bit sillier than just using
run_command(...)to call the existing command.
Whose's syntax will likely soon change, breaking all this :-(
Best regards,
Marek Vasut
PATCH 4/7 dfu: MMC specific routines for DFU operation
Quoted 18 lines · On Tuesday 03 July 2012 20:13:37 Marek Vasut wrote:
Dear Tom Rini,
Quoted 17 lines · Marek Vasut
Quoted 16 lines
Dear Tom Rini,
Quoted 14 lines
Quoted 11 lines
Quoted 9 lines
Quoted 5 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ debug("%s: %s 0x%p\n", __func__, cmd_buf, cmd_buf); + run_command(cmd_buf, 0);Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
Are they really simple? There's a few other places we do this, and so long as it's documented that DFU depends on
CONFIG_FAT_WRITEfor writing to fat and so forth.Well ain't it easier to call
fat_write()or similar?Assuming that most of the logic in
do_fat_fswriteis needed, no. And I think a good portion of it is, at first glance at least.
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
Abstracting it out into a function won't cut it?
My inclination would be to say that seems a bit sillier than just using
run_command(...)to call the existing command.Whose's syntax will likely soon change, breaking all this :-(
and would be pretty much impossible to detect at compile time. extending the API for code to call is the right answer ... abusing the shell at runtime from other code should be an absolute last resort.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120720/d37ea667/attachment.pgp>
PATCH 4/7 dfu: MMC specific routines for DFU operation
In reply to Marek VasutHi Marek,
Quoted 48 lines
Dear Tom Rini,
Quoted 46 lines · Marek Vasut
Quoted 44 lines
Dear Lukasz Majewski,
Quoted 6 lines
Support for MMC storage devices to work with DFU framework.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
Quoted 21 lines
drivers/dfu/dfu_mmc.c new file +6
-0+ +#include <common.h> +#include <malloc.h> +#include <dfu.h> + +int dfu_write_medium_mmc(struct dfu_entity *dfu, void *buf,long *len) +{
(quoted diff) +1
-0+ ALLOC_CACHE_ALIGN_BUFFER(char, cmd_buf,
DFU_CMD_BUF_SIZE); +drivers/dfu/dfu_mmc.c new file +5
-0+memset (cmd_buf,'\0' ,sizeof (cmd_buf)); + +switch (dfu->layout) { +case RAW_ADDR : + sprintf(cmd_buf, "mmc write 0x%x %x %x",(unsigned int) buf,
(quoted diff) +1
-0+ dfu->data.mmc.lba_start,
dfu->data.mmc.lba_size);drivers/dfu/dfu_mmc.c new file +3
-0+break ; +case FAT : + sprintf(cmd_buf, "fatwrite mmc %d:%d 0x%x %s%lx",
drivers/dfu/dfu_mmc.c line 48
Quoted 9 lines
drivers/dfu/dfu_mmc.c new file +9
-0+ dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int) buf, dfu->name, *len); +break ; +default : +printf ("%s: Wrong layout!\n" , __func__); + } + +debug ("%s: %s 0x%p\n" , __func__, cmd_buf, cmd_buf); +run_command (cmd_buf,0 );Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
Quoted 6 lines
Quoted 3 lines
Are they really simple? There's a few other places we do this, and so long as it's documented that DFU depends on
CONFIG_FAT_WRITEfor writing to fat and so forth.Well ain't it easier to call
fat_write()or similar?
I've decided to use run_command on a purpose.
This call provides clean and reliable API. It is very unlikely that the mmc write <dev> <addr> <start> <size> command will change (or any other).
On the other hand the fields of struct mmc are changed from time to time.
Moreover, mmc drivers are also a subject to change (like adding dw_mmc recently).
Using run_command also takes the burden of mmc_init() related calls.
Of course the run_command's downside is the speed of execution. But is it so important when one considers, the firmware update?
Side note: DFU uses only EP0 (for transfer and configuration), so this is rather slow communication link.
I'm open for discussion.
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH 4/7 dfu: MMC specific routines for DFU operation
Dear Lukasz Majewski,
[...]
Quoted 9 lines
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
Are they really simple? There's a few other places we do this, and so long as it's documented that DFU depends on
CONFIG_FAT_WRITEfor writing to fat and so forth.Well ain't it easier to call
fat_write()or similar?
Quoted 7 lines
I've decided to use
run_commandon a purpose.This call provides clean and reliable API. It is very unlikely that the mmc write <dev> <addr> <start> <size> command will change (or any other).
On the other hand the fields of struct mmc are changed from time to time.
I'm afraid it might change with the driver model soon.
Quoted 6 lines
Moreover, mmc drivers are also a subject to change (like adding
dw_mmcrecently).
Usingrun_commandalso takes the burden ofmmc_init()related calls.Of course the run_command's downside is the speed of execution. But is it so important when one considers, the firmware update?
But as Stephen pointed out, the type checking is much better when used as function.
Quoted 2 lines
Side note: DFU uses only EP0 (for transfer and configuration), so this is rather slow communication link.
I see
Quoted 1 line
I'm open for discussion.
Yes please, I think I started some bad flamewar in here :/
Best regards,
Marek Vasut
PATCH 4/7 dfu: MMC specific routines for DFU operation
Hi Marek,
Quoted 15 lines
Dear Lukasz Majewski,
[...]
Quoted 11 lines
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Holy Moly ... can we not make this into simple calls to those subsystems ? Instead invoking command is crazy ;-)
Are they really simple? There's a few other places we do this, and so long as it's documented that DFU depends on
CONFIG_FAT_WRITEfor writing to fat and so forth.Well ain't it easier to call
fat_write()or similar?I've decided to use
run_commandon a purpose.
Quoted 7 lines
Quoted 5 lines
This call provides clean and reliable API. It is very unlikely that the mmc write <dev> <addr> <start> <size> command will change (or any other).
On the other hand the fields of struct mmc are changed from time to time.I'm afraid it might change with the driver model soon.
You have probably more information than I about the driver model :-)
Since I know u-boot this API was stable. If it changes, I will adjust the sprintf :-)
Quoted 10 lines
Quoted 7 lines
Moreover, mmc drivers are also a subject to change (like adding
dw_mmcrecently).
Usingrun_commandalso takes the burden ofmmc_init()related calls.Of course the run_command's downside is the speed of execution. But is it so important when one considers, the firmware update?
But as Stephen pointed out, the type checking is much better when used as function.
Yes, I agree about the type check.
Contrary, the cmd_mmc.c code is not checking the correctness of passed data. It performs strncmp, then simple_strtoul and with this parameter callsmmc->block_dev.block_read(). For this command such behavior is acceptable.
Quoted 9 lines
Quoted 3 lines
Side note: DFU uses only EP0 (for transfer and configuration), so this is rather slow communication link.
I see
Quoted 1 line
I'm open for discussion.
Yes please, I think I started some bad flamewar in here :/
Maybe we come up with a better solution thanks to that :-).
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
In reply to Lukasz MajewskiSupport for u-boot's command line command "dfu <interface> <dev> [list]".
--- common/Makefile | 1 + common/cmd_dfu.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 82 insertions(+), 0 deletions(-) create mode 100644 common/cmd_dfu.c
common/Makefile +1 -0
@@ -186,6 +186,7 @@ COBJS-$(CONFIG_MENU) += menu.o COBJS-$(CONFIG_MODEM_SUPPORT) += modem.o COBJS-$(CONFIG_UPDATE_TFTP) += update.o COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o +COBJS-$(CONFIG_CMD_DFU) += cmd_dfu.o endif ifdef CONFIG_SPL_BUILD
common/cmd_dfu.c new file +81 -0
81 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
Dear Lukasz Majewski,
Quoted 6 lines
Support for u-boot's command line command "dfu <interface> <dev> [list]".
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
common/cmd_dfu.c line 42
Quoted 13 lines
common/cmd_dfu.c new file +13
-0+int do_dfu (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) +{ +char *str_env =NULL , *env_bkp =NULL ; +static char *s ="dfu" ; +int ret =0 ; + +if (argc <3 ) +return CMD_RET_USAGE ; + + str_env =getenv ("dfu_alt_info" ); +if (str_env ==NULL ) { +printf ("%s: \"dfu_alt_info\" env variable not defined!\n" , + __func__);
I was always curious if it's not possible to do something like
puts(__func__ "rest of string");
Maybe it'd help the overhead a bit? Certainly, it's beyond the scope of this patchset, I'm just curious :)
Review
Quoted 2 lines
(quoted diff) +2
-0+ return CMD_RET_FAILURE; + }
[...]
Best regards,
Marek Vasut
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
Hi Marek,
Quoted 29 lines
Dear Lukasz Majewski,
Quoted 7 lines
Support for u-boot's command line command "dfu <interface> <dev> [list]".
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
Quoted 13 lines
+int
do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])+{common/cmd_dfu.c new file +10
-0+char *str_env =NULL , *env_bkp =NULL ; +static char *s ="dfu" ; +int ret =0 ; + +if (argc <3 ) +return CMD_RET_USAGE ; + + str_env =getenv ("dfu_alt_info" ); +if (str_env ==NULL ) { + printf("%s: \"dfu_alt_info\" env variable notdefined!\n",
common/cmd_dfu.c line 42
Quoted 1 line
common/cmd_dfu.c new file +1
-0+ __func__);I was always curious if it's not possible to do something like
Quoted 4 lines
puts(__func__ "rest of string");Maybe it'd help the overhead a bit? Certainly, it's beyond the scope of this patchset, I'm just curious :)
It is a good idea, since many error/info messages are supposed to produce following output:
"dfu_write: Not enough space!"
Putting there the __func__ name would improve structure and speed up finding right place.
Quoted 8 lines
Review
Quoted 3 lines
(quoted diff) +2
-0+ return CMD_RET_FAILURE; + }[...]
Best regards,
Marek Vasut
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
Dear Lukasz Majewski,
Quoted 36 lines
Hi Marek,
Quoted 29 lines
Dear Lukasz Majewski,
Quoted 7 lines
Support for u-boot's command line command "dfu <interface> <dev> [list]".
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
[...]
Quoted 13 lines
+int
do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])+{common/cmd_dfu.c new file +10
-0+char *str_env =NULL , *env_bkp =NULL ; +static char *s ="dfu" ; +int ret =0 ; + +if (argc <3 ) +return CMD_RET_USAGE ; + + str_env =getenv ("dfu_alt_info" ); +if (str_env ==NULL ) { + printf("%s: \"dfu_alt_info\" env variable notdefined!\n",
common/cmd_dfu.c line 42
Quoted 1 line
common/cmd_dfu.c new file +1
-0+ __func__);I was always curious if it's not possible to do something like
Quoted 4 lines
puts(__func__ "rest of string");Maybe it'd help the overhead a bit? Certainly, it's beyond the scope of this patchset, I'm just curious :)
Quoted 7 lines
It is a good idea, since many error/info messages are supposed to produce following output:
"
dfu_write: Not enough space!"Putting there the
__func__name would improve structure and speed up finding right place.
And if you want to use even __LINE__, look up __stringify patch in the ML archives ;-)
Quoted 7 lines
Quoted 7 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ return CMD_RET_FAILURE; + }[...]
Best regards,
Marek Vasut
Best regards,
Marek Vasut
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
Quoted 5 lines · On Wednesday 04 July 2012 10:39:20 Marek Vasut wrote:
Quoted 2 lines
Putting there the
__func__name would improve structure and speed up finding right place.And if you want to use even
__LINE__, look up__stringifypatch in the ML archives ;-)
ugh, no, let's not use __LINE__ anywhere other than debug(). it has no business in code we ship as it is pointless bloated noise.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120720/4cdf7149/attachment.pgp>
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
Dear Mike Frysinger,
Quoted 9 lines · On Wednesday 04 July 2012 10:39:20 Marek Vasut wrote:
Quoted 5 lines
Quoted 2 lines
Putting there the
__func__name would improve structure and speed up finding right place.And if you want to use even
__LINE__, look up__stringifypatch in the ML archives ;-)ugh, no, let's not use
__LINE__anywhere other thandebug(). it has no business in code we ship as it is pointless bloated noise.
Helps find out the problematic place in code ...
Quoted 1 line
-mike
Best regards,
Marek Vasut
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
Quoted 5 lines · On Friday 20 July 2012 07:33:49 Marek Vasut wrote:
Dear Mike Frysinger,
Quoted 4 lines · On Wednesday 04 July 2012 10:39:20 Marek Vasut wrote:
Quoted 3 lines
Quoted 2 lines
Putting there the
__func__name would improve structure and speed up finding right place.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
And if you want to use even
__LINE__, look up__stringifypatch in the ML archives ;-)ugh, no, let's not use
__LINE__anywhere other thandebug(). it has no business in code we ship as it is pointless bloated noise.Helps find out the problematic place in code ...
except the code changes thus invalidating the line numbers, and how often are you putting the same string in multiple places that you can't easily coordinate where it came from ? if people are using the same exact string in multiple places, that sounds like a different problem.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120720/e9bf6f8a/attachment.pgp>
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
Dear Mike Frysinger,
Quoted 13 lines · On Friday 20 July 2012 07:33:49 Marek Vasut wrote:
Quoted 12 lines
Dear Mike Frysinger,
Quoted 9 lines · On Wednesday 04 July 2012 10:39:20 Marek Vasut wrote:
Quoted 5 lines
Quoted 2 lines
Putting there the
__func__name would improve structure and speed up finding right place.And if you want to use even
__LINE__, look up__stringifypatch in the ML archives ;-)ugh, no, let's not use
__LINE__anywhere other thandebug(). it has no business in code we ship as it is pointless bloated noise.
Quoted 6 lines
Quoted 1 line
Helps find out the problematic place in code ...
except the code changes thus invalidating the line numbers, and how often are you putting the same string in multiple places that you can't easily coordinate where it came from ? if people are using the same exact string in multiple places, that sounds like a different problem.
You can always replace the function names with macros, which expand in place. And then simply add __func__ __LINE__ __FILE__ etc.
Quoted 1 line
-mike
Best regards,
Marek Vasut
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
Quoted 15 lines · On Friday 20 July 2012 17:11:33 Marek Vasut wrote:
Dear Mike Frysinger,
Quoted 14 lines · On Friday 20 July 2012 07:33:49 Marek Vasut wrote:
Quoted 12 lines
Dear Mike Frysinger,
Quoted 9 lines · On Wednesday 04 July 2012 10:39:20 Marek Vasut wrote:
Quoted 5 lines
Quoted 2 lines
Putting there the
__func__name would improve structure and speed up finding right place.And if you want to use even
__LINE__, look up__stringifypatch in the ML archives ;-)ugh, no, let's not use
__LINE__anywhere other thandebug(). it has no business in code we ship as it is pointless bloated noise.Helps find out the problematic place in code ...
Quoted 7 lines
Quoted 4 lines
except the code changes thus invalidating the line numbers, and how often are you putting the same string in multiple places that you can't easily coordinate where it came from ? if people are using the same exact string in multiple places, that sounds like a different problem.
You can always replace the function names with macros, which expand in place. And then simply add
__func____LINE____FILE__etc.
if you wanted to add it while debugging, that's fine, but the point is that this doesn't belong in normal runtime images. it's even trivial to define such a macro:
#ifdef DEBUG
# define printf(fmt, args...) printf("%s:%s:%i: " fmt, __FILE__, __LINE__,
__func__, ## args)
#endif
(will obviously need a little more work to handle non-const fmt strings, but
you get the idea).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120721/832382c4/attachment.pgp>PATCH 5/7 dfu:cmd: Support for DFU u-boot command
Dear Mike Frysinger,
Quoted 24 lines · On Friday 20 July 2012 17:11:33 Marek Vasut wrote:
Quoted 23 lines
Dear Mike Frysinger,
Quoted 20 lines · On Friday 20 July 2012 07:33:49 Marek Vasut wrote:
Quoted 6 lines
Dear Mike Frysinger,
Quoted 4 lines · On Wednesday 04 July 2012 10:39:20 Marek Vasut wrote:
Quoted 3 lines
Quoted 2 lines
Putting there the
__func__name would improve structure and speed up finding right place.Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
And if you want to use even
__LINE__, look up__stringifypatch in the ML archives ;-)ugh, no, let's not use
__LINE__anywhere other thandebug(). it has no business in code we ship as it is pointless bloated noise.Helps find out the problematic place in code ...
except the code changes thus invalidating the line numbers, and how often are you putting the same string in multiple places that you can't easily coordinate where it came from ? if people are using the same exact string in multiple places, that sounds like a different problem.
Quoted 5 lines
Quoted 2 lines
You can always replace the function names with macros, which expand in place. And then simply add
__func____LINE____FILE__etc.if you wanted to add it while debugging, that's fine, but the point is that this doesn't belong in normal runtime images.
Well doh ...
Quoted 6 lines
it's even trivial to define
such a macro:
#ifdef DEBUG# define printf(fmt, args...) printf("%s:%s:%i: " fmt, __FILE__, __LINE__, __func__, ## args) #endif
Uh, now I'm not sure what you mean by this stuff above.
Quoted 3 lines
(will obviously need a little more work to handle non-const fmt strings, but you get the idea).
-mike
Best regards,
Marek Vasut
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
In reply to Marek VasutQuoted 16 lines · On Tuesday 03 July 2012 17:32:54 Marek Vasut wrote:
common/cmd_dfu.c line 42
Quoted 13 lines
common/cmd_dfu.c new file +13
-0+int do_dfu (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) +{ +char *str_env =NULL , *env_bkp =NULL ; +static char *s ="dfu" ; +int ret =0 ; + +if (argc <3 ) +return CMD_RET_USAGE ; + + str_env =getenv ("dfu_alt_info" ); +if (str_env ==NULL ) { +printf ("%s: \"dfu_alt_info\" env variable not defined!\n" , + __func__);I was always curious if it's not possible to do something like
Quoted 4 lines
puts(__func__ "rest of string");Maybe it'd help the overhead a bit? Certainly, it's beyond the scope of this patchset, I'm just curious :)
not anymore -- gcc disabled support for that sometime ago. and it's good they did as it causes more bloat than good. as soon as you do more than one statement, you get duplication. the string table will have:
"some_func: rest of string"
"some_func: boo"
"some_func: another message"
which takes up more space than:
"some_func" "%s: rest of string" "%s: boo" "%s: another message"
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120720/19f853eb/attachment.pgp>
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
Dear Mike Frysinger,
Quoted 29 lines · On Tuesday 03 July 2012 17:32:54 Marek Vasut wrote:
Quoted 16 lines
common/cmd_dfu.c line 42
Quoted 13 lines
common/cmd_dfu.c new file +13
-0+int do_dfu (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[]) +{ +char *str_env =NULL , *env_bkp =NULL ; +static char *s ="dfu" ; +int ret =0 ; + +if (argc <3 ) +return CMD_RET_USAGE ; + + str_env =getenv ("dfu_alt_info" ); +if (str_env ==NULL ) { +printf ("%s: \"dfu_alt_info\" env variable not defined!\n" , + __func__);I was always curious if it's not possible to do something like
Quoted 4 lines
puts(__func__ "rest of string");Maybe it'd help the overhead a bit? Certainly, it's beyond the scope of this patchset, I'm just curious :)
not anymore -- gcc disabled support for that sometime ago. and it's good they did as it causes more bloat than good. as soon as you do more than one statement, you get duplication. the string table will have:
"some_func: rest of string"
"some_func: boo"
"some_func: another message"
which takes up more space than:
Quoted 4 lines
"some_func" "%s: rest of string" "%s: boo" "%s: another message"
Good knowing this. I'd expect gcc would build some trie in there to optimize the size.
Quoted 1 line
-mike
Best regards,
Marek Vasut
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
In reply to Lukasz Majewskicommon/cmd_dfu.c
Quoted 4 lines · On Tuesday 03 July 2012 05:38:09 Lukasz Majewski wrote:
common/cmd_dfu.c new file +1
-0+int do_dfu (cmd_tbl_t *cmdtp,int flag,int argc,char *const argv[])
static
common/cmd_dfu.c line 32
Quoted 2 lines
common/cmd_dfu.c new file +2
-0+{ +char *str_env =NULL , *env_bkp =NULL ;
no need to assign NULL here. str_env should be const.
common/cmd_dfu.c line 33
Quoted 1 line
common/cmd_dfu.c new file +1
-0+static char *s ="dfu" ;
no need to declare this static
common/cmd_dfu.c line 34
Quoted 1 line
common/cmd_dfu.c new file +1
-0+int ret =0 ;
no need to init to 0
common/cmd_dfu.c line 56
Quoted 11 lines
common/cmd_dfu.c new file +11
-0+ env_bkp =strdup (str_env); + ret =dfu_config_entities (env_bkp, argv[1 ], + (int )simple_strtoul (argv[2 ],NULL ,10 )); +if (ret) +return CMD_RET_FAILURE ; + +if (strcmp (argv[3 ],"list" ) ==0 ) { +dfu_show_entities (); +dfu_free_entities (); +free (env_bkp); +return CMD_RET_SUCCESS ;
for these last three statements, you could just do "goto done" and put a done label below ...
common/cmd_dfu.c line 68
Quoted 2 lines
common/cmd_dfu.c new file +2
-0+exit: +g_dnl_cleanup ();
done:
common/cmd_dfu.c line 72
Quoted 4 lines
common/cmd_dfu.c new file +4
-0+dfu_free_entities (); +free (env_bkp); + +return CMD_RET_SUCCESS ;
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120720/7b1add72/attachment.pgp>
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
Dear Mike,
Quoted 8 lines · On Tuesday 03 July 2012 05:38:09 Lukasz Majewski wrote:
Quoted 5 lines
common/cmd_dfu.c new file +1
-0+int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * constargv[])
static
It can be static (static int do_dfu). On the other hand the U_BOOT_CMD macro defines:
int (*cmd)(struct cmd_tbl_s *, int, int, char * const []); at
struct cmd_tbl_s, which is int.
Quoted 5 lines
common/cmd_dfu.c line 32
Quoted 3 lines
common/cmd_dfu.c new file +2
-0+{ +char *str_env =NULL , *env_bkp =NULL ;no need to assign NULL here.
str_envshould be const.
Yes, correct.
Quoted 4 lines
common/cmd_dfu.c line 33
Quoted 2 lines
common/cmd_dfu.c new file +1
-0+static char *s ="dfu" ;no need to declare this static
Why not? The s ptr is further passed to g_dnl_init(s), so my intend was to declare string in the data segment of this translation unit. In this way the data under this ptr will not vanish.
Quoted 4 lines
common/cmd_dfu.c line 34
Quoted 2 lines
common/cmd_dfu.c new file +1
-0+int ret =0 ;no need to init to 0
Ok.
Quoted 16 lines
common/cmd_dfu.c line 56
Quoted 13 lines
common/cmd_dfu.c new file +3
-0+ env_bkp =strdup (str_env); + ret =dfu_config_entities (env_bkp, argv[1 ], + (int)simple_strtoul(argv[2], NULL,10));
common/cmd_dfu.c new file +8
-0+if (ret) +return CMD_RET_FAILURE ; + +if (strcmp (argv[3 ],"list" ) ==0 ) { +dfu_show_entities (); +dfu_free_entities (); +free (env_bkp); +return CMD_RET_SUCCESS ;for these last three statements, you could just do "goto done" and put a done label below ...
Yes, you are correct. Thanks for tip.
Quoted 12 lines
common/cmd_dfu.c line 68
Quoted 3 lines
common/cmd_dfu.c new file +2
-0+exit: +g_dnl_cleanup ();done:
common/cmd_dfu.c line 72
Quoted 4 lines
common/cmd_dfu.c new file +4
-0+dfu_free_entities (); +free (env_bkp); + +return CMD_RET_SUCCESS ;-mike
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
Quoted 10 lines · On Monday 23 July 2012 12:01:04 Lukasz Majewski wrote:
Dear Mike,
Quoted 8 lines · On Tuesday 03 July 2012 05:38:09 Lukasz Majewski wrote:
Quoted 5 lines
common/cmd_dfu.c new file +1
-0+int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * constargv[])
static
Quoted 5 lines
It can be static (static int
do_dfu). On the other hand theU_BOOT_CMDmacro defines:int (*cmd)(struct
cmd_tbl_s*, int, int, char * const []); at
structcmd_tbl_s, which is int.
i don't understand what you're trying to say
Quoted 7 lines
Quoted 3 lines
common/cmd_dfu.c line 33
Quoted 1 line
common/cmd_dfu.c new file +1
-0+static char *s ="dfu" ;no need to declare this static
Why not? The s ptr is further passed to
g_dnl_init(s), so my intend was to declare string in the data segment of this translation unit. In this way the data under this ptr will not vanish.
except your g_dnl_init already copies the incoming string to local storage, so where it is stored doesn't matter. further, the "dfu" is going to be in .rodata (thus never going away), it is only the "s" pointer which will be stored in .data, not the thing it points to.
had you done:
char s[] = { 'd', 'f', 'u', '\0', };then you'd get 4 bytes on the stack
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120724/7bdd3c07/attachment.pgp>
PATCH 5/7 dfu:cmd: Support for DFU u-boot command
Hi Mike,
Quoted 27 lines · On Monday 23 July 2012 12:01:04 Lukasz Majewski wrote:
Quoted 10 lines
Dear Mike,
Quoted 8 lines · On Tuesday 03 July 2012 05:38:09 Lukasz Majewski wrote:
Quoted 5 lines
common/cmd_dfu.c new file +1
-0+int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * constargv[])
static
Quoted 5 lines
It can be static (static int
do_dfu). On the other hand theU_BOOT_CMDmacro defines:int (*cmd)(struct
cmd_tbl_s*, int, int, char * const []); at
structcmd_tbl_s, which is int.i don't understand what you're trying to say
Quoted 7 lines
Quoted 3 lines
common/cmd_dfu.c line 33
Quoted 1 line
common/cmd_dfu.c new file +1
-0+static char *s ="dfu" ;no need to declare this static
Why not? The s ptr is further passed to
g_dnl_init(s), so my intend was to declare string in the data segment of this translation unit. In this way the data under this ptr will not vanish.
Quoted 8 lines
except your
g_dnl_initalready copies the incoming string to local storage, so where it is stored doesn't matter. further, the "dfu" is going to be in .rodata (thus never going away), it is only the "s" pointer which will be stored in .data, not the thing it points to.had you done:
char s[] = { 'd', 'f', 'u', '\0', };then you'd get 4 bytes on the stack
Thanks for clarification
Regards,
Lukasz Majewski
PATCH 6/7 arm:trats: Support for USB UDC driver at TRATS board.
In reply to Lukasz MajewskiSupport for USB UDC driver at trats board.
--- board/samsung/trats/trats.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
board/samsung/trats/trats.c +9 -0
@@ -59,6 +59,8 @@ static int hwrevision(int rev)return (board_rev &0xf ) == rev; } +struct s3c_plat_otg_data s5pc210_otg_data; +int board_init (void ) { gd->bd->bi_boot_params =PHYS_SDRAM_1 +0x100 ;
@@ -259,6 +261,13 @@ struct s3c_plat_otg_data s5pc210_otg_data = { .usb_phy_ctrl = EXYNOS4_USBPHY_CONTROL, .usb_flags = PHY0_SLEEP, }; + +void board_usb_init (void ) +{ +puts ("USB_udc_probe\n" ); +s3c_udc_probe (&s5pc210_otg_data); + +}#endif static void pmic_reset (void )
Signature · 1 line
1.7.2.3
PATCH 6/7 arm:trats: Support for USB UDC driver at TRATS board.
Dear Lukasz,
Quoted 24 lines · Lukasz Majewski
Support for USB UDC driver at trats board.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>Cc Minkyu Kang <[email protected]>--- board/samsung/trats/trats.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)board/samsung/trats/trats.c +2
-0@@ -59,6 +59,8 @@ static int hwrevision(int rev)return (board_rev &0xf ) == rev; } +struct s3c_plat_otg_data s5pc210_otg_data; +int board_init (void ) { gd->bd->bi_boot_params =PHYS_SDRAM_1 +0x100 ;
board/samsung/trats/trats.c struct s3c_plat_otg_data s5pc210_otg_data = { · line 267
Quoted 7 lines
board/samsung/trats/trats.c +4
-0@@ -259,6 +261,13 @@ struct s3c_plat_otg_data s5pc210_otg_data = { .usb_phy_ctrl = EXYNOS4_USBPHY_CONTROL, .usb_flags = PHY0_SLEEP, }; + +void board_usb_init (void ) +{ +puts ("USB_udc_probe\n" );
is it useful information? or debug message?
board/samsung/trats/trats.c struct s3c_plat_otg_data s5pc210_otg_data = { · line 272
Quoted 5 lines
board/samsung/trats/trats.c +3
-0+ s3c_udc_probe(&s5pc210_otg_data); + +}#endif
Thanks.
Minkyu Kang.
Signature · 2 lines
from. prom. www.promsoft.net
PATCH 6/7 arm:trats: Support for USB UDC driver at TRATS board.
Hi Minkyu,
Quoted 21 lines
Dear Lukasz,
Quoted 18 lines · Lukasz Majewski
Support for USB UDC driver at trats board.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>Cc Minkyu Kang <[email protected]>--- board/samsung/trats/trats.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)(quoted diff) +0
-0
b/board/samsung/trats/trats.cindex a95a516..2f3a531 100644board/samsung/trats/trats.c +0
-0@@ -59,6 +59,8 @@ static int hwrevision(int rev)return (board_rev &0xf ) == rev; }
Quoted 15 lines
board/samsung/trats/trats.c struct s3c_plat_otg_data s5pc210_otg_data = { · line 267
Quoted 13 lines
board/samsung/trats/trats.c +6
-0+struct s3c_plat_otg_data s5pc210_otg_data; +int board_init (void ) { gd->bd->bi_boot_params =PHYS_SDRAM_1 +0x100 ;@@ -259,6 +261,13 @@ struct s3c_plat_otg_data s5pc210_otg_data = { .usb_phy_ctrl = EXYNOS4_USBPHY_CONTROL, .usb_flags = PHY0_SLEEP, }; + +void board_usb_init (void ) +{ +puts ("USB_udc_probe\n" );is it useful information? or debug message?
Good point. I will change it to debug.
Quoted 9 lines
board/samsung/trats/trats.c struct s3c_plat_otg_data s5pc210_otg_data = { · line 272
Quoted 6 lines
board/samsung/trats/trats.c +3
-0+ s3c_udc_probe(&s5pc210_otg_data); + +}#endif Thanks.
Minkyu Kang.
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH 7/7 arm:trats: Enable g_dnl composite USB gadget with embedded DFU function on TRATS
In reply to Lukasz MajewskiEnable the g_dnl composite USB gadget driver with embedded DFU function on it. It now uses the composite gadget framework to support download specific USB functions (like enabled DFU or USB Mass Storage).
--- include/configs/trats.h | 19 ++++++++++++++++++- 1 files changed, 18 insertions(+), 1 deletions(-)
include/configs/trats.h +18 -1
@@ -94,6 +94,16 @@#undef CONFIG_CMD_ONENAND#undef CONFIG_CMD_MTDPARTS#define CONFIG_CMD_MMC +#define CONFIG_CMD_DFU + +/* FAT */ +#define CONFIG_CMD_FAT +#define CONFIG_FAT_WRITE + +/* USB Composite download gadget - g_dnl */ +#define CONFIG_USBDOWNLOAD_GADGET +#define CONFIG_DFU_FUNCTION +#define CONFIG_DFU_MMC #define CONFIG_BOOTDELAY 1#define CONFIG_ZERO_BOOTDELAY_CHECK
@@ -104,6 +114,11 @@#define CONFIG_BOOTBLOCK "10"#define CONFIG_ENV_COMMON_BOOT "${console} ${meminfo}" +#define CONFIG_DFU_ALT \ + "dfu_alt_info=" \ + "u-boot mmc 80 400;" \ + "uImage fat 0 2\0" \ +#define CONFIG_ENV_OVERWRITE #define CONFIG_SYS_CONSOLE_INFO_QUIET #define CONFIG_SYS_CONSOLE_IS_IN_ENV
@@ -146,7 +161,8 @@"mmcdev=0\0" \"mmcbootpart=2\0" \"mmcrootpart=3\0" \ -"opts=always_resume=1" +"opts=always_resume=1\0" \ +CONFIG_DFU_ALT /* Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP /* undef to save memory */
@@ -213,6 +229,7 @@#define CONFIG_USB_GADGET #define CONFIG_USB_GADGET_S3C_UDC_OTG #define CONFIG_USB_GADGET_DUALSPEED +#define CONFIG_USB_GADGET_VBUS_DRAW 2/* LCD */ #define CONFIG_EXYNOS_FB
Signature · 1 line
1.7.2.3
PATCH 7/7 arm:trats: Enable g_dnl composite USB gadget with embedded DFU function on TRATS
Quoted 4 lines · Lukasz Majewski
Enable the
g_dnlcomposite USB gadget driver with embedded DFU function on it. It now uses the composite gadget framework to support download specific USB functions (like enabled DFU or USB Mass Storage).
Quoted 8 lines
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>Cc Minkyu Kang <[email protected]>--- include/configs/trats.h | 19 ++++++++++++++++++- 1 files changed, 18 insertions(+), 1 deletions(-)
Signature · 2 lines
from. prom. www.promsoft.net
cover dfu:usb: Composite USB download gadget with DFU function
In reply to Lukasz MajewskiQuoted 2 lines · Lukasz Majewski
Those patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
Awesome! :-)
Signature · 3 lines
Otavio Salvador O.S. Systems E-mail: otavio at ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
cover dfu:usb: Composite USB download gadget with DFU function
Dear Otavio Salvador,
Quoted 1 line
On Tue, Jul 3, 2012 at 6:38 AM, Lukasz Majewski <[email protected]>
Quoted 4 lines · wrote:
Quoted 2 lines
Those patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
Awesome! :-)
Hey Otavio ... we can do the same with our bootrom :-p
Best regards,
Marek Vasut
v2 cover dfu:usb: Composite USB download gadget with DFU function
In reply to Lukasz MajewskiThose patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
A separate DFU back-end and front-end have been added.
Back-end is placed at ./drivers/dfu directory. The front-end is implemented as USB function.
The back-end is written in a generic manner with storage device specific code separated (eMMC).
DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_standard
Example usage:
u-boot side: dfu mmc 0
PC: dfu-util -U IMAGE.bin -a uImage (for upload)
dfu-util -D uImage -a uImage (download)
To list the alt settings:
dfu mmc 0 list
Test HW:
Exynos4210 Trats board
Lukasz Majewski (7):
dfu:usb: Support for g_dnl composite download gadget. dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
dfu: DFU backend implementation
dfu: MMC specific routines for DFU operation
dfu:cmd: Support for DFU u-boot command
arm:trats: Support for USB UDC driver at TRATS board. arm:trats: Enable g_dnl composite USB gadget with embedded DFU
function on TRATS
Makefile | 1 + board/samsung/trats/trats.c | 8 + common/Makefile | 1 + common/cmd_dfu.c | 81 +++++ drivers/dfu/Makefile | 44 +++ drivers/dfu/dfu.c | 259 +++++++++++++++ drivers/dfu/dfu_mmc.c | 126 +++++++ drivers/usb/gadget/Makefile | 2 + drivers/usb/gadget/f_dfu.c | 753 +++++++++++++++++++++++++++++++++++++++++++ drivers/usb/gadget/f_dfu.h | 100 ++++++ drivers/usb/gadget/g_dnl.c | 223 +++++++++++++ include/configs/trats.h | 24 ++- include/dfu.h | 99 ++++++ include/g_dnl.h | 33 ++ 14 files changed, 1753 insertions(+), 1 deletions(-) create mode 100644 common/cmd_dfu.c create mode 100644 drivers/dfu/Makefile create mode 100644 drivers/dfu/dfu.c create mode 100644 drivers/dfu/dfu_mmc.c create mode 100644 drivers/usb/gadget/f_dfu.c create mode 100644 drivers/usb/gadget/f_dfu.h create mode 100644 drivers/usb/gadget/g_dnl.c create mode 100644 include/dfu.h create mode 100644 include/g_dnl.h
Signature · 1 line
1.7.2.3
PATCH v2 1/7 dfu:usb: Support for g_dnl composite download gadget.
Composite USB download gadget support (g_dnl) for download functions. This code works on top of composite gadget.
---
Changes for v2:
- G_DNL_{VENDOR_NUM, PRODUCT_NUM and MANUFACTURER} defined at ./include/configs/<board>.h
- Suspend and resume stub methods removed
- '\0' repleaced with plain 0
--- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/g_dnl.c | 223 +++++++++++++++++++++++++++++++++++++++++++ include/g_dnl.h | 33 +++++++ 3 files changed, 257 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/g_dnl.c create mode 100644 include/g_dnl.h
drivers/usb/gadget/Makefile +1 -0
@@ -29,6 +29,7 @@ LIB := $(obj)libusb_gadget.o 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 endif ifdef CONFIG_USB_ETHER COBJS-y += ether.o epautoconf.o config.o usbstring.o
drivers/usb/gadget/g_dnl.c new file +223 -0
223 lines not on this page · raw message
include/g_dnl.h new file +33 -0
@@ -0,0 +1,33 @@ +/* +* Copyright (C) 2012 Samsung Electronics +* Lukasz Majewski <[email protected]> +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License as +* published by the Free Software Foundation; either version 2 of +* the License, or (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, +* MA 02111-1307 USA +*/ + +#ifndef __G_DOWNLOAD_H_ +#define __G_DOWNLOAD_H_ + +#include <linux/usb/ch9.h> +#include <usbdescriptors.h> +#include <linux/usb/gadget.h> + +int g_dnl_init (char *s); +void g_dnl_cleanup (void ); + +/* USB initialization declaration - board specific*/ +void board_usb_init (void ); +#endif /* __G_DOWNLOAD_H_ */
Signature · 1 line
1.7.2.3
PATCH v2 1/7 dfu:usb: Support for g_dnl composite download gadget.
Dear Lukasz Majewski,
Quoted 11 lines
Composite USB download gadget support (
g_dnl) for download functions. This code works on top of composite gadget.Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>---
Changes for v2:- G_DNL_{VENDOR_NUM,
PRODUCT_NUMand MANUFACTURER} defined at
make this CONFIG_G_....
The rest seems ok.
Best regards,
Marek Vasut
PATCH v2 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
In reply to Lukasz MajewskiSupport for f_dfu USB function.
---
Changes for v2:
- Replace kzalloc and kfree with free and calloc
- Reorganization of calloc calls
- Misspelling corrected
- Redesign of DFU state machine from "switch case" to function pointers
- Split the dfu_handle method to separate functions for each DFU state
--- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/f_dfu.c | 753 +++++++++++++++++++++++++++++++++++++++++++ drivers/usb/gadget/f_dfu.h | 100 ++++++ 3 files changed, 854 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/f_dfu.c create mode 100644 drivers/usb/gadget/f_dfu.h
drivers/usb/gadget/Makefile +1 -0
@@ -30,6 +30,7 @@ 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
drivers/usb/gadget/f_dfu.c new file +753 -0
753 lines not on this page · raw message
drivers/usb/gadget/f_dfu.h new file +100 -0
100 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v2 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
Dear Lukasz Majewski,
Quoted 6 lines
Support for
f_dfuUSB function.Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>
[...]
Quoted 9 lines
drivers/usb/gadget/f_dfu.c new file +9
-0+static void handle_getstatus (struct usb_request *req) +{ +struct dfu_status *dstat = (struct dfu_status *)req->buf; +struct f_dfu *f_dfu = req->context; + +switch (f_dfu->dfu_state) { +case DFU_STATE_dfuDNLOAD_SYNC: +case DFU_STATE_dfuDNBUSY: + f_dfu->dfu_state = DFU_STATE_dfuDNLOAD_IDLE;
drivers/usb/gadget/f_dfu.c line 170
Quoted 10 lines
drivers/usb/gadget/f_dfu.c new file +10
-0+break ; +case DFU_STATE_dfuMANIFEST_SYNC: +break ; +default : +break ; + } + +/* send status response */ + dstat->bStatus = f_dfu->dfu_status; +/* FIXME: set dstat->bwPollTimeout */
FIXME? :)
Quoted 3 lines
drivers/usb/gadget/f_dfu.c new file +3
-0+ dstat->bState = f_dfu->dfu_state; + dstat->iString =0 ; +}
[...]
Quoted 10 lines
drivers/usb/gadget/f_dfu.c new file +10
-0+static int +dfu_handle (struct usb_function *f,const struct usb_ctrlrequest *ctrl) +{ +struct usb_gadget *gadget = f->config->cdev->gadget; +struct usb_request *req = f->config->cdev->req; +struct f_dfu *f_dfu = f->config->cdev->req->context; +u16 len =le16_to_cpu (ctrl->wLength); +u16 w_value =le16_to_cpu (ctrl->wValue); +int value =0 ; +u8 req_type = ctrl->bRequestType &USB_TYPE_MASK ;
drivers/usb/gadget/f_dfu.c line 539
Quoted 10 lines
drivers/usb/gadget/f_dfu.c new file +10
-0+ +debug ("w_value: 0x%x len: 0x%x\n" , w_value, len); +debug ("req_type: 0x%x ctrl->bRequest: 0x%x f_dfu->dfu_state: 0x%x\n" , + req_type, ctrl->bRequest, f_dfu->dfu_state); + + +if (req_type ==USB_TYPE_STANDARD ) { +if (ctrl->bRequest ==USB_REQ_GET_DESCRIPTOR && + (w_value >>8 ) ==DFU_DT_FUNC ) { + value =min (len, (u16 )sizeof dfu_func);
Does the sizeof really miss braces up here ?
[...]
PATCH v2 3/7 dfu: DFU backend implementation
In reply to Lukasz MajewskiNew, separate driver at ./drivers/dfu has been added. It allows platform and storage independent operation of DFU.
---
Changes for v2:
- None
--- Makefile | 1 + drivers/dfu/Makefile | 43 ++++++++ drivers/dfu/dfu.c | 259 ++++++++++++++++++++++++++++++++++++++++++++++++++ include/dfu.h | 99 +++++++++++++++++++ 4 files changed, 402 insertions(+), 0 deletions(-) create mode 100644 drivers/dfu/Makefile create mode 100644 drivers/dfu/dfu.c create mode 100644 include/dfu.h
Makefile +1 -0
@@ -271,6 +271,7 @@ LIBS += drivers/pci/libpci.o LIBS += drivers/pcmcia/libpcmcia.o LIBS += drivers/power/libpower.o LIBS += drivers/spi/libspi.o +LIBS += drivers/dfu/libdfu.o ifeq ($(CPU),mpc83xx) LIBS += drivers/qe/libqe.o LIBS += arch/powerpc/cpu/mpc8xxx/ddr/libddr.o
drivers/dfu/Makefile new file +43 -0
43 lines not on this page · raw message
drivers/dfu/dfu.c new file +259 -0
259 lines not on this page · raw message
include/dfu.h new file +99 -0
99 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v2 3/7 dfu: DFU backend implementation
Dear Lukasz Majewski,
Quoted 7 lines
New, separate driver at
./drivers/dfuhas been added. It allows platform and storage independent operation of DFU.Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>
[...]
drivers/dfu/dfu.c line 63
Quoted 11 lines
drivers/dfu/dfu.c new file +11
-0+char *dfu_extract_token (char ** e,int *n) +{ +char *st = *e; + +debug ("%s: %s\n" , __func__, st); + +strsep (e," " ); + *n = *e - st; + +return st; +}
Sigh, what about these? btw don't we have strtok?
[...]
Best regards,
Marek Vasut
PATCH v2 3/7 dfu: DFU backend implementation
In reply to Lukasz MajewskiDear Lukasz Majewski,
Quoted 2 lines · In message <[email protected]> you wrote:
New, separate driver at
./drivers/dfuhas been added. It allows platform and storage independent operation of DFU.
Sorry for a probably stupid question, but I know basicly zero about
DFU. We are talking about "storage independent" here. Does this
also mean file system independent?
drivers/dfu/dfu.c line 223
Quoted 5 lines
drivers/dfu/dfu.c new file +5
-0+static char *dfu_get_dev_type (enum dfu_device_type t) +{ +static char *dev_t[] = {NULL ,"MMC" ,"ONENAND" ,"NAND" }; +return dev_t[t]; +}
So this currently supports MMC, OneNAND and NAND as storage devices?
drivers/dfu/dfu.c line 229
Quoted 5 lines
drivers/dfu/dfu.c new file +5
-0+static char *dfu_get_layout (enum dfu_device_type l) +{ +static char *dfu_layout[] = {NULL ,"RAW_ADDR" ,"FAT" ,"EXT" }; +return dfu_layout[l]; +}
And FAT (or VFAT?) and EXT (as in EXT2? or EXT3? or ... ?) as file systems?
include/dfu.h line 40
Quoted 11 lines
include/dfu.h new file +11
-0+enum dfu_device_type { +MMC =1 , +ONENAND , +NAND +}; + +enum dfu_layout { +RAW_ADDR =1 , +FAT , +EXT , +};
MMC, NAND, FAT and EXT are very generic names that heavily pollute on the global name space. Please chose more specific names, probaly also indicating the meaning (EXT could be some "extension" or "external" or whatever - the name does not indicate that this is a file system type here.
Best regards,
Wolfgang Denk
Signature · 4 lines
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 It is your destiny. - Darth Vader
PATCH v2 3/7 dfu: DFU backend implementation
Dear Wolfgang Denk,
Quoted 10 lines
Dear Lukasz Majewski,
In message <[email protected]>
Quoted 2 lines · you
New, separate driver at
./drivers/dfuhas been added. It allows platform and storage independent operation of DFU.Sorry for a probably stupid question, but I know basicly zero about
DFU. We are talking about "storage independent" here. Does this
also mean file system independent?
Some clarification is needed. I've divided DFU support (PATCH v2) to three separate parts:
1. DFU transmission handling (via USB)
with ./drivers/usb/gadget/g_dnl.c|f_dfu.c
2. Generic DFU functions ./drivers/dfu/dfu.c - which try to abstract DFU operation to be platform independent.
Generic dfu_{write|read} functions have been defined and are
accessible from USB code. On the other hand dfu_{write|read}
calls function pointers dfu->{read|write}_medium(), which points
to medium specific functions.3. Code for MMC write/read - dfu_mmc.c.
It is possible to read/write raw data to MMC (with passing LBA address) or to file systems (like FAT). For now MMC is only supported. It uses (in my opinion) "generic" sprintf+run_command() calls, which can be easily extended.
To support OneNAND one needs to define dfu_onenand.c file with OneNAND specific functions.
Considering above, there are already defined "generic" access functions
- dfu_{write|read}.
Quoted 8 lines
drivers/dfu/dfu.c line 223
Quoted 6 lines
drivers/dfu/dfu.c new file +5
-0+static char *dfu_get_dev_type (enum dfu_device_type t) +{ +static char *dev_t[] = {NULL ,"MMC" ,"ONENAND" ,"NAND" }; +return dev_t[t]; +}So this currently supports MMC, OneNAND and NAND as storage devices?
It currently only supports MMC devices. Others (ONENAND/NAND) have been added as place holders for future usage.
Quoted 20 lines
Review
Quoted 7 lines
drivers/dfu/dfu.c new file +3
-0+static char *dfu_get_layout (enum dfu_device_type l) +{ +static char *dfu_layout[] = {NULL ,"RAW_ADDR" ,"FAT" ,"EXT" };
(quoted diff) +2
-0+ return dfu_layout[l]; +}And FAT (or VFAT?) and EXT (as in EXT2? or EXT3? or ... ?) as file systems?
Quoted 9 lines
include/dfu.h new file +9
-0+enum dfu_device_type { +MMC =1 , +ONENAND , +NAND +}; + +enum dfu_layout { +RAW_ADDR =1 , +FAT ,
Quoted 8 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ EXT, +};MMC, NAND, FAT and EXT are very generic names that heavily pollute on the global name space. Please chose more specific names, probaly also indicating the meaning (EXT could be some "extension" or "external" or whatever - the name does not indicate that this is a file system type here.
Ok, no problem with this.
Quoted 6 lines
Best regards,
Wolfgang Denk
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v2 3/7 dfu: DFU backend implementation
Dear Lukasz,
Quoted 4 lines · In message <[email protected]> you wrote:
Some clarification is needed. I've divided DFU support (PATCH v2) to three separate parts:
1. DFU transmission handling (via USB)
...
Quoted 2 lines
2. Generic DFU functions
./drivers/dfu/dfu.c- which try to abstract DFU operation to be platform independent.
...
Quoted 1 line
3. Code for MMC write/read -
dfu_mmc.c.
OK, than my understanding was mostly correct.
Quoted 6 lines
It is possible to read/write raw data to MMC (with passing LBA address) or to file systems (like FAT). For now MMC is only supported. It uses (in my opinion) "generic" sprintf+run_command() calls, which can be easily extended.
To support OneNAND one needs to definedfu_onenand.cfile with OneNAND specific functions.
Correct. And adaption for other devices (say, NAND or USB mass storage) should be trivial as well.
Quoted 2 lines
Considering above, there are already defined "generic" access functions
- dfu_{write|read}.
OK - but the device specific stuff is only used in the sprintf() command then. That's why I recommend to move just this very small function into a separate file, which can be replaced or removed later.
Quoted 4 lines
Quoted 1 line
So this currently supports MMC, OneNAND and NAND as storage devices?
It currently only supports MMC devices. Others (ONENAND/NAND) have been added as place holders for future usage.
Yes, I understand. But then, adding such support looks pretty straightforward, and even trivial to me. You provided a pretty clear infrastructure for this, thanks.
Best regards,
Wolfgang Denk
Signature · 7 lines
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 I thought my people would grow tired of killing. But you were right, they see it is easier than trading. And it has its pleasures. I feel it myself. Like the hunt, but with richer rewards. -- Apella, "A Private Little War", stardate 4211.8
PATCH v2 3/7 dfu: DFU backend implementation
Dear Wolfgang Denk,
Quoted 2 lines
Correct. And adaption for other devices (say, NAND or USB mass storage) should be trivial as well.
USB Mass Storage is also under development. It is supposed to be a function (f_ums.c) for g_dnl.c composite gadget.
I will postpone posting it to ML until we agree for the DFU shape (and thereof the g_dnl composite gadget driver).
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
In reply to Lukasz MajewskiSupport for MMC storage devices to work with DFU framework.
---
Changes for v2:
- None
--- drivers/dfu/Makefile | 1 + drivers/dfu/dfu_mmc.c | 126 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 127 insertions(+), 0 deletions(-) create mode 100644 drivers/dfu/dfu_mmc.c
drivers/dfu/Makefile +1 -0
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk LIB = $(obj)libdfu.o COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o +COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o SRCS := $(COBJS-y:.o=.c) OBJS := $(addprefix $(obj),$(COBJS-y))
drivers/dfu/dfu_mmc.c new file +126 -0
126 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Dear Lukasz Majewski,
Quoted 6 lines
Support for MMC storage devices to work with DFU framework.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>
This one opens some questions.
[...]
Quoted 5 lines
drivers/dfu/dfu_mmc.c new file +5
-0+int dfu_fill_entity_mmc (struct dfu_entity *dfu,char * s) +{ +char *st =NULL ; +int n =0 ; +
drivers/dfu/dfu_mmc.c line 111
Quoted 10 lines
drivers/dfu/dfu_mmc.c new file +10
-0+ dfu->dev_type =MMC ; + st =dfu_extract_token (&s, &n); + +if (!strncmp (st,"mmc" , n)) { + dfu->layout =RAW_ADDR ; + + dfu->data.mmc.lba_start =simple_strtoul (s, &s,16 ); + dfu->data.mmc.lba_size =simple_strtoul (++s, &s,16 ); + dfu->data.mmc.lba_blk_size =get_mmc_blk_size (dfu->dev_num); +
^ one line too much.
Quoted 5 lines
drivers/dfu/dfu_mmc.c new file +5
-0+ }else if (!strncmp (st,"fat" , n)) { + dfu->layout =FAT ; + + dfu->data.mmc.dev =simple_strtoul (s, &s,10 ); + dfu->data.mmc.part =simple_strtoul (++s, &s,10 );
drivers/dfu/dfu_mmc.c line 126
Quoted 10 lines
drivers/dfu/dfu_mmc.c new file +10
-0+ + }else { +printf ("%s: Wrong memory layout!\n" , __func__); + } + + dfu->read_medium = dfu_read_medium_mmc; + dfu->write_medium = dfu_write_medium_mmc; + +return 0 ; +}
Best regards,
Marek Vasut
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
In reply to Lukasz MajewskiQuoted 5 lines · Lukasz Majewski
Support for MMC storage devices to work with DFU framework.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>
[snip]
Quoted 5 lines
drivers/dfu/dfu_mmc.c new file +5
-0+case RAW_ADDR : +sprintf (cmd_buf,"mmc write 0x%x %x %x" , (unsigned int ) buf, + dfu->data.mmc.lba_start, dfu->data.mmc.lba_size); +break ; +case FAT :
drivers/dfu/dfu_mmc.c line 48
Quoted 10 lines
drivers/dfu/dfu_mmc.c new file +10
-0+sprintf (cmd_buf,"fatwrite mmc %d:%d 0x%x %s %lx" , + dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int ) buf, dfu->name, *len); +break ; +default : +printf ("%s: Wrong layout!\n" , __func__); + } + +debug ("%s: %s 0x%p\n" , __func__, cmd_buf, cmd_buf); +run_command (cmd_buf,0 );
If we try and take the long-view here, that fatwrite/mmc write don't perform a lot of sanity checking on input isn't good. Lots of commands I believe don't, but we can start somewhere. So, lets do what Marek was suggesting of making common/cmd_mmc.c and common/cmd_fat.c call a sub-function that takes compile-time typecheckable inputs, and call that here. That opens things up for later making the user commands perform better checking and so forth.
Signature · 8 lines
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/20120710/641ed618/attachment.pgp>
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Hi Tom,
Quoted 20 lines · Lukasz Majewski
Quoted 5 lines
Support for MMC storage devices to work with DFU framework.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>[snip]
Quoted 13 lines
(quoted diff) +2
-0+ case RAW_ADDR: + sprintf(cmd_buf, "mmc write 0x%x %x %x", (unsignedint) buf,
(quoted diff) +1
-0+ dfu->data.mmc.lba_start,
dfu->data.mmc.lba_size);drivers/dfu/dfu_mmc.c new file +8
-0+break ; +case FAT : +sprintf (cmd_buf,"fatwrite mmc %d:%d 0x%x %s %lx" , + dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int ) buf, dfu->name, *len); +break ; +default : +printf ("%s: Wrong layout!\n" , __func__);
Quoted 8 lines
drivers/dfu/dfu_mmc.c line 48
Quoted 4 lines
drivers/dfu/dfu_mmc.c new file +4
-0+ } + +debug ("%s: %s 0x%p\n" , __func__, cmd_buf, cmd_buf); +run_command (cmd_buf,0 );If we try and take the long-view here, that fatwrite/mmc write don't perform a lot of sanity checking on input isn't good. Lots of commands I believe don't, but we can start somewhere.
Yes, indeed they don't. But I think, that it is a deeper problem.
When one looks into the cmd_mmc.c, the code is not checking the correctness of passed data. It performs strncmp, then simple_strtoul and with this parameter calls mmc->block_dev.block_read().
But I'm a bit concern if adding function:
do_mmcops_check(unsigned int lba_start, unsigned int lba_end, ...) to
do_mmcops(argc, argv) {
int i = simple_strtol(argv[]);
return do_mmcops_check(i);
}will help with preventing errors.
As I've written previously, data from prompt is passed in a form of text, which is converted to the well defined type anyway (with e.g. simple_strtoul - returns unsigned long, strict_strtoul - returns int, simple_strtol - returns long, simple_strtoull - returns unsigned long long). Using those functions correctly would ensure correct types passed to e.g. mmc->block_dev.block_read().
When one create the do_mmcops_check() function, the compiler would check if its arguments are correct (i.e. the i in the above example is int). What is the difference between checking at compile time the output of simple_strtoul?
The real problem in my opinion is the lack of checking if arguments passed as text to the do_mmcops are correct or not. This is not done for MMC and I doubt, if adding compile time type checking (in a form of a separate function) would solve/alleviate the problem.
Quoted 5 lines
So, lets do
what Marek was suggesting of makingcommon/cmd_mmc.candcommon/cmd_fat.ccall a sub-function that takes compile-time typecheckable inputs, and call that here. That opens things up for later making the user commands perform better checking and so forth.
I'd like to point to the problem with passing and then parsing parameters as text.
User typed parameters aren't checked.
Please correct me if I misunderstood the problem or the proposed solution.
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Quoted 36 lines · Lukasz Majewski
Hi Tom,
Quoted 20 lines · Lukasz Majewski
Quoted 5 lines
Support for MMC storage devices to work with DFU framework.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>[snip]
Quoted 13 lines
(quoted diff) +2
-0+ case RAW_ADDR: + sprintf(cmd_buf, "mmc write 0x%x %x %x", (unsignedint) buf,
(quoted diff) +1
-0+ dfu->data.mmc.lba_start,
dfu->data.mmc.lba_size);drivers/dfu/dfu_mmc.c new file +8
-0+break ; +case FAT : +sprintf (cmd_buf,"fatwrite mmc %d:%d 0x%x %s %lx" , + dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int ) buf, dfu->name, *len); +break ; +default : +printf ("%s: Wrong layout!\n" , __func__);Quoted 8 lines
drivers/dfu/dfu_mmc.c line 48
Quoted 4 lines
drivers/dfu/dfu_mmc.c new file +4
-0+ } + +debug ("%s: %s 0x%p\n" , __func__, cmd_buf, cmd_buf); +run_command (cmd_buf,0 );If we try and take the long-view here, that fatwrite/mmc write don't perform a lot of sanity checking on input isn't good. Lots of commands I believe don't, but we can start somewhere.
Yes, indeed they don't. But I think, that it is a deeper problem.
When one looks into the
cmd_mmc.c, the code is not checking the correctness of passed data. It performs strncmp, thensimple_strtouland with this parameter callsmmc->block_dev.block_read().
Quoted 8 lines
But I'm a bit concern if adding function:
do_mmcops_check(unsigned int lba_start, unsigned int lba_end, ...)todo_mmcops(argc, argv) { int i = simple_strtol(argv[]); return do_mmcops_check(i); }
Well, what I was suggesting would be:
do_mmcops_real(uint lba_start, ...) { .. most of do_mmcops today .. } do_mmcops_from_cmd(argc, argv) {
... convert user input today, maybe try and sanity check input tomorrow ..
}
And then dfu calls do_mmcops_real(lba_start, ...). A further clean-up would be to make the interface the command uses to perform checking of the arguments passed. Does this make sense?
Signature · 1 line
Tom
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Quoted 56 lines · On Wed, 11 Jul 2012 04:54:31 -0700 Tom Rini <[email protected]> wrote:
Quoted 39 lines · Lukasz Majewski
Hi Tom,
Quoted 21 lines · Lukasz Majewski
Quoted 5 lines
Support for MMC storage devices to work with DFU framework.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>[snip]
Quoted 14 lines
(quoted diff) +2
-0+ case RAW_ADDR: + sprintf(cmd_buf, "mmc write 0x%x %x %x",(unsigned int) buf,
(quoted diff) +1
-0+ dfu->data.mmc.lba_start,
dfu->data.mmc.lba_size);drivers/dfu/dfu_mmc.c new file +3
-0+break ; +case FAT : + sprintf(cmd_buf, "fatwrite mmc %d:%d 0x%x %s%lx",
drivers/dfu/dfu_mmc.c new file +5
-0+ dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int) buf, dfu->name, *len); +break ; +default : +printf ("%s: Wrong layout!\n" , __func__);Quoted 8 lines
drivers/dfu/dfu_mmc.c line 48
Quoted 4 lines
drivers/dfu/dfu_mmc.c new file +4
-0+ } + +debug ("%s: %s 0x%p\n" , __func__, cmd_buf, cmd_buf); +run_command (cmd_buf,0 );If we try and take the long-view here, that fatwrite/mmc write don't perform a lot of sanity checking on input isn't good. Lots of commands I believe don't, but we can start somewhere.
Yes, indeed they don't. But I think, that it is a deeper problem.
When one looks into the
cmd_mmc.c, the code is not checking the correctness of passed data. It performs strncmp, thensimple_strtouland with this parameter callsmmc->block_dev.block_read().But I'm a bit concern if adding function:
Quoted 7 lines
do_mmcops_check(unsigned int lba_start, unsigned int lba_end, ...)todo_mmcops(argc, argv) { int i = simple_strtol(argv[]); return do_mmcops_check(i); }Well, what I was suggesting would be:
do_mmcops_real(uint lba_start, ...){ .. most ofdo_mmcopstoday .. }do_mmcops_from_cmd(argc, argv){
... convert user input today, maybe try and sanity check input
tomorrow ..
}
Quoted 4 lines
And then dfu calls
do_mmcops_real(lba_start, ...). A further clean-up would be to make the interface the command uses to perform checking of the arguments passed. Does this make sense?
Generally it is in my opinion a good way to go.
However, why we aren't first writing sanity checks for passed arguments?
We are adding one more level of abstraction, but don't think of the main problem (checking values of passed arguments)?
Anyway we shall wait for Marek's opinion.
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Quoted 59 lines · Lukasz Majewski
Quoted 56 lines · On Wed, 11 Jul 2012 04:54:31 -0700 Tom Rini <[email protected]> wrote:
Quoted 39 lines · Lukasz Majewski
Hi Tom,
Quoted 21 lines · Lukasz Majewski
Quoted 5 lines
Support for MMC storage devices to work with DFU framework.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>[snip]
Quoted 14 lines
(quoted diff) +2
-0+ case RAW_ADDR: + sprintf(cmd_buf, "mmc write 0x%x %x %x",(unsigned int) buf,
(quoted diff) +1
-0+ dfu->data.mmc.lba_start,
dfu->data.mmc.lba_size);drivers/dfu/dfu_mmc.c new file +3
-0+break ; +case FAT : + sprintf(cmd_buf, "fatwrite mmc %d:%d 0x%x %s%lx",
drivers/dfu/dfu_mmc.c new file +5
-0+ dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int) buf, dfu->name, *len); +break ; +default : +printf ("%s: Wrong layout!\n" , __func__);Quoted 8 lines
drivers/dfu/dfu_mmc.c line 48
Quoted 4 lines
drivers/dfu/dfu_mmc.c new file +4
-0+ } + +debug ("%s: %s 0x%p\n" , __func__, cmd_buf, cmd_buf); +run_command (cmd_buf,0 );If we try and take the long-view here, that fatwrite/mmc write don't perform a lot of sanity checking on input isn't good. Lots of commands I believe don't, but we can start somewhere.
Yes, indeed they don't. But I think, that it is a deeper problem.
When one looks into the
cmd_mmc.c, the code is not checking the correctness of passed data. It performs strncmp, thensimple_strtouland with this parameter callsmmc->block_dev.block_read().But I'm a bit concern if adding function:
Quoted 7 lines
do_mmcops_check(unsigned int lba_start, unsigned int lba_end, ...)todo_mmcops(argc, argv) { int i = simple_strtol(argv[]); return do_mmcops_check(i); }Well, what I was suggesting would be:
do_mmcops_real(uint lba_start, ...){ .. most ofdo_mmcopstoday .. }do_mmcops_from_cmd(argc, argv){
... convert user input today, maybe try and sanity check input
tomorrow ..
}
Quoted 8 lines
Quoted 4 lines
And then dfu calls
do_mmcops_real(lba_start, ...). A further clean-up would be to make the interface the command uses to perform checking of the arguments passed. Does this make sense?Generally it is in my opinion a good way to go.
However, why we aren't first writing sanity checks for passed arguments?
Simply because I didn't want to ask you to do a lot more unrelated work :) If you want to split and check the mmc (and fatwrite) argueuments and then make the DFU series depend on that, by all means please do so!
Quoted 4 lines
We are adding one more level of abstraction, but don't think of the main problem (checking values of passed arguments)?
Anyway we shall wait for Marek's opinion.
Yes, a good idea as well.
Signature · 1 line
Tom
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Dear Tom Rini,
Quoted 73 lines · Lukasz Majewski
Quoted 72 lines
On Wed, 11 Jul 2012 04:54:31 -0700
Quoted 58 lines · Tom Rini
Quoted 45 lines · Lukasz Majewski
Hi Tom,
Quoted 23 lines · Lukasz Majewski
Quoted 5 lines
Support for MMC storage devices to work with DFU framework.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>[snip]
Quoted 14 lines
(quoted diff) +2
-0+ case RAW_ADDR: + sprintf(cmd_buf, "mmc write 0x%x %x %x",(unsigned int) buf,
(quoted diff) +1
-0+ dfu->data.mmc.lba_start,
dfu->data.mmc.lba_size);drivers/dfu/dfu_mmc.c new file +3
-0+break ; +case FAT : + sprintf(cmd_buf, "fatwrite mmc %d:%d 0x%x %s%lx",
drivers/dfu/dfu_mmc.c new file +5
-0+ dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int) buf, dfu->name, *len); +break ; +default : +printf ("%s: Wrong layout!\n" , __func__);Quoted 8 lines
drivers/dfu/dfu_mmc.c line 48
Quoted 4 lines
drivers/dfu/dfu_mmc.c new file +4
-0+ } + +debug ("%s: %s 0x%p\n" , __func__, cmd_buf, cmd_buf); +run_command (cmd_buf,0 );If we try and take the long-view here, that fatwrite/mmc write don't perform a lot of sanity checking on input isn't good. Lots of commands I believe don't, but we can start somewhere.
Yes, indeed they don't. But I think, that it is a deeper problem.
When one looks into the
cmd_mmc.c, the code is not checking the correctness of passed data. It performs strncmp, thensimple_strtouland with this parameter callsmmc->block_dev.block_read().But I'm a bit concern if adding function:
do_mmcops_check(unsigned int lba_start, unsigned int lba_end, ...)toQuoted 6 lines
do_mmcops(argc, argv){int i = simple_strtol(argv[]); return do_mmcops_check(i);}
Well, what I was suggesting would be:
do_mmcops_real(uint lba_start, ...){ .. most ofdo_mmcopstoday .. }do_mmcops_from_cmd(argc, argv){Quoted 8 lines
... convert user input today, maybe try and sanity check input
tomorrow ..
}And then dfu calls
do_mmcops_real(lba_start, ...). A further clean-up would be to make the interface the command uses to perform checking of the arguments passed. Does this make sense?Generally it is in my opinion a good way to go.
Quoted 7 lines
Quoted 1 line
However, why we aren't first writing sanity checks for passed arguments?
Simply because I didn't want to ask you to do a lot more unrelated work
:) If you want to split and check the mmc (and fatwrite) argueuments
and then make the DFU series depend on that, by all means please do so!
Would be cool indeed.
Quoted 6 lines
Quoted 4 lines
We are adding one more level of abstraction, but don't think of the main problem (checking values of passed arguments)?
Anyway we shall wait for Marek's opinion.
Yes, a good idea as well.
My opinion is that if you'll do the sanity checks, that'd be good. We're right before .07 release anyway, so the patches will hit the next merge window. Are you up for doing a lot of unrelated work to make this proper?
Best regards,
Marek Vasut
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Quoted 15 lines
Quoted 9 lines
Quoted 3 lines
Generally it is in my opinion a good way to go.
However, why we aren't first writing sanity checks for passed arguments?
Simply because I didn't want to ask you to do a lot more unrelated work
:) If you want to split and check the mmc (and fatwrite) argueuments
and then make the DFU series depend on that, by all means please do so!
Would be cool indeed.
Quoted 3 lines
Quoted 3 lines
We are adding one more level of abstraction, but don't think of the main problem (checking values of passed arguments)?
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
Anyway we shall wait for Marek's opinion.
Yes, a good idea as well.
My opinion is that if you'll do the sanity checks, that'd be good. We're right before .07 release anyway, so the patches will hit the next merge window. Are you up for doing a lot of unrelated work to make this proper?
I agree with the general sense that adding sanity checking would be good. Just because I was too lazy to add them, doesn't mean I was right. ;)
Andy
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
In reply to Lukasz MajewskiDear Lukasz Majewski,
Quoted 1 line · In message <[email protected]> you wrote:
Support for MMC storage devices to work with DFU framework.
Sorry for jumping in late.
drivers/dfu/dfu_mmc.c line 45
Quoted 13 lines
drivers/dfu/dfu_mmc.c new file +13
-0+switch (dfu->layout) { +case RAW_ADDR : +sprintf (cmd_buf,"mmc write 0x%x %x %x" , (unsigned int ) buf, + dfu->data.mmc.lba_start, dfu->data.mmc.lba_size); +break ; +case FAT : +sprintf (cmd_buf,"fatwrite mmc %d:%d 0x%x %s %lx" , + dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int ) buf, dfu->name, *len); +break ; +default : +printf ("%s: Wrong layout!\n" , __func__); + }
In case of error, you should always print what the unexpected data was. The end user who receives an "Wrong layout!" error is probably
pretty much surpised and doesn't know what he did wrong. If you
print instead: "EXT2 layout not supported (yet)" he would know exactly what to change to make it work.
There has been some dicussion already if using this sprintf() / run_command() approach is good or not, or how it should be fixed.
It appears, all this discussion forgot to take into account that patch 3/7 dfu: DFU backend implementation promised to add "platform and storage independent operation of DFU." Here we are breaking this promise.
And by adding special functions to the FAT file system code thing sget just worse, as now not only the DFU code needs to be extended when we want to use this with any other file system type, but suddenly this also bleeds into all supported file system code.
I am aware that the current implementation suffers from the fact that we don't have a unified access to file systems - each comes with it's own set of commands and more or less (in)compatible command line and function call interfaces. This will hopefully improve in the context of the device model rework, but we don't want to block you until then. But considering that this is going to change in a foreseeable future, it also makes littel sense to invest big efforts into generic code that covers all potential future uses.
Here is my poposal:
Let's introduce a thin shim layer to abstract the file system interface from the accesses you need here. As far as I can see here, you need exactly 4 functions:
- block_read()
- block_write()
- file_read()
- file_write()
These names could be function pointers to implement the device I/O in a both device and file system agnostic way; you can implement specific versions of the functions like mmc_block_read(), usb_block_read(), ... etc. and use the settings of dfu_device_type and dfu_layout to set the pointers to these functions.
For this shim layer I would actually prefer the original approach (shown above) to use sprintf() to build commands based on the existing command interface - this is the minimal intrusive way to implement this for now. With this approach, no modifications to file system and/or device driver code are needed, and we still maintain full flexibility here in the DFU code. Yes, error checking may not be perfect, and we my not win a price for elegance of design either, but we should get mostly clean, working code quickly.
The advantage I see for this code is that we have separated all this device interface stuff from both the generic DFU code and from the device and file system code as well. As soon as we have a better implementation below, all we need to adjust (or potentially even remove) is this shim layer.
Best regards,
Wolfgang Denk
Signature · 5 lines
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 To the systems programmer, users and applications serve only to provide a test load.
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Dear Wolfgang Denk,
Quoted 3 lines
Dear Lukasz Majewski,
In message <[email protected]> you
Quoted 65 lines · wrote:
Quoted 1 line
Support for MMC storage devices to work with DFU framework.
Sorry for jumping in late.
drivers/dfu/dfu_mmc.c line 45
Quoted 13 lines
drivers/dfu/dfu_mmc.c new file +13
-0+switch (dfu->layout) { +case RAW_ADDR : +sprintf (cmd_buf,"mmc write 0x%x %x %x" , (unsigned int ) buf, + dfu->data.mmc.lba_start, dfu->data.mmc.lba_size); +break ; +case FAT : +sprintf (cmd_buf,"fatwrite mmc %d:%d 0x%x %s %lx" , + dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int ) buf, dfu->name, *len); +break ; +default : +printf ("%s: Wrong layout!\n" , __func__); + }In case of error, you should always print what the unexpected data was. The end user who receives an "Wrong layout!" error is probably
pretty much surpised and doesn't know what he did wrong. If you
print instead: "EXT2 layout not supported (yet)" he would know exactly what to change to make it work.There has been some dicussion already if using this
sprintf()/run_command()approach is good or not, or how it should be fixed.It appears, all this discussion forgot to take into account that patch 3/7 dfu: DFU backend implementation promised to add "platform and storage independent operation of DFU." Here we are breaking this promise.
And by adding special functions to the FAT file system code thing sget just worse, as now not only the DFU code needs to be extended when we want to use this with any other file system type, but suddenly this also bleeds into all supported file system code.
I am aware that the current implementation suffers from the fact that we don't have a unified access to file systems - each comes with it's own set of commands and more or less (in)compatible command line and function call interfaces. This will hopefully improve in the context of the device model rework, but we don't want to block you until then. But considering that this is going to change in a foreseeable future, it also makes littel sense to invest big efforts into generic code that covers all potential future uses.
Here is my poposal:
Let's introduce a thin shim layer to abstract the file system interface from the accesses you need here. As far as I can see here, you need exactly 4 functions:
-
block_read()
-block_write()
-file_read()
-file_write()These names could be function pointers to implement the device I/O in a both device and file system agnostic way; you can implement specific versions of the functions like
mmc_block_read(),usb_block_read(), ... etc. and use the settings ofdfu_device_typeanddfu_layoutto set the pointers to these functions.
Quoted 3 lines
For this shim layer I would actually prefer the original approach (shown above) to use
sprintf()to build commands based on the existing command interface
We discussed it for a while ... figure out the missing typechecking and abuse of the command line interface is not a way to go.
Quoted 6 lines
this is the minimal intrusive way to implement
this for now. With this approach, no modifications to file system and/or device driver code are needed, and we still maintain full flexibility here in the DFU code. Yes, error checking may not be perfect, and we my not win a price for elegance of design either, but we should get mostly clean, working code quickly.
But now that we started going in the typechecking way, I'd prefer to go all the way. And once DFU extends properly towards other supported filesystems/devices, the rest of the interface can get cleaned along the way.
Quoted 5 lines
The advantage I see for this code is that we have separated all this device interface stuff from both the generic DFU code and from the device and file system code as well. As soon as we have a better implementation below, all we need to adjust (or potentially even remove) is this shim layer.
Shim layer is cool -- abusing command line is not cool ;-)
Quoted 3 lines
Best regards,
Wolfgang Denk
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Dear Marek Vasut,
Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 4 lines
For this shim layer I would actually prefer the original approach (shown above) to use
sprintf()to build commands based on the existing command interfaceWe discussed it for a while ... figure out the missing typechecking and abuse of the command line interface is not a way to go.
I agree that this is not the preferred way for a permanent solution, but for now I cxonsider it acceptable, as it allows to easily deal with the inconsistent API of the misc file system handlers. For example instead of
sprintf(cmd_buf, "fatread mmc %d:%d 0x%x %s %lx", ...
we can even do something like
sprintf(cmd_buf, "%s %s %d:%d 0x%x %s %lx", command, device, ...
and set command as needed to "fatread" or "ext2load" or whatever, and device can be set to "mmc" or "usb" or ...
Quoted 10 lines
Quoted 6 lines
this is the minimal intrusive way to implement
this for now. With this approach, no modifications to file system and/or device driver code are needed, and we still maintain full flexibility here in the DFU code. Yes, error checking may not be perfect, and we my not win a price for elegance of design either, but we should get mostly clean, working code quickly.But now that we started going in the typechecking way, I'd prefer to go all the way. And once DFU extends properly towards other supported filesystems/devices, the rest of the interface can get cleaned along the way.
You can implement the type checking code when you hav ea stable, well define API for storage devices and file systems. For now we don't have that, and it makes ZERO sense to add special code just for that just to throw it away in a few weeks.
Quoted 1 line
Shim layer is cool -- abusing command line is not cool ;-)
Whether this is abuse or clever use remains to be defined, and this is probably largely a matter of taste. In any case, this will be a small piece of code that is of clearly transient nature, to be replaced or removed as soon as we can do better.
Best regards,
Wolfgang Denk
Signature · 5 lines
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 The nice thing about standards is that there are so many to choose from. - Andrew S. Tanenbaum
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Dear Wolfgang Denk,
Quoted 17 lines
Dear Marek Vasut,
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 3 lines
For this shim layer I would actually prefer the original approach (shown above) to use
sprintf()to build commands based on the existing command interfaceWe discussed it for a while ... figure out the missing typechecking and abuse of the command line interface is not a way to go.
I agree that this is not the preferred way for a permanent solution, but for now I cxonsider it acceptable, as it allows to easily deal with the inconsistent API of the misc file system handlers. For example instead of
sprintf(cmd_buf, "fatread mmc %d:%d 0x%x %s %lx", ...
Quoted 7 lines
we can even do something like
sprintf(cmd_buf, "%s %s %d:%d 0x%x %s %lx", command, device, ...and set command as needed to "fatread" or "ext2load" or whatever, and device can be set to "mmc" or "usb" or ...
Given that they have slightly different syntax, this is crazy too.
Quoted 12 lines
Quoted 11 lines
Quoted 6 lines
this is the minimal intrusive way to implement
this for now. With this approach, no modifications to file system and/or device driver code are needed, and we still maintain full flexibility here in the DFU code. Yes, error checking may not be perfect, and we my not win a price for elegance of design either, but we should get mostly clean, working code quickly.But now that we started going in the typechecking way, I'd prefer to go all the way. And once DFU extends properly towards other supported filesystems/devices, the rest of the interface can get cleaned along the way.
Quoted 4 lines
You can implement the type checking code when you hav ea stable, well define API for storage devices and file systems. For now we don't have that, and it makes ZERO sense to add special code just for that just to throw it away in a few weeks.
Ad API -- adding Pavel to CC. Hope his GMail works better than mine (mine doesn't, crashed again, damned google stuff). Pavel, can you provide us with how the API will look maybe?
Quoted 10 lines
Quoted 1 line
Shim layer is cool -- abusing command line is not cool ;-)
Whether this is abuse or clever use remains to be defined, and this is probably largely a matter of taste. In any case, this will be a small piece of code that is of clearly transient nature, to be replaced or removed as soon as we can do better.
Best regards,
Wolfgang Denk
Well ... after this discussion, I feel like I'll just go dig me a grave again.
Best regards,
Marek Vasut
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Dear Marek Vasut,
Quoted 8 lines · In message <[email protected]> you wrote:
Quoted 6 lines
sprintf(cmd_buf, "%s %s %d:%d 0x%x %s %lx", command, device, ...and set command as needed to "fatread" or "ext2load" or whatever, and device can be set to "mmc" or "usb" or ...
Given that they have slightly different syntax, this is crazy too.
Draw the line between clever and crazy, genius and idiot :-)
Quoted 1 line
Well ... after this discussion, I feel like I'll just go dig me a grave again.
Why? I think the discussion has been beneficial - we isolated a poor piece of code, discussed how it should be improved, and now ry to find an intermediate solution that adds not too much work for Lukasz while still keeing the existing code clean and allowing for easy adaption to the new DM interfaces - three worthwile goals at once.
Best regards,
Wolfgang Denk
Signature · 4 lines
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 Sorry, but my karma just ran over your dogma.
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
In reply to Wolfgang DenkDear Wolfgang Denk,
Quoted 22 lines
Dear Lukasz Majewski,
In message <[email protected]>
Quoted 1 line · you
Support for MMC storage devices to work with DFU framework.
Sorry for jumping in late.
Quoted 13 lines
drivers/dfu/dfu_mmc.c new file +3
-0+switch (dfu->layout) { +case RAW_ADDR : + sprintf(cmd_buf, "mmc write 0x%x %x %x", (unsignedint) buf,
(quoted diff) +1
-0+ dfu->data.mmc.lba_start,
dfu->data.mmc.lba_size);drivers/dfu/dfu_mmc.c new file +7
-0+break ; +case FAT : +sprintf (cmd_buf,"fatwrite mmc %d:%d 0x%x %s %lx" , + dfu->data.mmc.dev, dfu->data.mmc.part, + (unsigned int ) buf, dfu->name, *len); +break ; +default :
Quoted 8 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ printf("%s: Wrong layout!\n", __func__); + }In case of error, you should always print what the unexpected data was. The end user who receives an "Wrong layout!" error is probably
pretty much surpised and doesn't know what he did wrong. If you
print instead: "EXT2 layout not supported (yet)" he would know exactly what to change to make it work.
Ok, this can be easily corrected.
Quoted 42 lines
There has been some dicussion already if using this
sprintf()/run_command()approach is good or not, or how it should be fixed.It appears, all this discussion forgot to take into account that patch 3/7 dfu: DFU backend implementation promised to add "platform and storage independent operation of DFU." Here we are breaking this promise.
And by adding special functions to the FAT file system code thing sget just worse, as now not only the DFU code needs to be extended when we want to use this with any other file system type, but suddenly this also bleeds into all supported file system code.
I am aware that the current implementation suffers from the fact that we don't have a unified access to file systems - each comes with it's own set of commands and more or less (in)compatible command line and function call interfaces. This will hopefully improve in the context of the device model rework, but we don't want to block you until then. But considering that this is going to change in a foreseeable future, it also makes littel sense to invest big efforts into generic code that covers all potential future uses.
Here is my poposal:
Let's introduce a thin shim layer to abstract the file system interface from the accesses you need here. As far as I can see here, you need exactly 4 functions:
-
block_read()
-block_write()
-file_read()
-file_write()These names could be function pointers to implement the device I/O in a both device and file system agnostic way; you can implement specific versions of the functions like
mmc_block_read(),usb_block_read(), ... etc. and use the settings ofdfu_device_typeanddfu_layoutto set the pointers to these functions.
Quoted 9 lines
For this shim layer I would actually prefer the original approach (shown above) to use
sprintf()to build commands based on the existing command interface - this is the minimal intrusive way to implement this for now. With this approach, no modifications to file system and/or device driver code are needed, and we still maintain full flexibility here in the DFU code. Yes, error checking may not be perfect, and we my not win a price for elegance of design either, but we should get mostly clean, working code quickly.
So I suppose, that you are proposing something like this (pseudo code):
int mmc_block_write() {
sprintf(cmd_buf, "mmc write 0x%x %x %x")
run_command(cmd_buf, 0);
}int mmc_file_write(enum fs_type) {
switch (fs_type)
case FAT:
sprintf(cmd_buf, "fatwrite mmc %d:%d 0x%x %s %lx")
break;
case EXT4:
sprintf(cmd_buf, "ext4write mmc %d:%d 0x%x %s %lx")
break;
run_command(cmd_buf);
}int dfu_write_medium_mmc(struct dfu_entity *dfu, void *buf, long *len)
{
ALLOC_CACHE_ALIGN_BUFFER(char, cmd_buf, DFU_CMD_BUF_SIZE);
memset(cmd_buf, '\0', sizeof(cmd_buf));
switch (dfu->layout) {
case RAW_ADDR:
mmc_block_write()
break;
case FAT:
case EXT3:
case EXT4:
mmc_file_write(dfu->layout);
break;
default:
printf("%s: Wrong layout %s!\n", __func__,
layout_table[dfu->layout]); }
return 0;
}Quoted 7 lines
The advantage I see for this code is that we have separated all this device interface stuff from both the generic DFU code and from the device and file system code as well. As soon as we have a better implementation below, all we need to adjust (or potentially even remove) is this shim layer.
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v2 4/7 dfu: MMC specific routines for DFU operation
Dear Lukasz,
Quoted 2 lines · In message <[email protected]> you wrote:
So I suppose, that you are proposing something like this (pseudo code):
Yes, very close.
Quoted 17 lines
int mmc_block_write() { sprintf(cmd_buf, "mmc write 0x%x %x %x") run_command(cmd_buf, 0); }int mmc_file_write(enum fs_type) { switch (fs_type) case FAT: sprintf(cmd_buf, "fatwrite mmc %d:%d 0x%x %s %lx") break; case EXT4: sprintf(cmd_buf, "ext4write mmc %d:%d 0x%x %s %lx") break; run_command(cmd_buf); }
Quoted 2 lines
int
dfu_write_medium_mmc(struct dfu_entity *dfu, void *buf, long *len){
I suggest just use
int dfu_write_medium(struct dfu_entity *dfu, void *buf, long *len)
here; you can then so something like
switch (dfu->dev_type) {
case MMC: block_write = mmc_block_write;
file_write = mmc_file_write;
break;
#ifdef NAND_SUPPORT_AVAILABLE
case NAND: block_write = nand_block_write;
file_write = nand_block_write;
break;
#endif
...and use block_write() resp. file_write() in the rest. So the code is really trivial to extend for other storage devices and file systems.
I feel we are very close, thanks!
Let's see if Pavel adds some comments about the best API to chose to be as compatible with possible with the upcoming block device layer, and then we can go for it.
Best regards,
Wolfgang Denk
Signature · 5 lines
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
Houston, Tranquillity Base here. The Eagle has landed.
-- Neil ArmstrongPATCH v2 5/7 dfu:cmd: Support for DFU u-boot command
In reply to Lukasz MajewskiSupport for u-boot's command line command "dfu <interface> <dev> [list]".
---
Changes for v2:
- None
--- common/Makefile | 1 + common/cmd_dfu.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 82 insertions(+), 0 deletions(-) create mode 100644 common/cmd_dfu.c
common/Makefile +1 -0
@@ -184,6 +184,7 @@ COBJS-$(CONFIG_MENU) += menu.o COBJS-$(CONFIG_MODEM_SUPPORT) += modem.o COBJS-$(CONFIG_UPDATE_TFTP) += update.o COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o +COBJS-$(CONFIG_CMD_DFU) += cmd_dfu.o endif ifdef CONFIG_SPL_BUILD
common/cmd_dfu.c new file +81 -0
81 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v2 6/7 arm:trats: Support for USB UDC driver at TRATS board.
In reply to Lukasz MajewskiSupport for USB UDC driver at trats board.
---
Changes for v2:
- replace puts to debug
--- board/samsung/trats/trats.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
board/samsung/trats/trats.c +8 -0
@@ -59,6 +59,8 @@ static int hwrevision(int rev)return (board_rev &0xf ) == rev; } +struct s3c_plat_otg_data s5pc210_otg_data; +int board_init (void ) { gd->bd->bi_boot_params =PHYS_SDRAM_1 +0x100 ;
@@ -259,6 +261,12 @@ struct s3c_plat_otg_data s5pc210_otg_data = { .usb_phy_ctrl = EXYNOS4_USBPHY_CONTROL, .usb_flags = PHY0_SLEEP, }; + +void board_usb_init (void ) +{ +debug ("USB_udc_probe\n" ); +s3c_udc_probe (&s5pc210_otg_data); +}#endif static void pmic_reset (void )
Signature · 1 line
1.7.2.3
PATCH v2 7/7 arm:trats: Enable g_dnl composite USB gadget with embedded DFU function on TRATS
In reply to Lukasz MajewskiEnable the g_dnl composite USB gadget driver with embedded DFU function on it. It now uses the composite gadget framework to support download specific USB functions (like enabled DFU or USB Mass Storage).
---
Change for v2:
- Move the G_DNL_{VENDOR_NUM, PRODUCT_NUM and MANUFACTURER} definitions to ./include/configs/<board>.h
--- include/configs/trats.h | 24 +++++++++++++++++++++++- 1 files changed, 23 insertions(+), 1 deletions(-)
include/configs/trats.h +23 -1
@@ -94,6 +94,21 @@#undef CONFIG_CMD_ONENAND#undef CONFIG_CMD_MTDPARTS#define CONFIG_CMD_MMC +#define CONFIG_CMD_DFU + +/* FAT */ +#define CONFIG_CMD_FAT +#define CONFIG_FAT_WRITE + +/* USB Composite download gadget - g_dnl */ +#define CONFIG_USBDOWNLOAD_GADGET +#define CONFIG_DFU_FUNCTION +#define CONFIG_DFU_MMC + +/* USB Samsung's IDs */ +#define G_DNL_VENDOR_NUM 0x04E8 +#define G_DNL_PRODUCT_NUM 0x6601 +#define G_DNL_MANUFACTURER "Samsung"#define CONFIG_BOOTDELAY 1#define CONFIG_ZERO_BOOTDELAY_CHECK
@@ -104,6 +119,11 @@#define CONFIG_BOOTBLOCK "10"#define CONFIG_ENV_COMMON_BOOT "${console} ${meminfo}" +#define CONFIG_DFU_ALT \ + "dfu_alt_info=" \ + "u-boot mmc 80 400;" \ + "uImage fat 0 2\0" \ +#define CONFIG_ENV_OVERWRITE #define CONFIG_SYS_CONSOLE_INFO_QUIET #define CONFIG_SYS_CONSOLE_IS_IN_ENV
@@ -146,7 +166,8 @@"mmcdev=0\0" \"mmcbootpart=2\0" \"mmcrootpart=3\0" \ -"opts=always_resume=1" +"opts=always_resume=1\0" \ +CONFIG_DFU_ALT /* Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP /* undef to save memory */
@@ -209,6 +230,7 @@#define CONFIG_USB_GADGET #define CONFIG_USB_GADGET_S3C_UDC_OTG #define CONFIG_USB_GADGET_DUALSPEED +#define CONFIG_USB_GADGET_VBUS_DRAW 2/* LCD */ #define CONFIG_EXYNOS_FB
Signature · 1 line
1.7.2.3
v2 cover dfu:usb: Composite USB download gadget with DFU function
In reply to Lukasz MajewskiHi Marek,
Quoted 26 lines
Those patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
A separate DFU back-end and front-end have been added. Back-end is placed at
./drivers/dfudirectory. The front-end is implemented as USB function.The back-end is written in a generic manner with storage device specific code separated (eMMC).
DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_standardExample usage:
u-boot side: dfu mmc 0
PC: dfu-util -U IMAGE.bin -a uImage (for upload)
dfu-util -D uImage -a uImage (download)To list the alt settings:
dfu mmc 0 listTest HW:
Exynos4210 Trats board
Quoted 9 lines
Lukasz Majewski (7):
dfu:usb: Support forg_dnlcomposite download gadget. dfu:usb: DFU USB function (f_dfu) support forg_dnlcomposite gadget
dfu: DFU backend implementation
dfu: MMC specific routines for DFU operation
dfu:cmd: Support for DFU u-boot command
arm:trats: Support for USB UDC driver at TRATS board. arm:trats: Enableg_dnlcomposite USB gadget with embedded DFU
function on TRATS
Do you have more comments about those patches?
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
v2 cover dfu:usb: Composite USB download gadget with DFU function
Quoted 39 lines · Lukasz Majewski
Hi Marek,
Quoted 26 lines
Those patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
A separate DFU back-end and front-end have been added. Back-end is placed at
./drivers/dfudirectory. The front-end is implemented as USB function.The back-end is written in a generic manner with storage device specific code separated (eMMC).
DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_standardExample usage:
u-boot side: dfu mmc 0
PC: dfu-util -U IMAGE.bin -a uImage (for upload)
dfu-util -D uImage -a uImage (download)To list the alt settings:
dfu mmc 0 listTest HW:
Exynos4210 Trats boardQuoted 9 lines
Lukasz Majewski (7):
dfu:usb: Support forg_dnlcomposite download gadget. dfu:usb: DFU USB function (f_dfu) support forg_dnlcomposite gadget
dfu: DFU backend implementation
dfu: MMC specific routines for DFU operation
dfu:cmd: Support for DFU u-boot command
arm:trats: Support for USB UDC driver at TRATS board. arm:trats: Enableg_dnlcomposite USB gadget with embedded DFU
function on TRATS
Quoted 1 line
Do you have more comments about those patches?
I _think_ he's been busy with exams and preparing for the U-Boot BoF this week. I'll make sure this gets brought up then however.
Signature · 8 lines
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/20120709/db7e1ef4/attachment.pgp>
v2 cover dfu:usb: Composite USB download gadget with DFU function
Dear Tom Rini,
Quoted 39 lines · Lukasz Majewski
Quoted 38 lines
Hi Marek,
Quoted 36 lines
Those patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
A separate DFU back-end and front-end have been added. Back-end is placed at
./drivers/dfudirectory. The front-end is implemented as USB function.The back-end is written in a generic manner with storage device specific code separated (eMMC).
DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_standardExample usage:
u-boot side: dfu mmc 0
PC: dfu-util -U IMAGE.bin -a uImage (for upload)dfu-util -D uImage -a uImage (download)
To list the alt settings:
dfu mmc 0 listTest HW:
Exynos4210 Trats boardLukasz Majewski (7):
dfu:usb: Support forg_dnlcomposite download gadget. dfu:usb: DFU USB function (f_dfu) support forg_dnlcomposite gadget
dfu: DFU backend implementation
dfu: MMC specific routines for DFU operation
dfu:cmd: Support for DFU u-boot command
arm:trats: Support for USB UDC driver at TRATS board. arm:trats: Enableg_dnlcomposite USB gadget with embedded DFU
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
function on TRATS
Do you have more comments about those patches?
I _think_ he's been busy with exams and preparing for the U-Boot BoF this week. I'll make sure this gets brought up then however.
Exams are long past, but there's a lot of other stuff -- the driver model, the denx work, the LSM this week -- I wish I could cut myself in four or so.
But weren't there some open questions, especially about the function vs. command stuff? The rest were really minor things and I believe you closed them with ease. There are just the few big questions, but it doesn't seem people are too interested to discuss them.
Best regards,
Marek Vasut
v2 cover dfu:usb: Composite USB download gadget with DFU function
Hi Marek,
Quoted 44 lines
Dear Tom Rini,
Quoted 42 lines · Lukasz Majewski
Quoted 41 lines
Hi Marek,
Quoted 38 lines
Those patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
A separate DFU back-end and front-end have been added. Back-end is placed at
./drivers/dfudirectory. The front-end is implemented as USB function.The back-end is written in a generic manner with storage device specific code separated (eMMC).
DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_standardExample usage:
u-boot side: dfu mmc 0
PC: dfu-util -U IMAGE.bin -a uImage (for upload)dfu-util -D uImage -a uImage (download)
To list the alt settings:
dfu mmc 0 listTest HW:
Exynos4210 Trats boardLukasz Majewski (7):
dfu:usb: Support forg_dnlcomposite download gadget. dfu:usb: DFU USB function (f_dfu) support forg_dnlcomposite
gadget dfu: DFU backend implementation
dfu: MMC specific routines for DFU operation dfu:cmd: Support for DFU u-boot command
arm:trats: Support for USB UDC driver at TRATS board. arm:trats: Enableg_dnlcomposite USB gadget with embedded DFUfunction on TRATS
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Do you have more comments about those patches?
I _think_ he's been busy with exams and preparing for the U-Boot BoF this week. I'll make sure this gets brought up then however.
Exams are long past, but there's a lot of other stuff -- the driver model, the denx work, the LSM this week -- I wish I could cut myself in four or so.
As a side note - I'm looking forward to see your keynote video about the new driver model :-).
Quoted 5 lines
But weren't there some open questions, especially about the function vs. command stuff? The rest were really minor things and I believe you closed them with ease. There are just the few big questions, but it doesn't seem people are too interested to discuss them.
I'm open for a discussion :-)
I will post the v3, after the LSM and discussion about the command vs. function issue.
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
v2 cover dfu:usb: Composite USB download gadget with DFU function
Dear Lukasz Majewski,
[...]
Quoted 11 lines
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Do you have more comments about those patches?
I _think_ he's been busy with exams and preparing for the U-Boot BoF this week. I'll make sure this gets brought up then however.
Exams are long past, but there's a lot of other stuff -- the driver model, the denx work, the LSM this week -- I wish I could cut myself in four or so.
As a side note - I'm looking forward to see your keynote video about the new driver model :-).
Oh, just rub it in even more. I'm just starting to get seriously nervous about the talk. Just a while ago, it fell on me ;-) I hope you'll like it though.
Quoted 6 lines
Quoted 4 lines
But weren't there some open questions, especially about the function vs. command stuff? The rest were really minor things and I believe you closed them with ease. There are just the few big questions, but it doesn't seem people are too interested to discuss them.
I'm open for a discussion :-)
I'm glad for that, really.
Quoted 2 lines
I will post the v3, after the LSM and discussion about the command vs. function issue.
Best regards,
Marek Vasut
cover dfu:usb: Composite USB download gadget with DFU function
In reply to Lukasz MajewskiDear Lukasz Majewski,
Quoted 7 lines
Those patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
A separate DFU back-end and front-end have been added.
Back-end is placed at./drivers/dfudirectory. The front-end is implemented as USB function.
Quoted 6 lines
The back-end is written in a generic manner with storage device specific code separated (eMMC).
DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_sta
ndard
[...]
will we see a next version of this series please? Or where did the discussion get?
Best regards,
Marek Vasut
cover dfu:usb: Composite USB download gadget with DFU function
Hi Marek,
Quoted 13 lines
Dear Lukasz Majewski,
Quoted 11 lines
Those patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
A separate DFU back-end and front-end have been added. Back-end is placed at
./drivers/dfudirectory. The front-end is implemented as USB function.The back-end is written in a generic manner with storage device specific code separated (eMMC).
Quoted 7 lines
Quoted 3 lines
DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_sta
ndard[...]
will we see a next version of this series please?
I've just come back from my holiday. I will continue work on this.
Quoted 2 lines
Or where did the
discussion get?
As fair as I remember, the discussion ended up with a conclusion, that new layer of abstraction (in a form of function call) is needed.
I will rehack the cmd_mmc.c to include new functions in it. It will be a prepatch for the DFU.
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
cover dfu:usb: Composite USB download gadget with DFU function
Dear Lukasz Majewski,
Quoted 25 lines
Hi Marek,
Quoted 13 lines
Dear Lukasz Majewski,
Quoted 11 lines
Those patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
A separate DFU back-end and front-end have been added. Back-end is placed at
./drivers/dfudirectory. The front-end is implemented as USB function.The back-end is written in a generic manner with storage device specific code separated (eMMC).
Quoted 7 lines
Quoted 3 lines
DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_standard[...]
will we see a next version of this series please?
I've just come back from my holiday. I will continue work on this.
Quoted 8 lines
Quoted 2 lines
Or where did the
discussion get?As fair as I remember, the discussion ended up with a conclusion, that new layer of abstraction (in a form of function call) is needed.
I will rehack the
cmd_mmc.cto include new functions in it. It will be a prepatch for the DFU.
Thanks a lot! I didn't intend to torture you, really ... I just wanted this to be done properly.
Best regards,
Marek Vasut
v3 cover dfu:usb: DFU support via USB Download gadget
In reply to Lukasz MajewskiThose patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
A separate DFU back-end and front-end have been added.
Back-end is placed at ./drivers/dfu directory. The front-end is implemented as USB function.
The back-end is written in a generic manner with storage device specific code separated (eMMC).
DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_standard
Example usage:
u-boot side: dfu mmc 0
PC: dfu-util -U IMAGE.bin -a uImage (for upload)
dfu-util -D uImage -a uImage (download)
To list the alt settings:
dfu mmc 0 list
Test HW:
Exynos4210 Trats board
Lukasz Majewski (7):
dfu:usb: Support for g_dnl composite download gadget. dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
dfu: DFU backend implementation
dfu: MMC specific routines for DFU operation
dfu:cmd: Support for DFU u-boot command
arm:trats: Support for USB UDC driver at TRATS board. arm:trats: Enable g_dnl composite USB gadget with embedded DFU
function on TRATS
Makefile | 1 + board/samsung/trats/trats.c | 8 + common/Makefile | 1 + common/cmd_dfu.c | 81 +++++ drivers/dfu/Makefile | 44 +++ drivers/dfu/dfu.c | 237 ++++++++++++++ drivers/dfu/dfu_mmc.c | 165 ++++++++++ drivers/usb/gadget/Makefile | 2 + drivers/usb/gadget/f_dfu.c | 751 +++++++++++++++++++++++++++++++++++++++++++ drivers/usb/gadget/f_dfu.h | 100 ++++++ drivers/usb/gadget/g_dnl.c | 218 +++++++++++++ include/configs/trats.h | 24 ++- include/dfu.h | 103 ++++++ include/g_dnl.h | 33 ++ 14 files changed, 1767 insertions(+), 1 deletions(-) create mode 100644 common/cmd_dfu.c create mode 100644 drivers/dfu/Makefile create mode 100644 drivers/dfu/dfu.c create mode 100644 drivers/dfu/dfu_mmc.c create mode 100644 drivers/usb/gadget/f_dfu.c create mode 100644 drivers/usb/gadget/f_dfu.h create mode 100644 drivers/usb/gadget/g_dnl.c create mode 100644 include/dfu.h create mode 100644 include/g_dnl.h
Signature · 1 line
1.7.2.3
PATCH v3 1/7 dfu:usb: Support for g_dnl composite download gadget.
Composite USB download gadget support (g_dnl) for download functions. This code works on top of composite gadget.
---
Changes for v2:
- G_DNL_{VENDOR_NUM, PRODUCT_NUM and MANUFACTURER} defined at ./include/configs/<board>.h
- Suspend and resume stub methods removed
- '\0' repleaced with plain 0
Changes for v3:
- Remove unused #includes
- Replace strncpy and strncat with strcpy and strcat. It was possible due to new approach to g_dnl name generation (at g_dnl_register function)
- Rename the g_dnl_{init|cleanup} to g_dnl_{register|unregister}
- Replace the G_DNL_* CONFIG_G_DNL_*
--- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/g_dnl.c | 218 +++++++++++++++++++++++++++++++++++++++++++ include/g_dnl.h | 33 +++++++ 3 files changed, 252 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/g_dnl.c create mode 100644 include/g_dnl.h
drivers/usb/gadget/Makefile +1 -0
@@ -29,6 +29,7 @@ LIB := $(obj)libusb_gadget.o 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 endif ifdef CONFIG_USB_ETHER COBJS-y += ether.o epautoconf.o config.o usbstring.o
drivers/usb/gadget/g_dnl.c new file +218 -0
218 lines not on this page · raw message
include/g_dnl.h new file +33 -0
@@ -0,0 +1,33 @@ +/* +* Copyright (C) 2012 Samsung Electronics +* Lukasz Majewski <[email protected]> +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License as +* published by the Free Software Foundation; either version 2 of +* the License, or (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, +* MA 02111-1307 USA +*/ + +#ifndef __G_DOWNLOAD_H_ +#define __G_DOWNLOAD_H_ + +#include <linux/usb/ch9.h> +#include <usbdescriptors.h> +#include <linux/usb/gadget.h> + +int g_dnl_register (const char *s); +void g_dnl_unregister (void ); + +/* USB initialization declaration - board specific*/ +void board_usb_init (void ); +#endif /* __G_DOWNLOAD_H_ */
Signature · 1 line
1.7.2.3
PATCH v3 1/7 dfu:usb: Support for g_dnl composite download gadget.
drivers/usb/gadget/g_dnl.c line 69
Quoted 5 lines · On Tuesday 31 July 2012 02:36:57 Lukasz Majewski wrote:
drivers/usb/gadget/g_dnl.c new file +2
-0+static const struct usb_descriptor_header *otg_desc[] = { + (struct usb_descriptor_header *) &(struct usb_otg_descriptor ){
since you're just casting away things, you could just use (void*) to make it a bit more compact
also, can this be:
static const struct usb_descriptor_header * const otg_desc[] (notice the 2nd const)
Quoted 1 line
+static struct
usb_gadget_strings*g_dnl_composite_strings[] = {
here too:
static struct usb_gadget_strings * const g_dnl_composite_strings[] = {
drivers/usb/gadget/g_dnl.c line 102
Quoted 4 lines
drivers/usb/gadget/g_dnl.c new file +4
-0+static int g_dnl_do_config (struct usb_configuration *c) +{ +int ret =-1 ; +char *s = (char *) c->cdev->driver->name;
pretty sure this should be:
const char *s = c->cdev->driver->name;
drivers/usb/gadget/g_dnl.c line 139
Quoted 5 lines
drivers/usb/gadget/g_dnl.c new file +5
-0+static int g_dnl_bind (struct usb_composite_dev *cdev) +{ +int gcnum; +int id, ret; +struct usb_gadget *gadget = cdev->gadget;
can we stick to a single space for indentation between the type and the variable name please ?
drivers/usb/gadget/g_dnl.c line 196
Quoted 9 lines
drivers/usb/gadget/g_dnl.c new file +9
-0+int g_dnl_register (const char *type) +{ +int ret; +/* We only allow "dfu" atm, so 3 should be enough */ +static char name[sizeof (shortname) +3 ]; + +if (!strcmp (type,"dfu" )) { +strcpy (name, shortname); +strcat (name, type);
if u-boot had stpcpy(), we could do:
strcpy(stpcpy(name, shortname), type);
include/g_dnl.h
Quoted 4 lines
include/g_dnl.h new file +1
-0+/* USB initialization declaration - board specific*/
needs a space before that "*/"
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120801/8b19b384/attachment.pgp>
PATCH v3 1/7 dfu:usb: Support for g_dnl composite download gadget.
Hi Mike,
Quoted 11 lines · On Tuesday 31 July 2012 02:36:57 Lukasz Majewski wrote:
Quoted 6 lines
drivers/usb/gadget/g_dnl.c new file +2
-0+static const struct usb_descriptor_header *otg_desc[] = { + (struct usb_descriptor_header *) &(structusb_otg_descriptor){
since you're just casting away things, you could just use (void*) to make it a bit more compact
Quoted 4 lines
also, can this be:
static const structusb_descriptor_header* const otg_desc[] (notice the 2nd const)
After looking into the code I can say that otg_support is not needed (at least for this gadget) in u-boot. Will be removed.
Quoted 4 lines
Quoted 1 line
+static struct
usb_gadget_strings*g_dnl_composite_strings[] = {here too:
static structusb_gadget_strings* const g_dnl_composite_strings[] = {
This const is anyway discarded by compiler (GCC 4.6.1) when .string field of struct usb_composite_driver is initialized.
Quoted 8 lines
drivers/usb/gadget/g_dnl.c line 102
Quoted 5 lines
drivers/usb/gadget/g_dnl.c new file +4
-0+static int g_dnl_do_config (struct usb_configuration *c) +{ +int ret =-1 ; +char *s = (char *) c->cdev->driver->name;pretty sure this should be:
const char *s = c->cdev->driver->name;
Yes, you are right. Corrected.
Quoted 9 lines
drivers/usb/gadget/g_dnl.c line 139
Quoted 6 lines
drivers/usb/gadget/g_dnl.c new file +5
-0+static int g_dnl_bind (struct usb_composite_dev *cdev) +{ +int gcnum; +int id, ret; +struct usb_gadget *gadget = cdev->gadget;can we stick to a single space for indentation between the type and the variable name please ?
Corrected.
Quoted 12 lines
drivers/usb/gadget/g_dnl.c line 196
Quoted 10 lines
drivers/usb/gadget/g_dnl.c new file +9
-0+int g_dnl_register (const char *type) +{ +int ret; +/* We only allow "dfu" atm, so 3 should be enough */ +static char name[sizeof (shortname) +3 ]; + +if (!strcmp (type,"dfu" )) { +strcpy (name, shortname); +strcat (name, type);if u-boot had
stpcpy(), we could do:
Quoted 8 lines
strcpy(stpcpy(name, shortname), type);include/g_dnl.h
Quoted 4 lines
include/g_dnl.h new file +1
-0+/* USB initialization declaration - board specific*/ needs a space before that "*/"
Corrected.
Quoted 1 line
-mike
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v3 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
In reply to Lukasz MajewskiSupport for f_dfu USB function.
---
Changes for v2:
- Replace kzalloc and kfree with free and calloc
- Reorganization of calloc calls
- Misspelling corrected
- Redesign of DFU state machine from "switch case" to function pointers
- Split the dfu_handle method to separate functions for each DFU state
Changes for v3:
- Missing parenthesis added to sizeof call
--- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/f_dfu.c | 751 +++++++++++++++++++++++++++++++++++++++++++ drivers/usb/gadget/f_dfu.h | 100 ++++++ 3 files changed, 852 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/f_dfu.c create mode 100644 drivers/usb/gadget/f_dfu.h
drivers/usb/gadget/Makefile +1 -0
@@ -30,6 +30,7 @@ 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
drivers/usb/gadget/f_dfu.c new file +751 -0
751 lines not on this page · raw message
drivers/usb/gadget/f_dfu.h new file +100 -0
100 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v3 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
drivers/usb/gadget/f_dfu.c
Quoted 4 lines · On Tuesday 31 July 2012 02:36:58 Lukasz Majewski wrote:
drivers/usb/gadget/f_dfu.c new file +1
-0+static struct usb_interface_descriptor dfu_intf_runtime = {
can this be made const ?
drivers/usb/gadget/f_dfu.c line 84
Quoted 2 lines
drivers/usb/gadget/f_dfu.c new file +2
-0+static struct usb_descriptor_header *dfu_runtime_descs[] = { + (struct usb_descriptor_header *) &dfu_intf_runtime,
can you change the descs array to be const ?
static const struct usb_descriptor_header * const dfu_runtime_descs[] = {
then i think you can drop the cast there ...
drivers/usb/gadget/f_dfu.c line 132
Quoted 5 lines
drivers/usb/gadget/f_dfu.c new file +5
-0+static struct usb_qualifier_descriptor dev_qualifier = { +static struct usb_gadget_strings stringtab_dfu_generic = { +static struct usb_gadget_strings *dfu_generic_strings[] = { +static struct usb_gadget_strings stringtab_dfu = { +static struct usb_gadget_strings *dfu_strings[] = {
can these be made const ?
drivers/usb/gadget/f_dfu.c line 178
Quoted 5 lines
drivers/usb/gadget/f_dfu.c new file +5
-0+static void handle_getstate (struct usb_request *req) +{ +struct f_dfu *f_dfu = req->context; + + ((u8 *)req->buf)[0 ] = f_dfu->dfu_state &0xff ;
pretty sure you don't need that "& 0xff"
drivers/usb/gadget/f_dfu.c line 223
Quoted 6 lines
drivers/usb/gadget/f_dfu.c new file +6
-0+static int state_app_idle (struct f_dfu *f_dfu, +const struct usb_ctrlrequest *ctrl, +struct usb_gadget *gadget, +struct usb_request *req) +{ +int value =0 ;
might be good to push this down into the 1 case statement (USB_REQ_DFU_GETSTATE) that uses it rather than init it up top
same goes for all the other funcs below that follow this style
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120801/72139cae/attachment.pgp>
PATCH v3 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
Dear Mike,
Quoted 7 lines · On Tuesday 31 July 2012 02:36:58 Lukasz Majewski wrote:
drivers/usb/gadget/f_dfu.c
Quoted 4 lines
drivers/usb/gadget/f_dfu.c new file +1
-0+static struct usb_interface_descriptor dfu_intf_runtime = {can this be made const ?
Unfortunately those structs cannot be const, since some of their fields are filled during running DFU code(when switching between "normal" and "dfu" mode).
Quoted 8 lines
drivers/usb/gadget/f_dfu.c line 84
Quoted 3 lines
drivers/usb/gadget/f_dfu.c new file +2
-0+static struct usb_descriptor_header *dfu_runtime_descs[] = { + (struct usb_descriptor_header *) &dfu_intf_runtime,can you change the descs array to be const ?
static const structusb_descriptor_header* const dfu_runtime_descs[] = {
The same as above. Moreover the DFU implementation passes the information about available alt settings as descriptors filled at runtime.
Quoted 3 lines
then i think you can drop the cast there ...
Quoted 1 line
+static struct
usb_qualifier_descriptordev_qualifier= {
Struct above can only be defined as const.
Quoted 7 lines
drivers/usb/gadget/f_dfu.c line 132
Quoted 4 lines
drivers/usb/gadget/f_dfu.c new file +4
-0+static struct usb_gadget_strings stringtab_dfu_generic = { +static struct usb_gadget_strings *dfu_generic_strings[] = { +static struct usb_gadget_strings stringtab_dfu = { +static struct usb_gadget_strings *dfu_strings[] = {can these be made const ?
Quoted 7 lines
drivers/usb/gadget/f_dfu.c line 178
Quoted 5 lines
drivers/usb/gadget/f_dfu.c new file +5
-0+static void handle_getstate (struct usb_request *req) +{ +struct f_dfu *f_dfu = req->context; + + ((u8 *)req->buf)[0 ] = f_dfu->dfu_state &0xff ;pretty sure you don't need that "&
0xff"
OK.
Quoted 11 lines
drivers/usb/gadget/f_dfu.c line 223
Quoted 7 lines
drivers/usb/gadget/f_dfu.c new file +6
-0+static int state_app_idle (struct f_dfu *f_dfu, +const struct usb_ctrlrequest *ctrl, +struct usb_gadget *gadget, +struct usb_request *req) +{ +int value =0 ;might be good to push this down into the 1 case statement (
USB_REQ_DFU_GETSTATE) that uses it rather than init it up top
I haven't understood this comment.
Do you suggest to combine all those functions (like state_app_* or state_dfu_*) in one big switch - case clause?
The state machine was initially implemented in this way, but for sake of clearness Marek Vasut asked to split it down do separate functions as defined at dfu_state[]. I also think that this approach is better than one bit switch - case.
Quoted 2 lines
same goes for all the other funcs below that follow this style -mike
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v3 3/7 dfu: DFU backend implementation
In reply to Lukasz MajewskiNew, separate driver at ./drivers/dfu has been added. It allows platform and storage independent operation of DFU.
It has been extended to use new MMC level of command abstraction.
---
Changes for v2:
- None
Changes for v3:
- Remove unnecessary NULL and 0 initialization of dynamic variables
- Combine two puts to one
- Adding const qualifier to device and layout definitions
- Remove unnecessary casting at dfu->name passing
- Provide more meaningful names for dfu layouts and device types
- Removal of dfu_extract_{token|entity} functions and replace them with strsep calls
--- Makefile | 1 + drivers/dfu/Makefile | 43 +++++++++ drivers/dfu/dfu.c | 237 ++++++++++++++++++++++++++++++++++++++++++++++++++ include/dfu.h | 103 ++++++++++++++++++++++ 4 files changed, 384 insertions(+), 0 deletions(-) create mode 100644 drivers/dfu/Makefile create mode 100644 drivers/dfu/dfu.c create mode 100644 include/dfu.h
Makefile +1 -0
@@ -271,6 +271,7 @@ LIBS += drivers/pci/libpci.o LIBS += drivers/pcmcia/libpcmcia.o LIBS += drivers/power/libpower.o LIBS += drivers/spi/libspi.o +LIBS += drivers/dfu/libdfu.o ifeq ($(CPU),mpc83xx) LIBS += drivers/qe/libqe.o LIBS += arch/powerpc/cpu/mpc8xxx/ddr/libddr.o
drivers/dfu/Makefile new file +43 -0
43 lines not on this page · raw message
drivers/dfu/dfu.c new file +237 -0
237 lines not on this page · raw message
include/dfu.h new file +103 -0
103 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v3 3/7 dfu: DFU backend implementation
drivers/dfu/dfu.c
Quoted 4 lines · On Tuesday 31 July 2012 02:36:59 Lukasz Majewski wrote:
drivers/dfu/dfu.c new file +1
-0+static int dfu_find_alt_num (char *s)
const char *s
drivers/dfu/dfu.c line 42
Quoted 9 lines
drivers/dfu/dfu.c new file +9
-0+{ +int i =0 ; + +for (; *s; s++) +if (*s ==';' ) + i++; + +return ++i; +}
looks kind of like:
return (strrchr(s, ';') - s) + 1;
drivers/dfu/dfu.c line 70
Quoted 12 lines
drivers/dfu/dfu.c new file +11
-0+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 ; + +if (blk_seq_num ==0 ) { +memset (dfu_buf,'\0' ,sizeof (dfu_buf)); +memcpy (i_buf, buf, size); + i_buf += size;
why bother clearing it ? since right below we memcpy() in the data we care about from buf, i'd skip the memset() completely.
Quoted 7 lines
drivers/dfu/dfu.c new file +7
-0+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 ;
drivers/dfu/dfu.c line 109
Quoted 10 lines
drivers/dfu/dfu.c new file +10
-0+ +if (blk_seq_num ==0 ) { + i_buf = dfu_buf; +memset (dfu_buf,'\0' ,sizeof (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); + }
same here -- punt the memset()
Quoted 1 line
+static int dfu_fill_entity(struct
dfu_entity*dfu, char* s, int alt,
"char *s", not "char* s"
drivers/dfu/dfu.c line 171
Quoted 11 lines
drivers/dfu/dfu.c new file +11
-0+int dfu_config_entities (char *env,char *interface,int num) +{ +struct dfu_entity *dfu; +int i, ret; +char *s; + + dfu_alt_num =dfu_find_alt_num (env); +debug ("%s: dfu_alt_num=%d\n" , __func__, dfu_alt_num); + +for (i =0 ; i < dfu_alt_num; i++) { + dfu =calloc (sizeof (struct dfu_entity ),1 );
seems like you can do this in a single call outside of the for loop:
dfu = calloc(sizeof(*dfu), dfu_alt_num);
if (!dfu)
return -1;
for (i = 0; i < dfu_alt_num; i++) {
s = strsep(&env, ";");
ret = dfu_fill_entity(&dfu[i], s, i, interface, num);
if (ret)
return -1;
list_add_tail(&dfu[i].list, &dfu_list);
}include/dfu.h line 97
Quoted 6 lines
include/dfu.h new file +3
-0+char *dfu_extract_token (char ** e,int *n); +extern int dfu_fill_entity_mmc (struct dfu_entity *dfu,char * s); +static inline int dfu_fill_entity_mmc (struct dfu_entity *dfu,char * s)
"char *s", not "char* s"
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120801/c7c6b43f/attachment.pgp>
PATCH v3 3/7 dfu: DFU backend implementation
Dear Mike Frysinger,
Quoted 7 lines · On Tuesday 31 July 2012 02:36:59 Lukasz Majewski wrote:
drivers/dfu/dfu.c
Quoted 4 lines
drivers/dfu/dfu.c new file +1
-0+static int dfu_find_alt_num (char *s)const char *s
Good point.
Quoted 10 lines
drivers/dfu/dfu.c line 42
Quoted 10 lines
drivers/dfu/dfu.c new file +9
-0+{ +int i =0 ; + +for (; *s; s++) +if (*s ==';' ) + i++; + +return ++i; +}
In this function I count how many times the ';' separator appears. I didn't found proper function at ./lib/string.c.
Quoted 3 lines
looks kind of like:
return (strrchr(s, ';') - s) + 1;
The above code returns position of the last occurrence of the ';' separator.
Quoted 16 lines
drivers/dfu/dfu.c line 70
Quoted 13 lines
+int
dfu_write(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num)+{drivers/dfu/dfu.c new file +9
-0+static unsigned char *i_buf; +static int i_blk_seq_num; +long w_size =0 ; +int ret =0 ; + +if (blk_seq_num ==0 ) { +memset (dfu_buf,'\0' ,sizeof (dfu_buf)); +memcpy (i_buf, buf, size); + i_buf += size;why bother clearing it ? since right below we
memcpy()in the data we care about from buf, i'd skip thememset()completely.
You are right, removed.
Quoted 13 lines
Quoted 13 lines
+int
dfu_read(struct dfu_entity *dfu, void *buf, int size, int blk_seq_num)+{drivers/dfu/dfu.c new file +10
-0+static unsigned char *i_buf; +static int i_blk_seq_num; +static long r_size; +static u32 crc; +int ret =0 ; + +if (blk_seq_num ==0 ) { + i_buf = dfu_buf; +memset (dfu_buf,'\0' ,sizeof (dfu_buf)); + ret = dfu->read_medium (dfu, i_buf, &r_size);
Quoted 8 lines
drivers/dfu/dfu.c line 109
Quoted 6 lines
drivers/dfu/dfu.c new file +1
-0+ debug("%s: %s %ld [B]\n", __func__, dfu->name,
r_size);drivers/dfu/dfu.c new file +4
-0+ i_blk_seq_num =0 ; +/* Integrity check (if needed) */ + crc =crc32 (0 , dfu_buf, r_size); + }same here -- punt the
memset()
OK,
Quoted 5 lines
Quoted 3 lines
+static int dfu_fill_entity(struct
dfu_entity*dfu, char* s, int alt,"char *s", not "char* s"
OK,
Quoted 14 lines
drivers/dfu/dfu.c line 171
Quoted 12 lines
drivers/dfu/dfu.c new file +11
-0+int dfu_config_entities (char *env,char *interface,int num) +{ +struct dfu_entity *dfu; +int i, ret; +char *s; + + dfu_alt_num =dfu_find_alt_num (env); +debug ("%s: dfu_alt_num=%d\n" , __func__, dfu_alt_num); + +for (i =0 ; i < dfu_alt_num; i++) { + dfu =calloc (sizeof (struct dfu_entity ),1 );seems like you can do this in a single call outside of the for loop:
Quoted 11 lines
dfu = calloc(sizeof(*dfu), dfu_alt_num);
if (!dfu)
return -1;
for (i = 0; i < dfu_alt_num; i++) {
s = strsep(&env, ";");
ret = dfu_fill_entity(&dfu[i], s, i, interface, num);
if (ret)
return -1;
list_add_tail(&dfu[i].list, &dfu_list);
}I'd prefer to leave it as it is (since IMHO is more readable) with the addition of following code:
for (i = 0; i < dfu_alt_num; i++) {
dfu = calloc(sizeof(struct dfu_entity), 1);
if (!dfu) {
dfu_free_entities();
return -1;
}
}Quoted 9 lines
Quoted 7 lines
include/dfu.h new file +3
-0+char *dfu_extract_token (char ** e,int *n); +extern int dfu_fill_entity_mmc (struct dfu_entity *dfu,char * s); +static inline int dfu_fill_entity_mmc(struct dfu_entity *dfu,char* s)
"char *s", not "char* s"
OK
Quoted 1 line
-mike
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v3 3/7 dfu: DFU backend implementation
Quoted 13 lines · On Thursday 02 August 2012 09:55:24 Lukasz Majewski wrote:
Dear Mike Frysinger,
Quoted 10 lines · On Tuesday 31 July 2012 02:36:59 Lukasz Majewski wrote:
drivers/dfu/dfu.c line 42
Quoted 9 lines
drivers/dfu/dfu.c new file +9
-0+{ +int i =0 ; + +for (; *s; s++) +if (*s ==';' ) + i++; + +return ++i; +}In this function I count how many times the ';' separator appears.
well, to be more specific, i think it's counting the number of elements if you were to split on ';'. so if there was one ';', this would return 2. but you're correct of course that my suggested replacement is not equivalent.
Quoted 24 lines
Quoted 24 lines
drivers/dfu/dfu.c line 171
Quoted 11 lines
drivers/dfu/dfu.c new file +11
-0+int dfu_config_entities (char *env,char *interface,int num) +{ +struct dfu_entity *dfu; +int i, ret; +char *s; + + dfu_alt_num =dfu_find_alt_num (env); +debug ("%s: dfu_alt_num=%d\n" , __func__, dfu_alt_num); + +for (i =0 ; i < dfu_alt_num; i++) { + dfu =calloc (sizeof (struct dfu_entity ),1 );seems like you can do this in a single call outside of the for loop:
dfu = calloc(sizeof(*dfu), dfu_alt_num); if (!dfu) return -1; for (i = 0; i < dfu_alt_num; i++) { s = strsep(&env, ";"); ret = dfu_fill_entity(&dfu[i], s, i, interface, num); if (ret)
Quoted 8 lines
Quoted 5 lines
return -1; list_add_tail(&dfu[i].list, &dfu_list); }I'd prefer to leave it as it is (since IMHO is more readable) with the addition of following code:
it might be more slightly more readable, but doing a single function call results in better runtime performance
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120803/55145bc3/attachment.pgp>
PATCH v3 3/7 dfu: DFU backend implementation
Dear Mike Frysinger,
Quoted 49 lines · On Thursday 02 August 2012 09:55:24 Lukasz Majewski wrote:
Quoted 14 lines
Dear Mike Frysinger,
Quoted 10 lines · On Tuesday 31 July 2012 02:36:59 Lukasz Majewski wrote:
drivers/dfu/dfu.c line 42
Quoted 9 lines
drivers/dfu/dfu.c new file +9
-0+{ +int i =0 ; + +for (; *s; s++) +if (*s ==';' ) + i++; + +return ++i; +}In this function I count how many times the ';' separator appears.
well, to be more specific, i think it's counting the number of elements if you were to split on ';'. so if there was one ';', this would return 2. but you're correct of course that my suggested replacement is not equivalent.
Quoted 28 lines
Quoted 28 lines
drivers/dfu/dfu.c line 171
Quoted 11 lines
drivers/dfu/dfu.c new file +11
-0+int dfu_config_entities (char *env,char *interface,int num) +{ +struct dfu_entity *dfu; +int i, ret; +char *s; + + dfu_alt_num =dfu_find_alt_num (env); +debug ("%s: dfu_alt_num=%d\n" , __func__, dfu_alt_num); + +for (i =0 ; i < dfu_alt_num; i++) { + dfu =calloc (sizeof (struct dfu_entity ),1 );seems like you can do this in a single call outside of the for loop:
dfu = calloc(sizeof(*dfu), dfu_alt_num); if (!dfu) return -1; for (i = 0; i < dfu_alt_num; i++) { s = strsep(&env, ";"); ret = dfu_fill_entity(&dfu[i], s, i, interface, num); if (ret) return -1; list_add_tail(&dfu[i].list, &dfu_list);
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
}I'd prefer to leave it as it is (since IMHO is more readable) with the
addition of following code:
it might be more slightly more readable, but doing a single function call results in better runtime performance
Doesn't the compiler optimize it as it sees fit?
Best regards,
Marek Vasut
PATCH v3 3/7 dfu: DFU backend implementation
Quoted 34 lines · On Saturday 04 August 2012 03:47:34 Marek Vasut wrote:
Dear Mike Frysinger,
Quoted 33 lines · On Thursday 02 August 2012 09:55:24 Lukasz Majewski wrote:
Quoted 32 lines
Dear Mike Frysinger,
Quoted 30 lines · On Tuesday 31 July 2012 02:36:59 Lukasz Majewski wrote:
drivers/dfu/dfu.c line 171
Quoted 11 lines
drivers/dfu/dfu.c new file +11
-0+int dfu_config_entities (char *env,char *interface,int num) +{ +struct dfu_entity *dfu; +int i, ret; +char *s; + + dfu_alt_num =dfu_find_alt_num (env); +debug ("%s: dfu_alt_num=%d\n" , __func__, dfu_alt_num); + +for (i =0 ; i < dfu_alt_num; i++) { + dfu =calloc (sizeof (struct dfu_entity ),1 );seems like you can do this in a single call outside of the for loop:
dfu = calloc(sizeof(*dfu), dfu_alt_num); if (!dfu) return -1; for (i = 0; i < dfu_alt_num; i++) { s = strsep(&env, ";"); ret = dfu_fill_entity(&dfu[i], s, i, interface, num); if (ret) return -1; list_add_tail(&dfu[i].list, &dfu_list); }
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
I'd prefer to leave it as it is (since IMHO is more readable) with the
addition of following code:
it might be more slightly more readable, but doing a single function call results in better runtime performance
Doesn't the compiler optimize it as it sees fit?
gcc can't know to optimize malloc calls like this
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120804/bc42c593/attachment.pgp>
PATCH v3 4/7 dfu: MMC specific routines for DFU operation
In reply to Lukasz MajewskiSupport for MMC storage devices to work with DFU framework.
---
Changes for v2:
- None
Changes for v3:
- Provide special abstraction layer (mmc_{block|file}_{read|write}) to alleviate switch to new device model (DM)
- More verbose messages when not supported layout encountered
- Calls to strncmp() replaced with strcmp()
--- drivers/dfu/Makefile | 1 + drivers/dfu/dfu_mmc.c | 165 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 166 insertions(+), 0 deletions(-) create mode 100644 drivers/dfu/dfu_mmc.c
drivers/dfu/Makefile +1 -0
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk LIB = $(obj)libdfu.o COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o +COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o SRCS := $(COBJS-y:.o=.c) OBJS := $(addprefix $(obj),$(COBJS-y))
drivers/dfu/dfu_mmc.c new file +165 -0
165 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v3 4/7 dfu: MMC specific routines for DFU operation
drivers/dfu/dfu_mmc.c line 34
Quoted 7 lines · On Tuesday 31 July 2012 02:37:00 Lukasz Majewski wrote:
drivers/dfu/dfu_mmc.c new file +4
-0+static int mmc_block_op (enum dfu_mmc_op op,struct dfu_entity *dfu, +void *buf,long *len) +{ +ALLOC_CACHE_ALIGN_BUFFER (char, cmd_buf,DFU_CMD_BUF_SIZE );
ugh, what ? you're passing this string to run_command so there is no point in aligning it (not to mention the topic of u-boot code internally calling run_command() is seriously wrong.
drivers/dfu/dfu_mmc.c line 37
Quoted 3 lines
drivers/dfu/dfu_mmc.c new file +3
-0+memset (cmd_buf,'\0' ,sizeof (cmd_buf)); + + sprintf(cmd_buf, "mmc %s 0x%x %x %x",
that memset is pointless. delete it.
drivers/dfu/dfu_mmc.c line 62
Quoted 3 lines
drivers/dfu/dfu_mmc.c new file +3
-0+static int mmc_file_op (enum dfu_mmc_op op,struct dfu_entity *dfu, +void *buf,long *len) +{
came comments for this func as above
Quoted 1 line
+int
dfu_fill_entity_mmc(struct dfu_entity *dfu, char* s)
"char *s", not "char* s". please search all your patches for this mistake as it seems to have come up a lot.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120801/e8f04431/attachment.pgp>
PATCH v3 4/7 dfu: MMC specific routines for DFU operation
Dear Mike Frysinger,
Quoted 11 lines · On Tuesday 31 July 2012 02:37:00 Lukasz Majewski wrote:
drivers/dfu/dfu_mmc.c line 34
Quoted 7 lines
drivers/dfu/dfu_mmc.c new file +4
-0+static int mmc_block_op (enum dfu_mmc_op op,struct dfu_entity *dfu, +void *buf,long *len) +{ +ALLOC_CACHE_ALIGN_BUFFER (char, cmd_buf,DFU_CMD_BUF_SIZE );ugh, what ? you're passing this string to
run_commandso there is no point in aligning it
Ok, I will change this.
Quoted 2 lines
(not to mention the topic of u-boot code internally calling
run_command()is seriously wrong.
We are all aware that this approach is a compromise. And this code will be rewritten when new DM appears.
Quoted 6 lines
drivers/dfu/dfu_mmc.c line 37
Quoted 4 lines
drivers/dfu/dfu_mmc.c new file +3
-0+memset (cmd_buf,'\0' ,sizeof (cmd_buf)); + + sprintf(cmd_buf, "mmc %s 0x%x %x %x",that memset is pointless. delete it.
Done.
Quoted 11 lines
drivers/dfu/dfu_mmc.c line 62
Quoted 4 lines
drivers/dfu/dfu_mmc.c new file +3
-0+static int mmc_file_op (enum dfu_mmc_op op,struct dfu_entity *dfu, +void *buf,long *len) +{came comments for this func as above
Quoted 1 line
+int
dfu_fill_entity_mmc(struct dfu_entity *dfu, char* s)"char *s", not "char* s". please search all your patches for this mistake as it seems to have come up a lot.
Hmm, ./tools/checkpatch wasn't complaining about this...
Quoted 1 line
-mike
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command
In reply to Lukasz MajewskiSupport for u-boot's "dfu <interface> <dev> [list]" command.
---
Changes for v2:
- None
Changes for v3:
- Remove unnecessary initialization to NULL of dynamic variables
- goto done added to reduce code duplication
- static definition of do_dfu()
--- common/Makefile | 1 + common/cmd_dfu.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 82 insertions(+), 0 deletions(-) create mode 100644 common/cmd_dfu.c
common/Makefile +1 -0
@@ -183,6 +183,7 @@ COBJS-$(CONFIG_MENU) += menu.o COBJS-$(CONFIG_MODEM_SUPPORT) += modem.o COBJS-$(CONFIG_UPDATE_TFTP) += update.o COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o +COBJS-$(CONFIG_CMD_DFU) += cmd_dfu.o endif ifdef CONFIG_SPL_BUILD
common/cmd_dfu.c new file +81 -0
81 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command
common/cmd_dfu.c line 81
Quoted 9 lines · Lukasz Majewski
Support for u-boot's "dfu <interface> <dev> [list]" command.
common/cmd_dfu.c new file +7
-0+U_BOOT_CMD (dfu,CONFIG_SYS_MAXARGS ,1 , do_dfu, +"Device Firmware Upgrade" , +"<interface> <dev> [list]\n" +" - device firmware upgrade on a device <dev>\n" +" attached to interface <interface>\n" +" [list] - list available alt settings" +);
Hmm. Is there any way to make this work without specifying "interface dev", or to allow specifying multiple "interface dev" entries? On a system with all of eMMC, NAND, and SPI, I'd like to just run "dfu" as the U-Boot command, and have the host specify which of those "devices" it wants to download to using the DFU protocol. So, if flashing a bunch of devices, there is no need to interact with U-Boot over both serial and USB in order to invoke the dfu command multiple times.
Somewhat related to this, it looks like the eMMC support doesn't allow the HW partition to be specified; it would be nice to expose alt settings for all of:
a) Each individual HW partition (boot0/1 if present, general0/1/2/3 if present, the user area, maybe the replay block)
b) Perhaps also a linearized view of the raw eMMC (LBAs 0..boot_size-1 write to boot 0, LBAs boot_size..(2*boot_size)-1 write to boot1, LBAs 2*boot_size..end_of_device write to user area for example).
PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command
Hi Stephen Warren,
Quoted 18 lines · Lukasz Majewski
common/cmd_dfu.c line 81
Quoted 9 lines
Support for u-boot's "dfu <interface> <dev> [list]" command.
common/cmd_dfu.c new file +7
-0+U_BOOT_CMD (dfu,CONFIG_SYS_MAXARGS ,1 , do_dfu, +"Device Firmware Upgrade" , +"<interface> <dev> [list]\n" +" - device firmware upgrade on a device <dev>\n" +" attached to interface <interface>\n" +" [list] - list available alt settings" +);Hmm. Is there any way to make this work without specifying "interface dev", or to allow specifying multiple "interface dev" entries? On a system with all of eMMC, NAND, and SPI, I'd like to just run "dfu" as the U-Boot command, and have the host specify which of those "devices" it wants to download to using the DFU protocol. So, if flashing a bunch of devices, there is no need to interact with U-Boot over both serial and USB in order to invoke the dfu command multiple times.
It would be possible by specifying proper altsettings e.g.:
a1 mmc-boot
a2 mmc-uImage
a3 nand-part0
a4 nand-part1
etc.
However, I think that for the start, the approach proposed here (as dfu mmc 0 command call) is sufficient.
This approach is used with several file systems calls (e.g. fatload mmc ... , fatwrite mmc ... etc.) and in my opinion it is consistent.
Quoted 7 lines
Somewhat related to this, it looks like the eMMC support doesn't allow the HW partition to be specified; it would be nice to expose alt settings for all of:
a) Each individual HW partition (boot0/1 if present, general0/1/2/3 if present, the user area, maybe the replay block)
I'm fully aware of this problem.
In the eMMC case, the access to boot partitions will be served by defining special alt settings for DFU.
Those altsettings will be defined as follows:
-a[N] boot0
-a[N+1] boot1
Prerequisite for this functionality is support of "boot" command, which will allow switching of the MMC available address spaces (e.g. between boot0/boot1 and user accessible space).
Quoted 4 lines
b) Perhaps also a linearized view of the raw eMMC (LBAs 0..boot_size-1 write to boot 0, LBAs boot_size..(2*boot_size)-1 write to boot1, LBAs 2*boot_size..end_of_device write to user area for example).
Access to partitions will be done differently. I assume that each eMMC memory (the user accessible part) will be equipped with MBR or GPT definition.
For this reason I'm now developing the USB Mass Storage (UMS) gadget to export eMMC to host PC.
This solves the problem with accessing separate partitions.
Please also be aware, that DFU shall be used only for relatively small files (due to small EP0 bandwidth).
Large files shall be copied with UMS.
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command
Quoted 12 lines · Lukasz Majewski
Hi Stephen Warren,
Quoted 10 lines · Lukasz Majewski
Quoted 9 lines
Support for u-boot's "dfu <interface> <dev> [list]" command.
common/cmd_dfu.c new file +7
-0+U_BOOT_CMD (dfu,CONFIG_SYS_MAXARGS ,1 , do_dfu, +"Device Firmware Upgrade" , +"<interface> <dev> [list]\n" +" - device firmware upgrade on a device <dev>\n" +" attached to interface <interface>\n" +" [list] - list available alt settings" +);
...
Quoted 15 lines
Quoted 6 lines
Somewhat related to this, it looks like the eMMC support doesn't allow the HW partition to be specified; it would be nice to expose alt settings for all of:
a) Each individual HW partition (boot0/1 if present, general0/1/2/3 if present, the user area, maybe the replay block)
I'm fully aware of this problem.
In the eMMC case, the access to boot partitions will be served by defining special alt settings for DFU.Those altsettings will be defined as follows:
(quoted diff) +0
-2-a[N] boot0 -a[N+1] boot1
Quoted 3 lines
Prerequisite for this functionality is support of "boot" command, which will allow switching of the MMC available address spaces (e.g. between boot0/boot1 and user accessible space).
Is this "boot" command a DFU protocol command, or a U-Boot command-line command? I note that the U-Boot command-line already allows HW partition selection using an additional parameter to "mmc" - "mmc dev $mmc_device_id $partition_id".
Quoted 7 lines
Quoted 3 lines
b) Perhaps also a linearized view of the raw eMMC (LBAs 0..boot_size-1 write to boot 0, LBAs boot_size..(2*boot_size)-1 write to boot1, LBAs 2*boot_size..end_of_device write to user area for example).
Access to partitions will be done differently. I assume that each eMMC memory (the user accessible part) will be equipped with MBR or GPT definition.
That's a different kind of partition though.
In general, there's no need for the eMMC device to contain any kind of standardized SW-level partition table. On Tegra, the boot ROM can boot directly from an eMMC device, and that requires raw data in the partitions, not a standardized SW partition table.
Quoted 3 lines
For this reason I'm now developing the USB Mass Storage (UMS) gadget to export eMMC to host PC.
This solves the problem with accessing separate partitions.
OK, if the raw eMMC device is exposed using USB storage, we should be able to dd directly to it and the presence-or-lack-thereof of any MBR/GPT wouldn't even be relevant.
It'd still be useful to have a linearized view of the flash that concatenated all the HW partitions into a single raw device, but I guess an alt setting for that probably could be added later.
Quoted 4 lines
Please also be aware, that DFU shall be used only for relatively small files (due to small EP0 bandwidth).
Large files shall be copied with UMS.
Oh, didn't know that. Just out of curiosity, are you thinking of implementing that too?
PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command
Quoted 29 lines · On Wed, 01 Aug 2012 11:13:14 -0600 Stephen Warren <[email protected]> wrote:
Quoted 12 lines · Lukasz Majewski
Hi Stephen Warren,
Quoted 10 lines · Lukasz Majewski
Quoted 9 lines
Support for u-boot's "dfu <interface> <dev> [list]" command.
common/cmd_dfu.c new file +7
-0+U_BOOT_CMD (dfu,CONFIG_SYS_MAXARGS ,1 , do_dfu, +"Device Firmware Upgrade" , +"<interface> <dev> [list]\n" +" - device firmware upgrade on a device <dev>\n" +" attached to interface <interface>\n" +" [list] - list available alt settings" +);...
Quoted 15 lines
Quoted 6 lines
Somewhat related to this, it looks like the eMMC support doesn't allow the HW partition to be specified; it would be nice to expose alt settings for all of:
a) Each individual HW partition (boot0/1 if present, general0/1/2/3 if present, the user area, maybe the replay block)
I'm fully aware of this problem.
In the eMMC case, the access to boot partitions will be served by defining special alt settings for DFU.Those altsettings will be defined as follows:
(quoted diff) +0
-2-a[N] boot0 -a[N+1] boot1
Quoted 8 lines
Quoted 3 lines
Prerequisite for this functionality is support of "boot" command, which will allow switching of the MMC available address spaces (e.g. between boot0/boot1 and user accessible space).
Is this "boot" command a DFU protocol command, or a U-Boot command-line command? I note that the U-Boot command-line already allows HW partition selection using an additional parameter to "mmc"
- "mmc dev $mmc_device_id $partition_id".
I'm rather thinking of a U-boot command (as it is easier to integrate). The command would be "mmc boot <dev> <params .. boot partition>"
Although it is not yet implemented, it is on the top of mine "TO DO" list :-).
Quoted 17 lines
Quoted 9 lines
Quoted 5 lines
b) Perhaps also a linearized view of the raw eMMC (LBAs 0..boot_size-1 write to boot 0, LBAs boot_size..(2*boot_size)-1 write to boot1, LBAs 2*boot_size..end_of_device write to user area for example).
Access to partitions will be done differently. I assume that each eMMC memory (the user accessible part) will be equipped with MBR or GPT definition.
That's a different kind of partition though.
In general, there's no need for the eMMC device to contain any kind of standardized SW-level partition table. On Tegra, the boot ROM can boot directly from an eMMC device, and that requires raw data in the partitions, not a standardized SW partition table.
Quoted 7 lines
Quoted 3 lines
For this reason I'm now developing the USB Mass Storage (UMS) gadget to export eMMC to host PC.
This solves the problem with accessing separate partitions.OK, if the raw eMMC device is exposed using USB storage, we should be able to dd directly to it and the presence-or-lack-thereof of any MBR/GPT wouldn't even be relevant.
With the UMS you would see the whole mmc address space as one partition. Then you can use dd with several parameters to "dump" data to a specific LBA address.
When correct MBR or GPT is present, then we can specify partitions to be accessed.
Quoted 4 lines
It'd still be useful to have a linearized view of the flash that concatenated all the HW partitions into a single raw device, but I guess an alt setting for that probably could be added later.
I think that UMS solves this issue. However, correct me if I'm wrong.
Let's assume, that UMS causes host to see following partitions:
sde: sde1 sde2 sde3 sde4 < sde5 .. sdeN >
Is the "mount -t vfat /dev/sde /mnt" not allowing access to the whole eMMC device (despite of the partitions)?
Quoted 8 lines
Quoted 5 lines
Please also be aware, that DFU shall be used only for relatively small files (due to small EP0 bandwidth).
Large files shall be copied with UMS.
Oh, didn't know that. Just out of curiosity, are you thinking of implementing that too?
The USB Mass Storage gadget is now working with the g_dnl composite gadget as a f_ums function.
Unfortunately it is not polished enough to be posted to ML.
I'd prefer that DFU related patches would be pulled to ML first. Afterwards I would post the UMS function.
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command
Quoted 41 lines · Lukasz Majewski
Quoted 29 lines · On Wed, 01 Aug 2012 11:13:14 -0600 Stephen Warren <[email protected]> wrote:
Quoted 12 lines · Lukasz Majewski
Hi Stephen Warren,
Quoted 10 lines · Lukasz Majewski
Quoted 9 lines
Support for u-boot's "dfu <interface> <dev> [list]" command.
common/cmd_dfu.c new file +7
-0+U_BOOT_CMD (dfu,CONFIG_SYS_MAXARGS ,1 , do_dfu, +"Device Firmware Upgrade" , +"<interface> <dev> [list]\n" +" - device firmware upgrade on a device <dev>\n" +" attached to interface <interface>\n" +" [list] - list available alt settings" +);...
Quoted 15 lines
Quoted 6 lines
Somewhat related to this, it looks like the eMMC support doesn't allow the HW partition to be specified; it would be nice to expose alt settings for all of:
a) Each individual HW partition (boot0/1 if present, general0/1/2/3 if present, the user area, maybe the replay block)
I'm fully aware of this problem.
In the eMMC case, the access to boot partitions will be served by defining special alt settings for DFU.Those altsettings will be defined as follows:
(quoted diff) +0
-2-a[N] boot0 -a[N+1] boot1Quoted 8 lines
Quoted 3 lines
Prerequisite for this functionality is support of "boot" command, which will allow switching of the MMC available address spaces (e.g. between boot0/boot1 and user accessible space).
Is this "boot" command a DFU protocol command, or a U-Boot command-line command? I note that the U-Boot command-line already allows HW partition selection using an additional parameter to "mmc"
- "mmc dev $mmc_device_id $partition_id".
Quoted 5 lines
I'm rather thinking of a U-boot command (as it is easier to integrate). The command would be "mmc boot <dev> <params .. boot partition>"
Although it is not yet implemented, it is on the top of mine "TO DO" list :-).
I guess I'm confused what that "boot" command would actually do then... The only thing I can think that it might do is already covered by the "mmc" command's partition parameter.
Quoted 35 lines
Quoted 16 lines
Quoted 8 lines
Quoted 4 lines
b) Perhaps also a linearized view of the raw eMMC (LBAs 0..boot_size-1 write to boot 0, LBAs boot_size..(2*boot_size)-1 write to boot1, LBAs 2*boot_size..end_of_device write to user area for example).
Access to partitions will be done differently. I assume that each eMMC memory (the user accessible part) will be equipped with MBR or GPT definition.
That's a different kind of partition though.
In general, there's no need for the eMMC device to contain any kind of standardized SW-level partition table. On Tegra, the boot ROM can boot directly from an eMMC device, and that requires raw data in the partitions, not a standardized SW partition table.
Quoted 7 lines
Quoted 3 lines
For this reason I'm now developing the USB Mass Storage (UMS) gadget to export eMMC to host PC.
This solves the problem with accessing separate partitions.OK, if the raw eMMC device is exposed using USB storage, we should be able to dd directly to it and the presence-or-lack-thereof of any MBR/GPT wouldn't even be relevant.
With the UMS you would see the whole mmc address space as one partition. Then you can use dd with several parameters to "dump" data to a specific LBA address.
When correct MBR or GPT is present, then we can specify partitions to be accessed.
Quoted 3 lines
It'd still be useful to have a linearized view of the flash that concatenated all the HW partitions into a single raw device, but I guess an alt setting for that probably could be added later.
Quoted 7 lines
I think that UMS solves this issue. However, correct me if I'm wrong.
Let's assume, that UMS causes host to see following partitions:
sde: sde1 sde2 sde3 sde4 < sde5 .. sdeN >Is the "mount -t vfat
/dev/sde/mnt" not allowing access to the whole eMMC device (despite of the partitions)?
Again, this is confusing two different kinds of partitions.
There are HW-level partitions/regions/areas within the eMMC HW itself. You need to send commands to the eMMC device to select whether read/write commands act on the boot0/boot1/general*/user HW partition.
There are (or can be) SW-level partitions within any/all of those HW partitions. This is the level at which an MBR/GPT partition would exist.
With DFU, I'd expect an alt setting for each of the HW partitions at least.
With UMS, I'd expect a device to appear for each of the HW partitions. (these may show up as say /dev/sdb for boot0, /dev/sdc for boot1, /dev/sdd for the user area). If an MBR/GPT is present within any of those, Linux may then create a device for each SW partition, so e.g. /dev/sdd1, /dev/sdd2, etc.
PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command
Dear Stephen Warren,
Quoted 5 lines
Again, this is confusing two different kinds of partitions.
There are HW-level partitions/regions/areas within the eMMC HW itself. You need to send commands to the eMMC device to select whether read/write commands act on the boot0/boot1/general*/user HW partition.
This will be done via "mmc boot [dev] [HW partition (boot0/1/user]" command (from u-boot prompt).
This command is not yet implemented at u-boot (at least for Trats development board).
After its implementation it will be used as a helper function for dfu.
As a result the access to those partition will be done via proper DFU's alt settings:
mmc-boot0
mmc-boot1
etc.
Quoted 7 lines
There are (or can be) SW-level partitions within any/all of those HW partitions. This is the level at which an MBR/GPT partition would exist.
With DFU, I'd expect an alt setting for each of the HW partitions at least.
And this is my goal. Now only the "user" HW partition is supported. After "mmc boot ..." command implementation support for other partitions will be added for DFU as well.
Quoted 4 lines
With UMS, I'd expect a device to appear for each of the HW partitions. (these may show up as say
/dev/sdbfor boot0,/dev/sdcfor boot1,/dev/sddfor the user area).
Frankly speaking I've thought of providing access only to user HW partition for initial UMS implementation (the UMS v1 implementation). However access to all HW partitions from UMS is worth consideration.
Quoted 3 lines
If an MBR/GPT is present within any of
those, Linux may then create a device for each SW partition, so e.g./dev/sdd1,/dev/sdd2, etc.
This is the functionality which now UMS (v1) provides.
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command
Quoted 10 lines · Lukasz Majewski
Dear Stephen Warren,
Quoted 5 lines
Again, this is confusing two different kinds of partitions.
There are HW-level partitions/regions/areas within the eMMC HW itself. You need to send commands to the eMMC device to select whether read/write commands act on the boot0/boot1/general*/user HW partition.
This will be done via "mmc boot [dev] [HW partition (boot0/1/user]" command (from u-boot prompt).
Hmm. I still fail to see how this is any different to the existing "mmc dev" command. Are the following two commands not exactly identical:
mmc dev $dev $part # already exists today
mmc boot $dev $part # new command you're proposing
?
Quoted 3 lines
This command is not yet implemented at u-boot (at least for Trats development board).
After its implementation it will be used as a helper function for dfu.
PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command
Dear Stephen Warren,
Quoted 13 lines · Lukasz Majewski
Quoted 11 lines
Dear Stephen Warren,
Quoted 6 lines
Again, this is confusing two different kinds of partitions.
There are HW-level partitions/regions/areas within the eMMC HW itself. You need to send commands to the eMMC device to select whether read/write commands act on the boot0/boot1/general*/user HW partition.
This will be done via "mmc boot [dev] [HW partition (boot0/1/user]" command (from u-boot prompt).
Quoted 8 lines
Hmm. I still fail to see how this is any different to the existing "mmc dev" command. Are the following two commands not exactly identical:
mmc dev $dev $part # already exists today
mmc boot $dev $part # new command you're proposing?
You are totally right the $part part is the thing I'm looking for. I had in mind a previous version of "mmc dev" command with only the $dev part.
As I can see in the code - the mmc_switch() call does exactly the things that I need :-)
Quoted 6 lines
Quoted 5 lines
This command is not yet implemented at u-boot (at least for Trats development board).
After its implementation it will be used as a helper function for dfu.
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command
In reply to Lukasz Majewskicommon/cmd_dfu.c
Quoted 4 lines · On Tuesday 31 July 2012 02:37:01 Lukasz Majewski wrote:
common/cmd_dfu.c new file +1
-0+static char *s ="dfu" ;
no need for this to be static
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120801/a3fe945f/attachment.pgp>
PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command
Dear Mike Frysinger,
Quoted 7 lines · On Tuesday 31 July 2012 02:37:01 Lukasz Majewski wrote:
common/cmd_dfu.c
Quoted 4 lines
common/cmd_dfu.c new file +1
-0+static char *s ="dfu" ;no need for this to be static
It can be pulled out of the function and be made into const static
Quoted 1 line
-mike
Best regards,
Marek Vasut
PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command
Dear Marek Vasut,
Quoted 11 lines
Dear Mike Frysinger,
Quoted 7 lines · On Tuesday 31 July 2012 02:37:01 Lukasz Majewski wrote:
common/cmd_dfu.c
Quoted 4 lines
common/cmd_dfu.c new file +1
-0+static char *s ="dfu" ;no need for this to be static
It can be pulled out of the function and be made into const static
Ok.
Quoted 5 lines
Quoted 2 lines
-mike
Best regards,
Marek Vasut
Signature · 5 lines
Best regards, Lukasz Majewski Samsung Poland R&D Center | Linux Platform Group
PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command
In reply to Marek VasutQuoted 11 lines · On Thursday 02 August 2012 03:16:18 Marek Vasut wrote:
Dear Mike Frysinger,
Quoted 7 lines · On Tuesday 31 July 2012 02:37:01 Lukasz Majewski wrote:
common/cmd_dfu.c
Quoted 4 lines
common/cmd_dfu.c new file +1
-0+static char *s ="dfu" ;no need for this to be static
It can be pulled out of the function and be made into const static
err, there's no point. the static markings here are for the pointer "s", not the stuff it's pointing to "dfu".
use:
char s[] = "dfu";
and it'll probably all optimize away correctly
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120802/e8c413ea/attachment.pgp>
PATCH v3 6/7 arm:trats: Support for USB UDC driver at TRATS board.
In reply to Lukasz MajewskiSupport for USB UDC driver at trats board.
---
Changes for v2:
- replace puts to debug
--- board/samsung/trats/trats.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
board/samsung/trats/trats.c +8 -0
@@ -59,6 +59,8 @@ static int hwrevision(int rev)return (board_rev &0xf ) == rev; } +struct s3c_plat_otg_data s5pc210_otg_data; +int board_init (void ) { gd->bd->bi_boot_params =PHYS_SDRAM_1 +0x100 ;
@@ -259,6 +261,12 @@ struct s3c_plat_otg_data s5pc210_otg_data = { .usb_phy_ctrl = EXYNOS4_USBPHY_CONTROL, .usb_flags = PHY0_SLEEP, }; + +void board_usb_init (void ) +{ +debug ("USB_udc_probe\n" ); +s3c_udc_probe (&s5pc210_otg_data); +}#endif static void pmic_reset (void )
Signature · 1 line
1.7.2.3
PATCH v3 6/7 arm:trats: Support for USB UDC driver at TRATS board.
Quoted 7 lines · Lukasz Majewski
Support for USB UDC driver at trats board.
Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>Cc Minkyu Kang <[email protected]>
Quoted 7 lines
---
Changes for v2:
- replace puts to debug--- board/samsung/trats/trats.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
Thanks.
Minkyu Kang.
Signature · 2 lines
from. prom. www.promsoft.net
PATCH v3 7/7 arm:trats: Enable g_dnl composite USB gadget with embedded DFU function on TRATS
In reply to Lukasz MajewskiEnable the g_dnl composite USB gadget driver with embedded DFU function on it. It now uses the composite gadget framework to support download specific USB functions (like enabled DFU or USB Mass Storage).
---
Change for v2:
- Move the G_DNL_{VENDOR_NUM, PRODUCT_NUM and MANUFACTURER} definitions to ./include/configs/<board>.h
Changes for v3:
- None
--- include/configs/trats.h | 24 +++++++++++++++++++++++- 1 files changed, 23 insertions(+), 1 deletions(-)
include/configs/trats.h +23 -1
@@ -94,6 +94,21 @@#undef CONFIG_CMD_ONENAND#undef CONFIG_CMD_MTDPARTS#define CONFIG_CMD_MMC +#define CONFIG_CMD_DFU + +/* FAT */ +#define CONFIG_CMD_FAT +#define CONFIG_FAT_WRITE + +/* USB Composite download gadget - g_dnl */ +#define CONFIG_USBDOWNLOAD_GADGET +#define CONFIG_DFU_FUNCTION +#define CONFIG_DFU_MMC + +/* USB Samsung's IDs */ +#define CONFIG_G_DNL_VENDOR_NUM 0x04E8 +#define CONFIG_G_DNL_PRODUCT_NUM 0x6601 +#define CONFIG_G_DNL_MANUFACTURER "Samsung"#define CONFIG_BOOTDELAY 1#define CONFIG_ZERO_BOOTDELAY_CHECK
@@ -104,6 +119,11 @@#define CONFIG_BOOTBLOCK "10"#define CONFIG_ENV_COMMON_BOOT "${console} ${meminfo}" +#define CONFIG_DFU_ALT \ + "dfu_alt_info=" \ + "u-boot mmc 80 400;" \ + "uImage fat 0 2\0" \ +#define CONFIG_ENV_OVERWRITE #define CONFIG_SYS_CONSOLE_INFO_QUIET #define CONFIG_SYS_CONSOLE_IS_IN_ENV
@@ -146,7 +166,8 @@"mmcdev=0\0" \"mmcbootpart=2\0" \"mmcrootpart=3\0" \ -"opts=always_resume=1" +"opts=always_resume=1\0" \ +CONFIG_DFU_ALT /* Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP /* undef to save memory */
@@ -209,6 +230,7 @@#define CONFIG_USB_GADGET #define CONFIG_USB_GADGET_S3C_UDC_OTG #define CONFIG_USB_GADGET_DUALSPEED +#define CONFIG_USB_GADGET_VBUS_DRAW 2/* LCD */ #define CONFIG_EXYNOS_FB
Signature · 1 line
1.7.2.3
PATCH v3 7/7 arm:trats: Enable g_dnl composite USB gadget with embedded DFU function on TRATS
Quoted 14 lines · Lukasz Majewski
Enable the
g_dnlcomposite USB gadget driver with embedded DFU function on it. It now uses the composite gadget framework to support download specific USB functions (like enabled DFU or USB Mass Storage).Signed-off-by Lukasz Majewski <[email protected]>Signed-off-by Kyungmin Park <[email protected]>Cc Marek Vasut <[email protected]>Cc Minkyu Kang <[email protected]>---
Change for v2:
- Move the G_DNL_{VENDOR_NUM,PRODUCT_NUMand MANUFACTURER} definitions to ./include/configs/<board>.h
Quoted 6 lines
Changes for v3:
- None--- include/configs/trats.h | 24 +++++++++++++++++++++++- 1 files changed, 23 insertions(+), 1 deletions(-)
Thanks.
Minkyu Kang.
Signature · 2 lines
from. prom. www.promsoft.net
v4 cover dfu:usb: DFU support via USB Download gadget
In reply to Lukasz MajewskiThose patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
A separate DFU back-end and front-end have been added.
Back-end is placed at ./drivers/dfu directory. The front-end is implemented as USB function.
The back-end is written in a generic manner with storage device specific code separated (eMMC).
DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_standard
Example usage:
u-boot side: dfu mmc 0
PC: dfu-util -U IMAGE.bin -a uImage (for upload)
dfu-util -D uImage -a uImage (download)
To list the alt settings:
dfu mmc 0 list
Test HW:
Exynos4210 Trats board
Lukasz Majewski (7):
dfu:usb: Support for g_dnl composite download gadget. dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
dfu: DFU backend implementation
dfu: MMC specific routines for DFU operation
dfu:cmd: Support for DFU u-boot command
arm:trats: Support for USB UDC driver at TRATS board. arm:trats: Enable g_dnl composite USB gadget with embedded DFU
function on TRATS
Makefile | 1 + board/samsung/trats/trats.c | 8 + common/Makefile | 1 + common/cmd_dfu.c | 81 +++++ drivers/dfu/Makefile | 44 +++ drivers/dfu/dfu.c | 239 ++++++++++++++ drivers/dfu/dfu_mmc.c | 162 ++++++++++ drivers/usb/gadget/Makefile | 2 + drivers/usb/gadget/f_dfu.c | 749 +++++++++++++++++++++++++++++++++++++++++++ drivers/usb/gadget/f_dfu.h | 100 ++++++ drivers/usb/gadget/g_dnl.c | 202 ++++++++++++ include/configs/trats.h | 24 ++- include/dfu.h | 103 ++++++ include/g_dnl.h | 33 ++ 14 files changed, 1748 insertions(+), 1 deletions(-) create mode 100644 common/cmd_dfu.c create mode 100644 drivers/dfu/Makefile create mode 100644 drivers/dfu/dfu.c create mode 100644 drivers/dfu/dfu_mmc.c create mode 100644 drivers/usb/gadget/f_dfu.c create mode 100644 drivers/usb/gadget/f_dfu.h create mode 100644 drivers/usb/gadget/g_dnl.c create mode 100644 include/dfu.h create mode 100644 include/g_dnl.h
Signature · 1 line
1.7.2.3
PATCH v4 1/7 dfu:usb: Support for g_dnl composite download gadget.
Composite USB download gadget support (g_dnl) for download functions. This code works on top of composite gadget.
---
Changes for v2:
- G_DNL_{VENDOR_NUM, PRODUCT_NUM and MANUFACTURER} defined at ./include/configs/<board>.h
- Suspend and resume stub methods removed
- '\0' repleaced with plain 0
Changes for v3:
- Remove unused #includes
- Replace strncpy and strncat with strcpy and strcat. It was possible due to new approach to g_dnl name generation (at g_dnl_register function)
- Rename the g_dnl_{init|cleanup} to g_dnl_{register|unregister}
- Replace the G_DNL_* CONFIG_G_DNL_*
Changes for v4:
- Remove unnecessary otg calls
- odin prefix replaced with g_dnl
- Single space indentation between type and variable name
--- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/g_dnl.c | 202 +++++++++++++++++++++++++++++++++++++++++++ include/g_dnl.h | 33 +++++++ 3 files changed, 236 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/g_dnl.c create mode 100644 include/g_dnl.h
drivers/usb/gadget/Makefile +1 -0
@@ -29,6 +29,7 @@ LIB := $(obj)libusb_gadget.o 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 endif ifdef CONFIG_USB_ETHER COBJS-y += ether.o epautoconf.o config.o usbstring.o
drivers/usb/gadget/g_dnl.c new file +202 -0
202 lines not on this page · raw message
include/g_dnl.h new file +33 -0
@@ -0,0 +1,33 @@ +/* +* Copyright (C) 2012 Samsung Electronics +* Lukasz Majewski <[email protected]> +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License as +* published by the Free Software Foundation; either version 2 of +* the License, or (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, +* MA 02111-1307 USA +*/ + +#ifndef __G_DOWNLOAD_H_ +#define __G_DOWNLOAD_H_ + +#include <linux/usb/ch9.h> +#include <usbdescriptors.h> +#include <linux/usb/gadget.h> + +int g_dnl_register (const char *s); +void g_dnl_unregister (void ); + +/* USB initialization declaration - board specific */ +void board_usb_init (void ); +#endif /* __G_DOWNLOAD_H_ */
Signature · 1 line
1.7.2.3
PATCH v4 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
In reply to Lukasz MajewskiSupport for f_dfu USB function.
---
Changes for v2:
- Replace kzalloc and kfree with free and calloc
- Reorganization of calloc calls
- Misspelling corrected
- Redesign of DFU state machine from "switch case" to function pointers
- Split the dfu_handle method to separate functions for each DFU state
Changes for v3:
- Missing parenthesis added to sizeof call
Changes for v4:
- Replace two puts with one
- Remove the 0xff at handle_getstate function
- Add const qualifier to struct definitions when possible
--- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/f_dfu.c | 749 +++++++++++++++++++++++++++++++++++++++++++ drivers/usb/gadget/f_dfu.h | 100 ++++++ 3 files changed, 850 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/f_dfu.c create mode 100644 drivers/usb/gadget/f_dfu.h
drivers/usb/gadget/Makefile +1 -0
@@ -30,6 +30,7 @@ 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
drivers/usb/gadget/f_dfu.c new file +749 -0
749 lines not on this page · raw message
drivers/usb/gadget/f_dfu.h new file +100 -0
100 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v4 3/7 dfu: DFU backend implementation
In reply to Lukasz MajewskiNew, separate driver at ./drivers/dfu has been added. It allows platform and storage independent operation of DFU.
It has been extended to use new MMC level of command abstraction.
---
Changes for v2:
- None
Changes for v3:
- Remove unnecessary NULL and 0 initialization of dynamic variables
- Combine two puts to one
- Adding const qualifier to device and layout definitions
- Remove unnecessary casting at dfu->name passing
- Provide more meaningful names for dfu layouts and device types
- Removal of dfu_extract_{token|entity} functions and replace them with strsep calls
Changes for v4:
- Remove unnecessary memset
- const added where applicable
- Handling calloc failure in dfu_config_entries()
--- Makefile | 1 + drivers/dfu/Makefile | 43 +++++++++ drivers/dfu/dfu.c | 239 ++++++++++++++++++++++++++++++++++++++++++++++++++ include/dfu.h | 103 ++++++++++++++++++++++ 4 files changed, 386 insertions(+), 0 deletions(-) create mode 100644 drivers/dfu/Makefile create mode 100644 drivers/dfu/dfu.c create mode 100644 include/dfu.h
Makefile +1 -0
@@ -271,6 +271,7 @@ LIBS += drivers/pci/libpci.o LIBS += drivers/pcmcia/libpcmcia.o LIBS += drivers/power/libpower.o LIBS += drivers/spi/libspi.o +LIBS += drivers/dfu/libdfu.o ifeq ($(CPU),mpc83xx) LIBS += drivers/qe/libqe.o LIBS += arch/powerpc/cpu/mpc8xxx/ddr/libddr.o
drivers/dfu/Makefile new file +43 -0
43 lines not on this page · raw message
drivers/dfu/dfu.c new file +239 -0
239 lines not on this page · raw message
include/dfu.h new file +103 -0
103 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v4 4/7 dfu: MMC specific routines for DFU operation
In reply to Lukasz MajewskiSupport for MMC storage devices to work with DFU framework.
---
Changes for v2:
- None
Changes for v3:
- Provide special abstraction layer (mmc_{block|file}_{read|write}) to alleviate switch to new device model (DM)
- More verbose messages when not supported layout encountered
- Calls to strncmp() replaced with strcmp()
Changes for v4:
- Remove superfluous memset() calls
- Replace ALLOC_CACHE_ALIGN_BUFFER with plain table definition
- Cosmetic changes with pointers definition
--- drivers/dfu/Makefile | 1 + drivers/dfu/dfu_mmc.c | 162 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 163 insertions(+), 0 deletions(-) create mode 100644 drivers/dfu/dfu_mmc.c
drivers/dfu/Makefile +1 -0
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk LIB = $(obj)libdfu.o COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o +COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o SRCS := $(COBJS-y:.o=.c) OBJS := $(addprefix $(obj),$(COBJS-y))
drivers/dfu/dfu_mmc.c new file +162 -0
162 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v4 5/7 dfu:cmd: Support for DFU u-boot command
In reply to Lukasz MajewskiSupport for u-boot's command line command "dfu <interface> <dev> [list]".
---
Changes for v2:
- None
Changes for v3:
- Remove unnecessary initialization to NULL of dynamic variables
- goto done added to reduce code duplication
- static definition of do_dfu()
Changes for v4:
- Define "dfu" string as an array
--- common/Makefile | 1 + common/cmd_dfu.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 82 insertions(+), 0 deletions(-) create mode 100644 common/cmd_dfu.c
common/Makefile +1 -0
@@ -183,6 +183,7 @@ COBJS-$(CONFIG_MENU) += menu.o COBJS-$(CONFIG_MODEM_SUPPORT) += modem.o COBJS-$(CONFIG_UPDATE_TFTP) += update.o COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o +COBJS-$(CONFIG_CMD_DFU) += cmd_dfu.o endif ifdef CONFIG_SPL_BUILD
common/cmd_dfu.c new file +81 -0
81 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v4 6/7 arm:trats: Support for USB UDC driver at TRATS board.
In reply to Lukasz MajewskiSupport for USB UDC driver at trats board.
---
Changes for v2:
- replace puts to debug
--- board/samsung/trats/trats.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
board/samsung/trats/trats.c +8 -0
@@ -59,6 +59,8 @@ static int hwrevision(int rev)return (board_rev &0xf ) == rev; } +struct s3c_plat_otg_data s5pc210_otg_data; +int board_init (void ) { gd->bd->bi_boot_params =PHYS_SDRAM_1 +0x100 ;
@@ -259,6 +261,12 @@ struct s3c_plat_otg_data s5pc210_otg_data = { .usb_phy_ctrl = EXYNOS4_USBPHY_CONTROL, .usb_flags = PHY0_SLEEP, }; + +void board_usb_init (void ) +{ +debug ("USB_udc_probe\n" ); +s3c_udc_probe (&s5pc210_otg_data); +}#endif static void pmic_reset (void )
Signature · 1 line
1.7.2.3
PATCH v4 7/7 arm:trats: Enable g_dnl composite USB gadget with embedded DFU function on TRATS
In reply to Lukasz MajewskiEnable the g_dnl composite USB gadget driver with embedded DFU function on it. It now uses the composite gadget framework to support download specific USB functions (like enabled DFU or USB Mass Storage).
---
Change for v2:
- Move the G_DNL_{VENDOR_NUM, PRODUCT_NUM and MANUFACTURER} definitions to ./include/configs/<board>.h
Changes for v3:
- None
--- include/configs/trats.h | 24 +++++++++++++++++++++++- 1 files changed, 23 insertions(+), 1 deletions(-)
include/configs/trats.h +23 -1
@@ -94,6 +94,21 @@#undef CONFIG_CMD_ONENAND#undef CONFIG_CMD_MTDPARTS#define CONFIG_CMD_MMC +#define CONFIG_CMD_DFU + +/* FAT */ +#define CONFIG_CMD_FAT +#define CONFIG_FAT_WRITE + +/* USB Composite download gadget - g_dnl */ +#define CONFIG_USBDOWNLOAD_GADGET +#define CONFIG_DFU_FUNCTION +#define CONFIG_DFU_MMC + +/* USB Samsung's IDs */ +#define CONFIG_G_DNL_VENDOR_NUM 0x04E8 +#define CONFIG_G_DNL_PRODUCT_NUM 0x6601 +#define CONFIG_G_DNL_MANUFACTURER "Samsung"#define CONFIG_BOOTDELAY 1#define CONFIG_ZERO_BOOTDELAY_CHECK
@@ -104,6 +119,11 @@#define CONFIG_BOOTBLOCK "10"#define CONFIG_ENV_COMMON_BOOT "${console} ${meminfo}" +#define CONFIG_DFU_ALT \ + "dfu_alt_info=" \ + "u-boot mmc 80 400;" \ + "uImage fat 0 2\0" \ +#define CONFIG_ENV_OVERWRITE #define CONFIG_SYS_CONSOLE_INFO_QUIET #define CONFIG_SYS_CONSOLE_IS_IN_ENV
@@ -146,7 +166,8 @@"mmcdev=0\0" \"mmcbootpart=2\0" \"mmcrootpart=3\0" \ -"opts=always_resume=1" +"opts=always_resume=1\0" \ +CONFIG_DFU_ALT /* Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP /* undef to save memory */
@@ -209,6 +230,7 @@#define CONFIG_USB_GADGET #define CONFIG_USB_GADGET_S3C_UDC_OTG #define CONFIG_USB_GADGET_DUALSPEED +#define CONFIG_USB_GADGET_VBUS_DRAW 2/* LCD */ #define CONFIG_EXYNOS_FB
Signature · 1 line
1.7.2.3
v5 cover dfu:usb: DFU support via USB Download gadget
In reply to Lukasz MajewskiThose patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
A separate DFU back-end and front-end have been added.
Back-end is placed at ./drivers/dfu directory. The front-end is implemented as USB function.
The back-end is written in a generic manner with storage device specific code separated (eMMC).
DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_standard
Example usage:
u-boot side: dfu mmc 0
PC: dfu-util -U IMAGE.bin -a uImage (for upload)
dfu-util -D uImage -a uImage (download)
To list the alt settings:
dfu mmc 0 list
Test HW:
Exynos4210 Trats board
Lukasz Majewski (7):
dfu:usb: Support for g_dnl composite download gadget. dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
dfu: DFU backend implementation
dfu: MMC specific routines for DFU operation
dfu:cmd: Support for DFU u-boot command
arm:trats: Support for USB UDC driver at TRATS board. arm:trats: Enable g_dnl composite USB gadget with embedded DFU
function on TRATS
Makefile | 1 + board/samsung/trats/trats.c | 8 + common/Makefile | 1 + common/cmd_dfu.c | 81 +++++ drivers/dfu/Makefile | 44 +++ drivers/dfu/dfu.c | 238 ++++++++++++++ drivers/dfu/dfu_mmc.c | 162 ++++++++++ drivers/usb/gadget/Makefile | 2 + drivers/usb/gadget/f_dfu.c | 749 +++++++++++++++++++++++++++++++++++++++++++ drivers/usb/gadget/f_dfu.h | 100 ++++++ drivers/usb/gadget/g_dnl.c | 202 ++++++++++++ include/configs/trats.h | 24 ++- include/dfu.h | 103 ++++++ include/g_dnl.h | 33 ++ 14 files changed, 1747 insertions(+), 1 deletions(-) create mode 100644 common/cmd_dfu.c create mode 100644 drivers/dfu/Makefile create mode 100644 drivers/dfu/dfu.c create mode 100644 drivers/dfu/dfu_mmc.c create mode 100644 drivers/usb/gadget/f_dfu.c create mode 100644 drivers/usb/gadget/f_dfu.h create mode 100644 drivers/usb/gadget/g_dnl.c create mode 100644 include/dfu.h create mode 100644 include/g_dnl.h
Signature · 1 line
1.7.2.3
PATCH v5 1/7 dfu:usb: Support for g_dnl composite download gadget.
Composite USB download gadget support (g_dnl) for download functions. This code works on top of composite gadget.
---
Changes for v2:
- G_DNL_{VENDOR_NUM, PRODUCT_NUM and MANUFACTURER} defined at ./include/configs/<board>.h
- Suspend and resume stub methods removed
- '\0' repleaced with plain 0
Changes for v3:
- Remove unused #includes
- Replace strncpy and strncat with strcpy and strcat. It was possible due to new approach to g_dnl name generation (at g_dnl_register function)
- Rename the g_dnl_{init|cleanup} to g_dnl_{register|unregister}
- Replace the G_DNL_* CONFIG_G_DNL_*
Changes for v4:
- Remove unnecessary otg calls
- odin prefix replaced with g_dnl
- Single space indentation between type and variable name
Changes for v5:
- None
--- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/g_dnl.c | 202 +++++++++++++++++++++++++++++++++++++++++++ include/g_dnl.h | 33 +++++++ 3 files changed, 236 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/g_dnl.c create mode 100644 include/g_dnl.h
drivers/usb/gadget/Makefile +1 -0
@@ -29,6 +29,7 @@ LIB := $(obj)libusb_gadget.o 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 endif ifdef CONFIG_USB_ETHER COBJS-y += ether.o epautoconf.o config.o usbstring.o
drivers/usb/gadget/g_dnl.c new file +202 -0
202 lines not on this page · raw message
include/g_dnl.h new file +33 -0
@@ -0,0 +1,33 @@ +/* +* Copyright (C) 2012 Samsung Electronics +* Lukasz Majewski <[email protected]> +* +* This program is free software; you can redistribute it and/or +* modify it under the terms of the GNU General Public License as +* published by the Free Software Foundation; either version 2 of +* the License, or (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, +* MA 02111-1307 USA +*/ + +#ifndef __G_DOWNLOAD_H_ +#define __G_DOWNLOAD_H_ + +#include <linux/usb/ch9.h> +#include <usbdescriptors.h> +#include <linux/usb/gadget.h> + +int g_dnl_register (const char *s); +void g_dnl_unregister (void ); + +/* USB initialization declaration - board specific */ +void board_usb_init (void ); +#endif /* __G_DOWNLOAD_H_ */
Signature · 1 line
1.7.2.3
PATCH v5 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget
In reply to Lukasz MajewskiSupport for f_dfu USB function.
---
Changes for v2:
- Replace kzalloc and kfree with free and calloc
- Reorganization of calloc calls
- Misspelling corrected
- Redesign of DFU state machine from "switch case" to function pointers
- Split the dfu_handle method to separate functions for each DFU state
Changes for v3:
- Missing parenthesis added to sizeof call
Changes for v4:
- Replace two puts with one
- Remove the 0xff at handle_getstate function
- Add const qualifier to struct definitions when possible
Changes for v5:
- None
--- drivers/usb/gadget/Makefile | 1 + drivers/usb/gadget/f_dfu.c | 749 +++++++++++++++++++++++++++++++++++++++++++ drivers/usb/gadget/f_dfu.h | 100 ++++++ 3 files changed, 850 insertions(+), 0 deletions(-) create mode 100644 drivers/usb/gadget/f_dfu.c create mode 100644 drivers/usb/gadget/f_dfu.h
drivers/usb/gadget/Makefile +1 -0
@@ -30,6 +30,7 @@ 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
drivers/usb/gadget/f_dfu.c new file +749 -0
749 lines not on this page · raw message
drivers/usb/gadget/f_dfu.h new file +100 -0
100 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v5 3/7 dfu: DFU backend implementation
In reply to Lukasz MajewskiNew, separate driver at ./drivers/dfu has been added. It allows platform and storage independent operation of DFU.
It has been extended to use new MMC level of command abstraction.
---
Changes for v2:
- None
Changes for v3:
- Remove unnecessary NULL and 0 initialization of dynamic variables
- Combine two puts to one
- Adding const qualifier to device and layout definitions
- Remove unnecessary casting at dfu->name passing
- Provide more meaningful names for dfu layouts and device types
- Removal of dfu_extract_{token|entity} functions and replace them with strsep calls
Changes for v4:
- Remove unnecessary memset
- const added where applicable
- Handling calloc failure in dfu_config_entries()
Changes for v5:
- Replace several calls to calloc(sizeof(struct dfu_entity), 1); with only one, done outside the for loop
--- Makefile | 1 + drivers/dfu/Makefile | 43 +++++++++ drivers/dfu/dfu.c | 238 ++++++++++++++++++++++++++++++++++++++++++++++++++ include/dfu.h | 103 ++++++++++++++++++++++ 4 files changed, 385 insertions(+), 0 deletions(-) create mode 100644 drivers/dfu/Makefile create mode 100644 drivers/dfu/dfu.c create mode 100644 include/dfu.h
Makefile +1 -0
@@ -271,6 +271,7 @@ LIBS += drivers/pci/libpci.o LIBS += drivers/pcmcia/libpcmcia.o LIBS += drivers/power/libpower.o LIBS += drivers/spi/libspi.o +LIBS += drivers/dfu/libdfu.o ifeq ($(CPU),mpc83xx) LIBS += drivers/qe/libqe.o LIBS += arch/powerpc/cpu/mpc8xxx/ddr/libddr.o
drivers/dfu/Makefile new file +43 -0
43 lines not on this page · raw message
drivers/dfu/dfu.c new file +238 -0
238 lines not on this page · raw message
include/dfu.h new file +103 -0
103 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v5 4/7 dfu: MMC specific routines for DFU operation
In reply to Lukasz MajewskiSupport for MMC storage devices to work with DFU framework.
---
Changes for v2:
- None
Changes for v3:
- Provide special abstraction layer (mmc_{block|file}_{read|write}) to alleviate switch to new device model (DM)
- More verbose messages when not supported layout encountered
- Calls to strncmp() replaced with strcmp()
Changes for v4:
- Remove superfluous memset() calls
- Replace ALLOC_CACHE_ALIGN_BUFFER with plain table definition
- Cosmetic changes with pointers definition
Changes for v5:
- None
--- drivers/dfu/Makefile | 1 + drivers/dfu/dfu_mmc.c | 162 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 163 insertions(+), 0 deletions(-) create mode 100644 drivers/dfu/dfu_mmc.c
drivers/dfu/Makefile +1 -0
@@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk LIB = $(obj)libdfu.o COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o +COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o SRCS := $(COBJS-y:.o=.c) OBJS := $(addprefix $(obj),$(COBJS-y))
drivers/dfu/dfu_mmc.c new file +162 -0
162 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v5 5/7 dfu:cmd: Support for DFU u-boot command
In reply to Lukasz MajewskiSupport for u-boot's command line command "dfu <interface> <dev> [list]".
---
Changes for v2:
- None
Changes for v3:
- Remove unnecessary initialization to NULL of dynamic variables
- goto done added to reduce code duplication
- static definition of do_dfu()
Changes for v4:
- Define "dfu" string as an array
Changes for v5:
- None
--- common/Makefile | 1 + common/cmd_dfu.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 82 insertions(+), 0 deletions(-) create mode 100644 common/cmd_dfu.c
common/Makefile +1 -0
@@ -183,6 +183,7 @@ COBJS-$(CONFIG_MENU) += menu.o COBJS-$(CONFIG_MODEM_SUPPORT) += modem.o COBJS-$(CONFIG_UPDATE_TFTP) += update.o COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o +COBJS-$(CONFIG_CMD_DFU) += cmd_dfu.o endif ifdef CONFIG_SPL_BUILD
common/cmd_dfu.c new file +81 -0
81 lines not on this page · raw message
Signature · 1 line
1.7.2.3
PATCH v5 6/7 arm:trats: Support for USB UDC driver at TRATS board.
In reply to Lukasz MajewskiSupport for USB UDC driver at trats board.
---
Changes for v2:
- replace puts to debug
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
--- board/samsung/trats/trats.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
board/samsung/trats/trats.c +8 -0
@@ -59,6 +59,8 @@ static int hwrevision(int rev)return (board_rev &0xf ) == rev; } +struct s3c_plat_otg_data s5pc210_otg_data; +int board_init (void ) { gd->bd->bi_boot_params =PHYS_SDRAM_1 +0x100 ;
@@ -259,6 +261,12 @@ struct s3c_plat_otg_data s5pc210_otg_data = { .usb_phy_ctrl = EXYNOS4_USBPHY_CONTROL, .usb_flags = PHY0_SLEEP, }; + +void board_usb_init (void ) +{ +debug ("USB_udc_probe\n" ); +s3c_udc_probe (&s5pc210_otg_data); +}#endif static void pmic_reset (void )
Signature · 1 line
1.7.2.3
PATCH v5 7/7 arm:trats: Enable g_dnl composite USB gadget with embedded DFU function on TRATS
In reply to Lukasz MajewskiEnable the g_dnl composite USB gadget driver with embedded DFU function on it. It now uses the composite gadget framework to support download specific USB functions (like enabled DFU or USB Mass Storage).
---
Change for v2:
- Move the G_DNL_{VENDOR_NUM, PRODUCT_NUM and MANUFACTURER} definitions to ./include/configs/<board>.h
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
--- include/configs/trats.h | 24 +++++++++++++++++++++++- 1 files changed, 23 insertions(+), 1 deletions(-)
include/configs/trats.h +23 -1
@@ -94,6 +94,21 @@#undef CONFIG_CMD_ONENAND#undef CONFIG_CMD_MTDPARTS#define CONFIG_CMD_MMC +#define CONFIG_CMD_DFU + +/* FAT */ +#define CONFIG_CMD_FAT +#define CONFIG_FAT_WRITE + +/* USB Composite download gadget - g_dnl */ +#define CONFIG_USBDOWNLOAD_GADGET +#define CONFIG_DFU_FUNCTION +#define CONFIG_DFU_MMC + +/* USB Samsung's IDs */ +#define CONFIG_G_DNL_VENDOR_NUM 0x04E8 +#define CONFIG_G_DNL_PRODUCT_NUM 0x6601 +#define CONFIG_G_DNL_MANUFACTURER "Samsung"#define CONFIG_BOOTDELAY 1#define CONFIG_ZERO_BOOTDELAY_CHECK
@@ -104,6 +119,11 @@#define CONFIG_BOOTBLOCK "10"#define CONFIG_ENV_COMMON_BOOT "${console} ${meminfo}" +#define CONFIG_DFU_ALT \ + "dfu_alt_info=" \ + "u-boot mmc 80 400;" \ + "uImage fat 0 2\0" \ +#define CONFIG_ENV_OVERWRITE #define CONFIG_SYS_CONSOLE_INFO_QUIET #define CONFIG_SYS_CONSOLE_IS_IN_ENV
@@ -146,7 +166,8 @@"mmcdev=0\0" \"mmcbootpart=2\0" \"mmcrootpart=3\0" \ -"opts=always_resume=1" +"opts=always_resume=1\0" \ +CONFIG_DFU_ALT /* Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP /* undef to save memory */
@@ -209,6 +230,7 @@#define CONFIG_USB_GADGET #define CONFIG_USB_GADGET_S3C_UDC_OTG #define CONFIG_USB_GADGET_DUALSPEED +#define CONFIG_USB_GADGET_VBUS_DRAW 2/* LCD */ #define CONFIG_EXYNOS_FB
Signature · 1 line
1.7.2.3
v5 cover dfu:usb: DFU support via USB Download gadget
In reply to Lukasz MajewskiDear Lukasz Majewski,
Quoted 7 lines
Those patches add support for composite USB download gadget. This gadget (at least for now) is equipped with DFU download function.
A separate DFU back-end and front-end have been added.
Back-end is placed at./drivers/dfudirectory. The front-end is implemented as USB function.
Quoted 6 lines
The back-end is written in a generic manner with storage device specific code separated (eMMC).
DFU specification can be found at:
http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_sta
ndard
[...]
Applied the series and pushed to u-boot-usb ... now guys, please do final rounds of tests etc. so I can submit pullRQ.
Best regards,
Marek Vasut