Skip to contentSkip to conversation

dfu:usb: Composite USB download gadget with DFU function

PATCH Superseded Lukasz Majewski 11 participants 147 messages Jul 3, 2012 – Aug 6, 2012

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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
#1 lore raw

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
index 87d1918..2c067c8 100644
@@ -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
new file mode 100644
index 0000000..5d0e9a5
@@ -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
#2 lore raw

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.

---
 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
index 87d1918..2c067c8 100644
@@ -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 +19 -0
new file mode 100644
index 0000000..7925d0e
@@ -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
new file mode 100644
index 0000000..5d0e9a5
@@ -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_ */
#3 lore raw

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.

---
 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 -0

b/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.o
drivers/usb/gadget/g_dnl.c new file +7 -0
new file mode 100644
index 0000000..7925d0e
@@ -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 0x6601

Is 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 *) &(struct

usb_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
new file mode 100644
index 0000000..5d0e9a5
@@ -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
#4 lore raw

PATCH 1/7 dfu:usb: Support for g_dnl composite download gadget.

In reply to Lukasz Majewski

drivers/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>

#5 lore raw

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
#6 lore raw

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>

#7 lore raw

PATCH 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget

In reply to Lukasz Majewski

Support 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
index 2c067c8..5bbdd36 100644
@@ -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
#8 lore raw

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_dfu USB function.

---

[...]

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 :-(

#9 lore raw

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_dfu USB function.

---

[...]

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 as malloc(), 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
#10 lore raw

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_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

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->buf is 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 as malloc(), 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 :)

[...]

#11 lore raw

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_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

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->buf is 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 as malloc(), 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
#12 lore raw

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->buf is 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->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.

OK, then it's good :)

[...]

Best regards,
Marek Vasut

#13 lore raw

PATCH 3/7 dfu: DFU backend implementation

In reply to Lukasz Majewski

New, 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
index 0197239..c37dcf3 100644
@@ -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
#14 lore raw

PATCH 3/7 dfu: DFU backend implementation

Dear Lukasz Majewski,

Quoted 7 lines

New, separate driver at ./drivers/dfu has been added. It allows platform and storage independent operation of DFU.

---

[...]

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
new file mode 100644
index 0000000..f7d823b

[...]

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 ;-)

[...]

#15 lore raw

PATCH 3/7 dfu: DFU backend implementation

Hi Marek,

Quoted 36 lines

Dear Lukasz Majewski,

Quoted 7 lines

New, separate driver at ./drivers/dfu has been added. It allows platform and storage independent operation of DFU.

---

[...]

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
new file mode 100644
index 0000000..f7d823b

[...]

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
#16 lore raw

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/dfu has been added. It allows platform and storage independent operation of DFU.

---

[...]

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 from string.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_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.

Heh, agreed :-)

Quoted 23 lines
Quoted 10 lines

[...]

Quoted 5 lines
include/dfu.h new file +0 -0
new file mode 100644
index 0000000..f7d823b

[...]

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_data onenand.

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

#17 lore raw

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/dfu has been added. It allows platform and storage independent operation of DFU.

---

[...]

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 from string.c

Good 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_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.

Heh, agreed :-)

Quoted 23 lines
Quoted 22 lines

[...]

Quoted 5 lines
include/dfu.h new file +0 -0
new file mode 100644
index 0000000..f7d823b

[...]

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_data onenand.

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
#18 lore raw

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 my

head, that support for this memory is important :-)

Good, will look forward to it :)

Best regards,
Marek Vasut

#19 lore raw

PATCH 3/7 dfu: DFU backend implementation

In reply to Lukasz Majewski

drivers/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_type t)

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_type l)

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>

#20 lore raw

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_type t)

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_type l)

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
#21 lore raw

PATCH 4/7 dfu: MMC specific routines for DFU operation

In reply to Lukasz Majewski

Support 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
index 7736485..7b717bc 100644
@@ -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
#22 lore raw

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.

---

[...]

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

#23 lore raw

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.

---

[...]

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
#24 lore raw

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.

---

[...]

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_WRITE for writing to fat and so forth.

Well ain't it easier to call fat_write() or similar?

Best regards,
Marek Vasut

#25 lore raw

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.

---

[...]

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_WRITE for 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
#26 lore raw

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_WRITE for 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.

Abstracting it out into a function won't cut it?

Best regards,
Marek Vasut

#27 lore raw

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_WRITE for 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_fswrite is 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
#28 lore raw

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_WRITE for 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_fswrite is 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?

#29 lore raw

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_WRITE for 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.

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
#30 lore raw

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_WRITE for 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.

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?

#31 lore raw

PATCH 4/7 dfu: MMC specific routines for DFU operation

In reply to Tom Rini

Dear 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_WRITE for 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_fswrite is 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

#32 lore raw

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_WRITE for 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.

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>

#33 lore raw

PATCH 4/7 dfu: MMC specific routines for DFU operation

In reply to Marek Vasut

Hi 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.

---

[...]

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_WRITE for 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
#34 lore raw

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_WRITE for 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_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.

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_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?

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

#35 lore raw

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_WRITE for 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.

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_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?

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 calls
mmc->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
#36 lore raw

PATCH 5/7 dfu:cmd: Support for DFU u-boot command

In reply to Lukasz Majewski

Support 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
index 6e23baa..de43ead 100644
@@ -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
#37 lore raw

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]".

---

[...]

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

#38 lore raw

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]".

---

[...]

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 not

defined!\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
#39 lore raw

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]".

---

[...]

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 not

defined!\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

#40 lore raw

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 __stringify patch 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>

#41 lore raw

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 __stringify patch 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.

Helps find out the problematic place in code ...

Quoted 1 line

-mike

Best regards,
Marek Vasut

#42 lore raw

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 __stringify patch 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.

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>

#43 lore raw

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 __stringify patch 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.

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

#44 lore raw

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 __stringify patch 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.

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>
#45 lore raw

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 __stringify patch 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.

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

#46 lore raw

PATCH 5/7 dfu:cmd: Support for DFU u-boot command

In reply to Marek Vasut
Quoted 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>

#47 lore raw

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

#48 lore raw

PATCH 5/7 dfu:cmd: Support for DFU u-boot command

In reply to Lukasz Majewski

common/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>

#49 lore raw

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 * const

argv[])

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_env should 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
#50 lore raw

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 * const

argv[])

static

Quoted 5 lines

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.

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>

#51 lore raw

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 * const

argv[])

static

Quoted 5 lines

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.

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_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

Thanks for clarification

Regards,
Lukasz Majewski

#52 lore raw

PATCH 6/7 arm:trats: Support for USB UDC driver at TRATS board.

In reply to Lukasz Majewski

Support 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
index a95a516..2f3a531 100644
@@ -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
#53 lore raw

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.

---
 board/samsung/trats/trats.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)
board/samsung/trats/trats.c +2 -0
index a95a516..2f3a531 100644
@@ -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
#54 lore raw

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.

---
 board/samsung/trats/trats.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)
(quoted diff) +0 -0

b/board/samsung/trats/trats.c index a95a516..2f3a531 100644

board/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
#55 lore raw

PATCH 7/7 arm:trats: Enable g_dnl composite USB gadget with embedded DFU function on TRATS

In reply to Lukasz Majewski

Enable 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
index 2f96a18..dcbd198 100644
@@ -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
#56 lore raw

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_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).

Quoted 8 lines
---
 include/configs/trats.h |   19 ++++++++++++++++++-
 1 files changed, 18 insertions(+), 1 deletions(-)
Signature · 2 lines
from. prom.
www.promsoft.net
#57 lore raw

cover dfu:usb: Composite USB download gadget with DFU function

In reply to Lukasz Majewski
Quoted 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
#58 lore raw

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

#59 lore raw

v2 cover dfu:usb: Composite USB download gadget with DFU function

In reply to Lukasz Majewski

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 |    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
#60 lore raw

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
index 87d1918..2c067c8 100644
@@ -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
new file mode 100644
index 0000000..5d0e9a5
@@ -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
#61 lore raw

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.

---
Changes for v2:

- G_DNL_{VENDOR_NUM, PRODUCT_NUM and MANUFACTURER} defined at

make this CONFIG_G_....

The rest seems ok.

Best regards,
Marek Vasut

#62 lore raw

PATCH v2 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget

In reply to Lukasz Majewski

Support 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
index 2c067c8..5bbdd36 100644
@@ -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
#63 lore raw

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_dfu USB function.

[...]

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 ?

[...]

#64 lore raw

PATCH v2 3/7 dfu: DFU backend implementation

In reply to Lukasz Majewski

New, 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
index 0197239..c37dcf3 100644
@@ -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
#65 lore raw

PATCH v2 3/7 dfu: DFU backend implementation

Dear Lukasz Majewski,

Quoted 7 lines

New, separate driver at ./drivers/dfu has been added. It allows platform and storage independent operation of DFU.

[...]

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

#66 lore raw

PATCH v2 3/7 dfu: DFU backend implementation

In reply to Lukasz Majewski

Dear Lukasz Majewski,

Quoted 2 lines · In message <[email protected]> you wrote:

New, separate driver at ./drivers/dfu has 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
#67 lore raw

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/dfu has 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
#68 lore raw

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 define dfu_onenand.c file 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
#69 lore raw

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
#70 lore raw

PATCH v2 4/7 dfu: MMC specific routines for DFU operation

In reply to Lukasz Majewski

Support 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
index 7736485..7b717bc 100644
@@ -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
#71 lore raw

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.

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

#72 lore raw

PATCH v2 4/7 dfu: MMC specific routines for DFU operation

In reply to Lukasz Majewski
Quoted 5 lines · Lukasz Majewski

Support for MMC storage devices to work with DFU framework.

[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>
#73 lore raw

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.

[snip]

Quoted 13 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 +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 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.

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
#74 lore raw

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.

[snip]

Quoted 13 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 +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().

Quoted 8 lines

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);
}

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
#75 lore raw

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.

[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, then simple_strtoul and with this parameter calls mmc->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, ...) to

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 of do_mmcops today .. } 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
#76 lore raw

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.

[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, then simple_strtoul and with this parameter calls mmc->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, ...) to

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 of do_mmcops today .. } 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
#77 lore raw

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.

[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, 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

Quoted 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 of do_mmcops today .. } 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

#78 lore raw

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

#79 lore raw

PATCH v2 4/7 dfu: MMC specific routines for DFU operation

In reply to Lukasz Majewski

Dear 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.
#80 lore raw

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 of dfu_device_type and dfu_layout to 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

#81 lore raw

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 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.

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
#82 lore raw

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 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.

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

#83 lore raw

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.
#84 lore raw

PATCH v2 4/7 dfu: MMC specific routines for DFU operation

In reply to Wolfgang Denk

Dear 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", (unsigned

int) 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 of dfu_device_type and dfu_layout to 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
#85 lore raw

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 Armstrong
#86 lore raw

PATCH v2 5/7 dfu:cmd: Support for DFU u-boot command

In reply to Lukasz Majewski

Support 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
index 31175e3..9d60fe1 100644
@@ -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
#87 lore raw

PATCH v2 6/7 arm:trats: Support for USB UDC driver at TRATS board.

In reply to Lukasz Majewski

Support 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
index a95a516..a557e5c 100644
@@ -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
#88 lore raw

PATCH v2 7/7 arm:trats: Enable g_dnl composite USB gadget with embedded DFU function on TRATS

In reply to Lukasz Majewski

Enable 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
index eb269b2..a24e73d 100644
@@ -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
#89 lore raw

v2 cover dfu:usb: Composite USB download gadget with DFU function

In reply to 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/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

Quoted 9 lines

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

Do you have more comments about those patches?

Signature · 5 lines
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group
#90 lore raw

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/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

Quoted 9 lines

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

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>
#91 lore raw

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/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

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

#92 lore raw

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/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

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
#93 lore raw

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

#94 lore raw

cover dfu:usb: Composite USB download gadget with DFU function

In reply to Lukasz Majewski

Dear 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/dfu directory. 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

#95 lore raw

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/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).

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
#96 lore raw

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/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).

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 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.c to 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

#97 lore raw

v3 cover dfu:usb: DFU support via USB Download gadget

In reply to Lukasz Majewski

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 |    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
#98 lore raw

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
index 87d1918..2c067c8 100644
@@ -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
new file mode 100644
index 0000000..d65214f
@@ -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
#99 lore raw

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>

#100 lore raw

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 *) &(struct

usb_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 struct usb_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 struct usb_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
#101 lore raw

PATCH v3 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget

In reply to Lukasz Majewski

Support 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
index 2c067c8..5bbdd36 100644
@@ -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
#102 lore raw

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>

#103 lore raw

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 struct usb_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_descriptor dev_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
#104 lore raw

PATCH v3 3/7 dfu: DFU backend implementation

In reply to Lukasz Majewski

New, 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
index d57c15e..bd469f4 100644
@@ -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
#105 lore raw

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>

#106 lore raw

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 the memset() 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
#107 lore raw

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>

#108 lore raw

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

#109 lore raw

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>

#110 lore raw

PATCH v3 4/7 dfu: MMC specific routines for DFU operation

In reply to Lukasz Majewski

Support 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
index 7736485..7b717bc 100644
@@ -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
#111 lore raw

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>

#112 lore raw

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_command so 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
#113 lore raw

PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command

In reply to Lukasz Majewski

Support 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
index 483eb4d..32d44e5 100644
@@ -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
#114 lore raw

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).

#115 lore raw

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
#116 lore raw

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?

#117 lore raw

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
#118 lore raw

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] 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".

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.

#119 lore raw

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/sdb for boot0, /dev/sdc for boot1, /dev/sdd for 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
#120 lore raw

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.

#121 lore raw

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
#122 lore raw

PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command

In reply to Lukasz Majewski

common/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>

#123 lore raw

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

#124 lore raw

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
#125 lore raw

PATCH v3 5/7 dfu:cmd: Support for DFU u-boot command

In reply to Marek Vasut
Quoted 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>

#126 lore raw

PATCH v3 6/7 arm:trats: Support for USB UDC driver at TRATS board.

In reply to Lukasz Majewski

Support 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
index a8b2b11..4f9cb5a 100644
@@ -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
#127 lore raw

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.

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
#128 lore raw

PATCH v3 7/7 arm:trats: Enable g_dnl composite USB gadget with embedded DFU function on TRATS

In reply to Lukasz Majewski

Enable 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
index eb269b2..75a23b0 100644
@@ -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
#129 lore raw

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_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

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
#130 lore raw

v4 cover dfu:usb: DFU support via USB Download gadget

In reply to Lukasz Majewski

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 |    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
#131 lore raw

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
index 87d1918..2c067c8 100644
@@ -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
new file mode 100644
index 0000000..0ec7440
@@ -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
#132 lore raw

PATCH v4 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget

In reply to Lukasz Majewski

Support 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
index 2c067c8..5bbdd36 100644
@@ -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
#133 lore raw

PATCH v4 3/7 dfu: DFU backend implementation

In reply to Lukasz Majewski

New, 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
index eb37ea1..67c627d 100644
@@ -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
#134 lore raw

PATCH v4 4/7 dfu: MMC specific routines for DFU operation

In reply to Lukasz Majewski

Support 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
index 7736485..7b717bc 100644
@@ -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
#135 lore raw

PATCH v4 5/7 dfu:cmd: Support for DFU u-boot command

In reply to Lukasz Majewski

Support 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
index 483eb4d..32d44e5 100644
@@ -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
#136 lore raw

PATCH v4 6/7 arm:trats: Support for USB UDC driver at TRATS board.

In reply to Lukasz Majewski

Support 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
index a8b2b11..4f9cb5a 100644
@@ -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
#137 lore raw

PATCH v4 7/7 arm:trats: Enable g_dnl composite USB gadget with embedded DFU function on TRATS

In reply to Lukasz Majewski

Enable 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
index eb269b2..75a23b0 100644
@@ -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
#138 lore raw

v5 cover dfu:usb: DFU support via USB Download gadget

In reply to Lukasz Majewski

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 |    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
#139 lore raw

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
index 87d1918..2c067c8 100644
@@ -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
new file mode 100644
index 0000000..0ec7440
@@ -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
#140 lore raw

PATCH v5 2/7 dfu:usb: DFU USB function (f_dfu) support for g_dnl composite gadget

In reply to Lukasz Majewski

Support 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
index 2c067c8..5bbdd36 100644
@@ -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
#141 lore raw

PATCH v5 3/7 dfu: DFU backend implementation

In reply to Lukasz Majewski

New, 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
index eb37ea1..67c627d 100644
@@ -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
#142 lore raw

PATCH v5 4/7 dfu: MMC specific routines for DFU operation

In reply to Lukasz Majewski

Support 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
index 7736485..7b717bc 100644
@@ -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
#143 lore raw

PATCH v5 5/7 dfu:cmd: Support for DFU u-boot command

In reply to Lukasz Majewski

Support 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
index 483eb4d..32d44e5 100644
@@ -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
#144 lore raw

PATCH v5 6/7 arm:trats: Support for USB UDC driver at TRATS board.

In reply to Lukasz Majewski

Support 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
index a8b2b11..4f9cb5a 100644
@@ -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
#145 lore raw

PATCH v5 7/7 arm:trats: Enable g_dnl composite USB gadget with embedded DFU function on TRATS

In reply to Lukasz Majewski

Enable 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
index eb269b2..75a23b0 100644
@@ -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
#146 lore raw

v5 cover dfu:usb: DFU support via USB Download gadget

In reply to Lukasz Majewski

Dear 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/dfu directory. 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