[U-Boot] [PATCH v4 0/3] dfu ram support

[U-Boot] [PATCH v4 0/3] dfu ram support

[Afzal Mohammed]

Hi,

DFU spec mentions it as a method to upgrade firmware (software stored
in writable non-volatile memory). It also says other potential uses of
DFU is beyond scope of the spec.

Here such a beyond the scope use is being attempted - directly pumping
binary images from host via USB to RAM. This facility is a developer
centric one in that it gives advantage over upgrading non-volatile
memory for testing new images every time during development and/or
testing.

Directly putting image onto RAM would speed up upgrade process. This and
convenience was the initial thoughts that led to doing this, speed
improvement over MMC was only 1 second though - 6 sec on RAM as opposed
to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing
DFU framework to avoid multiple copy for ram (if worth) may help, and
on other platforms and other boot media like NAND maybe improvement
would be higher.

And for a platform that doesn't yet have proper DFU suppport for
non-volatile media's, DFU to RAM can be used.

Another minor advantage would be to increase life of mmc/nand as it
would be less used during development/testing.

usage: <image name> ram <start address> <size>
eg. kernel ram 0x81000000 0x1000000

Downloading images to RAM using DFU is not something new, this is
acheived in openmoko also.

DFU on RAM can be used for extracting RAM contents to host using dfu
upload. Perhaps this can be extended to io for squeezing out register
dump through usb, if it is worth.

In addition to ram support, a minor unification of dfu read/write enum's
currently duplicated in mmc/nand is done, helping ram support too.

Also dfu ram support is added for am335x SoC based boards.

Based on: usb master branch

Regards
Afzal

v4:
    avoid doing prefix increment in argument of simple_strtoul()
    collect more tags
v3: collected tags, error used instead of printf
v2: unified read/write dfu ops enum, added am335x support


Afzal Mohammed (3):
  dfu: unify mmc/nand read/write ops enum
  dfu: ram support
  am335x_evm: enable DFU RAM

 drivers/dfu/Makefile         |  1 +
 drivers/dfu/dfu.c            |  7 ++--
 drivers/dfu/dfu_mmc.c        |  9 ++----
 drivers/dfu/dfu_nand.c       |  7 +---
 drivers/dfu/dfu_ram.c        | 77 ++++++++++++++++++++++++++++++++++++++++++++
 include/configs/am335x_evm.h |  6 ++++
 include/dfu.h                | 23 +++++++++++++
 7 files changed, 115 insertions(+), 15 deletions(-)
 create mode 100644 drivers/dfu/dfu_ram.c

-- 
1.8.2.135.g7b592fa

[U-Boot] [PATCH v4 1/3] dfu: unify mmc/nand read/write ops enum

[Afzal Mohammed]

MMC and NAND independently defines same enumerators for read/write.
Unify them by defining enum in dfu header. RAM support that is being
added newly also can make use of it.

Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Acked-by: Marek Vasut <marex@denx.de>
---

v4: collect more tag
v3: collected tag
v2: new

 drivers/dfu/dfu_mmc.c  | 9 ++-------
 drivers/dfu/dfu_nand.c | 7 +------
 include/dfu.h          | 5 +++++
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 0871a77..f942758 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -13,16 +13,11 @@
 #include <div64.h>
 #include <dfu.h>
 
-enum dfu_mmc_op {
-	DFU_OP_READ = 1,
-	DFU_OP_WRITE,
-};
-
 static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
 				dfu_file_buf[CONFIG_SYS_DFU_MAX_FILE_SIZE];
 static long dfu_file_buf_len;
 
-static int mmc_block_op(enum dfu_mmc_op op, struct dfu_entity *dfu,
+static int mmc_block_op(enum dfu_op op, struct dfu_entity *dfu,
 			u64 offset, void *buf, long *len)
 {
 	char cmd_buf[DFU_CMD_BUF_SIZE];
@@ -65,7 +60,7 @@ static int mmc_file_buffer(struct dfu_entity *dfu, void *buf, long *len)
 	return 0;
 }
 
-static int mmc_file_op(enum dfu_mmc_op op, struct dfu_entity *dfu,
+static int mmc_file_op(enum dfu_op op, struct dfu_entity *dfu,
 			void *buf, long *len)
 {
 	char cmd_buf[DFU_CMD_BUF_SIZE];
diff --git a/drivers/dfu/dfu_nand.c b/drivers/dfu/dfu_nand.c
index 0ec12cf..edbf5a9 100644
--- a/drivers/dfu/dfu_nand.c
+++ b/drivers/dfu/dfu_nand.c
@@ -19,12 +19,7 @@
 #include <jffs2/load_kernel.h>
 #include <nand.h>
 
-enum dfu_nand_op {
-	DFU_OP_READ = 1,
-	DFU_OP_WRITE,
-};
-
-static int nand_block_op(enum dfu_nand_op op, struct dfu_entity *dfu,
+static int nand_block_op(enum dfu_op op, struct dfu_entity *dfu,
 			u64 offset, void *buf, long *len)
 {
 	loff_t start, lim;
diff --git a/include/dfu.h b/include/dfu.h
index 392cef1..6a3e253 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -29,6 +29,11 @@ enum dfu_layout {
 	DFU_FS_EXT4,
 };
 
+enum dfu_op {
+	DFU_OP_READ = 1,
+	DFU_OP_WRITE,
+};
+
 struct mmc_internal_data {
 	/* RAW programming */
 	unsigned int lba_start;
-- 
1.8.2.135.g7b592fa

[U-Boot] [PATCH v4 2/3] dfu: ram support

[Afzal Mohammed]

DFU spec mentions it as a method to upgrade firmware (software stored
in writable non-volatile memory). It also says other potential uses of
DFU is beyond scope of the spec.

Here such a beyond the scope use is being attempted - directly pumping
binary images from host via USB to RAM. This facility is a developer
centric one in that it gives advantage over upgrading non-volatile
memory for testing new images every time during development and/or
testing.

Directly putting image onto RAM would speed up upgrade process. This and
convenience was the initial thoughts that led to doing this, speed
improvement over MMC was only 1 second though - 6 sec on RAM as opposed
to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing
DFU framework to avoid multiple copy for ram (if worth) may help, and
on other platforms and other boot media like NAND maybe improvement
would be higher.

And for a platform that doesn't yet have proper DFU suppport for
non-volatile media's, DFU to RAM can be used.

Another minor advantage would be to increase life of mmc/nand as it
would be less used during development/testing.

usage: <image name> ram <start address> <size>
eg. kernel ram 0x81000000 0x1000000

Downloading images to RAM using DFU is not something new, this is
acheived in openmoko also.

DFU on RAM can be used for extracting RAM contents to host using dfu
upload. Perhaps this can be extended to io for squeezing out register
dump through usb, if it is worth.

Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Gerhard Sittig <gsi@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
---

v4:
    avoid doing prefix increment in argument of simple_strtoul()
    collect more tags
v3: error used instead of printf
v2: remove read/write enumerator define's, instead use new common ones

 drivers/dfu/Makefile  |  1 +
 drivers/dfu/dfu.c     |  7 +++--
 drivers/dfu/dfu_ram.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++
 include/dfu.h         | 18 ++++++++++++
 4 files changed, 101 insertions(+), 2 deletions(-)
 create mode 100644 drivers/dfu/dfu_ram.c

diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
index fca370a..de9e44e 100644
--- a/drivers/dfu/Makefile
+++ b/drivers/dfu/Makefile
@@ -12,6 +12,7 @@ LIB	= $(obj)libdfu.o
 COBJS-$(CONFIG_DFU_FUNCTION) += dfu.o
 COBJS-$(CONFIG_DFU_MMC) += dfu_mmc.o
 COBJS-$(CONFIG_DFU_NAND) += dfu_nand.o
+COBJS-$(CONFIG_DFU_RAM) += dfu_ram.o
 
 SRCS    := $(COBJS-y:.o=.c)
 OBJS	:= $(addprefix $(obj),$(COBJS-y))
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 689f5db..56b21c7 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -348,6 +348,9 @@ static int dfu_fill_entity(struct dfu_entity *dfu, char *s, int alt,
 	} else if (strcmp(interface, "nand") == 0) {
 		if (dfu_fill_entity_nand(dfu, s))
 			return -1;
+	} else if (strcmp(interface, "ram") == 0) {
+		if (dfu_fill_entity_ram(dfu, s))
+			return -1;
 	} else {
 		printf("%s: Device %s not (yet) supported!\n",
 		       __func__,  interface);
@@ -397,14 +400,14 @@ int dfu_config_entities(char *env, char *interface, int num)
 
 const char *dfu_get_dev_type(enum dfu_device_type t)
 {
-	const char *dev_t[] = {NULL, "eMMC", "OneNAND", "NAND" };
+	const char *dev_t[] = {NULL, "eMMC", "OneNAND", "NAND", "RAM" };
 	return dev_t[t];
 }
 
 const char *dfu_get_layout(enum dfu_layout l)
 {
 	const char *dfu_layout[] = {NULL, "RAW_ADDR", "FAT", "EXT2",
-					   "EXT3", "EXT4" };
+					   "EXT3", "EXT4", "RAM_ADDR" };
 	return dfu_layout[l];
 }
 
diff --git a/drivers/dfu/dfu_ram.c b/drivers/dfu/dfu_ram.c
new file mode 100644
index 0000000..335a8e1
--- /dev/null
+++ b/drivers/dfu/dfu_ram.c
@@ -0,0 +1,77 @@
+/*
+ * (C) Copyright 2013
+ * Afzal Mohammed <afzal.mohd.ma@gmail.com>
+ *
+ * Reference: dfu_mmc.c
+ * Copyright (C) 2012 Samsung Electronics
+ * author: Lukasz Majewski <l.majewski@samsung.com>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <malloc.h>
+#include <errno.h>
+#include <dfu.h>
+
+static int dfu_transfer_medium_ram(enum dfu_op op, struct dfu_entity *dfu,
+				   u64 offset, void *buf, long *len)
+{
+	if (dfu->layout != DFU_RAM_ADDR) {
+		error("unsupported layout: %s\n", dfu_get_layout(dfu->layout));
+		return  -EINVAL;
+	}
+
+	if (offset > dfu->data.ram.size) {
+		error("request exceeds allowed area\n");
+		return -EINVAL;
+	}
+
+	if (op == DFU_OP_WRITE)
+		memcpy(dfu->data.ram.start + offset, buf, *len);
+	else
+		memcpy(buf, dfu->data.ram.start + offset, *len);
+
+	return 0;
+}
+
+static int dfu_write_medium_ram(struct dfu_entity *dfu, u64 offset,
+				void *buf, long *len)
+{
+	return dfu_transfer_medium_ram(DFU_OP_WRITE, dfu, offset, buf, len);
+}
+
+static int dfu_read_medium_ram(struct dfu_entity *dfu, u64 offset,
+			       void *buf, long *len)
+{
+	if (!*len) {
+		*len = dfu->data.ram.size;
+		return 0;
+	}
+
+	return dfu_transfer_medium_ram(DFU_OP_READ, dfu, offset, buf, len);
+}
+
+int dfu_fill_entity_ram(struct dfu_entity *dfu, char *s)
+{
+	char *st;
+
+	dfu->dev_type = DFU_DEV_RAM;
+	st = strsep(&s, " ");
+	if (strcmp(st, "ram")) {
+		error("unsupported device: %s\n", st);
+		return -ENODEV;
+	}
+
+	dfu->layout = DFU_RAM_ADDR;
+	dfu->data.ram.start = (void *)simple_strtoul(s, &s, 16);
+	s++;
+	dfu->data.ram.size = simple_strtoul(s, &s, 16);
+
+	dfu->write_medium = dfu_write_medium_ram;
+	dfu->read_medium = dfu_read_medium_ram;
+
+	dfu->inited = 0;
+
+	return 0;
+}
diff --git a/include/dfu.h b/include/dfu.h
index 6a3e253..6f4bba4 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -19,6 +19,7 @@ enum dfu_device_type {
 	DFU_DEV_MMC = 1,
 	DFU_DEV_ONENAND,
 	DFU_DEV_NAND,
+	DFU_DEV_RAM,
 };
 
 enum dfu_layout {
@@ -27,6 +28,7 @@ enum dfu_layout {
 	DFU_FS_EXT2,
 	DFU_FS_EXT3,
 	DFU_FS_EXT4,
+	DFU_RAM_ADDR,
 };
 
 enum dfu_op {
@@ -56,6 +58,11 @@ struct nand_internal_data {
 	unsigned int ubi;
 };
 
+struct ram_internal_data {
+	void		*start;
+	unsigned int	size;
+};
+
 static inline unsigned int get_mmc_blk_size(int dev)
 {
 	return find_mmc_device(dev)->read_bl_len;
@@ -81,6 +88,7 @@ struct dfu_entity {
 	union {
 		struct mmc_internal_data mmc;
 		struct nand_internal_data nand;
+		struct ram_internal_data ram;
 	} data;
 
 	int (*read_medium)(struct dfu_entity *dfu,
@@ -143,4 +151,14 @@ static inline int dfu_fill_entity_nand(struct dfu_entity *dfu, char *s)
 }
 #endif
 
+#ifdef CONFIG_DFU_RAM
+extern int dfu_fill_entity_ram(struct dfu_entity *dfu, char *s);
+#else
+static inline int dfu_fill_entity_ram(struct dfu_entity *dfu, char *s)
+{
+	puts("RAM support not available!\n");
+	return -1;
+}
+#endif
+
 #endif /* __DFU_ENTITY_H_ */
-- 
1.8.2.135.g7b592fa

[U-Boot] [PATCH v4 3/3] am335x_evm: enable DFU RAM

[Afzal Mohammed]

Enable DFU for RAM, provide example dfu_alt_info

Signed-off-by: Afzal Mohammed <afzal.mohd.ma@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Lukasz Majewski <l.majewski@samsung.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
---

v3: collected tag
v2: new

 include/configs/am335x_evm.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 3de30fc..978fdf9 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -100,6 +100,7 @@
 	"loadbootenv=load mmc ${mmcdev} ${loadaddr} ${bootenv}\0" \
 	"importbootenv=echo Importing environment from mmc ...; " \
 		"env import -t $loadaddr $filesize\0" \
+	"dfu_alt_info_ram=" DFU_ALT_INFO_RAM "\0" \
 	"ramargs=setenv bootargs console=${console} " \
 		"${optargs} " \
 		"root=${ramroot} " \
@@ -321,6 +322,11 @@
 	"kernel part 0 8;" \
 	"rootfs part 0 9"
 #endif
+#define CONFIG_DFU_RAM
+#define DFU_ALT_INFO_RAM \
+	"kernel ram 0x80200000 0xD80000;" \
+	"fdt ram 0x80F80000 0x80000;" \
+	"ramdisk ram 0x81000000 0x4000000"
 
 /*
  * Default to using SPI for environment, etc.
-- 
1.8.2.135.g7b592fa

[U-Boot] [PATCH v4 0/3] dfu ram support

[Marek Vasut]

Dear Afzal Mohammed,

> Hi,
> 
> DFU spec mentions it as a method to upgrade firmware (software stored
> in writable non-volatile memory). It also says other potential uses of
> DFU is beyond scope of the spec.
> 
> Here such a beyond the scope use is being attempted - directly pumping
> binary images from host via USB to RAM. This facility is a developer
> centric one in that it gives advantage over upgrading non-volatile
> memory for testing new images every time during development and/or
> testing.
> 
> Directly putting image onto RAM would speed up upgrade process. This and
> convenience was the initial thoughts that led to doing this, speed
> improvement over MMC was only 1 second though - 6 sec on RAM as opposed
> to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing
> DFU framework to avoid multiple copy for ram (if worth) may help, and
> on other platforms and other boot media like NAND maybe improvement
> would be higher.
> 
> And for a platform that doesn't yet have proper DFU suppport for
> non-volatile media's, DFU to RAM can be used.
> 
> Another minor advantage would be to increase life of mmc/nand as it
> would be less used during development/testing.
> 
> usage: <image name> ram <start address> <size>
> eg. kernel ram 0x81000000 0x1000000
> 
> Downloading images to RAM using DFU is not something new, this is
> acheived in openmoko also.
> 
> DFU on RAM can be used for extracting RAM contents to host using dfu
> upload. Perhaps this can be extended to io for squeezing out register
> dump through usb, if it is worth.
> 
> In addition to ram support, a minor unification of dfu read/write enum's
> currently duplicated in mmc/nand is done, helping ram support too.
> 
> Also dfu ram support is added for am335x SoC based boards.
> 
> Based on: usb master branch
> 
> Regards
> Afzal

Will wait for Heiko's ACK and then apply for -next.

Best regards,
Marek Vasut

[U-Boot] [PATCH v4 1/3] dfu: unify mmc/nand read/write ops enum

[Heiko Schocher]

Hello Afzal,

Sorry for the late replay ...

Am 13.09.2013 18:59, schrieb Afzal Mohammed:
> MMC and NAND independently defines same enumerators for read/write.
> Unify them by defining enum in dfu header. RAM support that is being
> added newly also can make use of it.
>
> Signed-off-by: Afzal Mohammed<afzal.mohd.ma@gmail.com>
> Cc: Heiko Schocher<hs@denx.de>
> Cc: Marek Vasut<marex@denx.de>
> Cc: Lukasz Majewski<l.majewski@samsung.com>
> Cc: Pantelis Antoniou<panto@antoniou-consulting.com>
> Acked-by: Lukasz Majewski<l.majewski@samsung.com>
> Acked-by: Marek Vasut<marex@denx.de>
> ---
>
> v4: collect more tag
> v3: collected tag
> v2: new
>
>   drivers/dfu/dfu_mmc.c  | 9 ++-------
>   drivers/dfu/dfu_nand.c | 7 +------
>   include/dfu.h          | 5 +++++
>   3 files changed, 8 insertions(+), 13 deletions(-)

Thanks!

Acked-by: Heiko Schocher <hs@denx.de>

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH v4 2/3] dfu: ram support

[Heiko Schocher]

Hello Afzal,

Am 13.09.2013 19:00, schrieb Afzal Mohammed:
> DFU spec mentions it as a method to upgrade firmware (software stored
> in writable non-volatile memory). It also says other potential uses of
> DFU is beyond scope of the spec.
>
> Here such a beyond the scope use is being attempted - directly pumping
> binary images from host via USB to RAM. This facility is a developer
> centric one in that it gives advantage over upgrading non-volatile
> memory for testing new images every time during development and/or
> testing.
>
> Directly putting image onto RAM would speed up upgrade process. This and
> convenience was the initial thoughts that led to doing this, speed
> improvement over MMC was only 1 second though - 6 sec on RAM as opposed
> to 7 sec on MMC in beagle bone, perhaps enabling cache and/or optimizing
> DFU framework to avoid multiple copy for ram (if worth) may help, and
> on other platforms and other boot media like NAND maybe improvement
> would be higher.
>
> And for a platform that doesn't yet have proper DFU suppport for
> non-volatile media's, DFU to RAM can be used.
>
> Another minor advantage would be to increase life of mmc/nand as it
> would be less used during development/testing.
>
> usage:<image name>  ram<start address>  <size>
> eg. kernel ram 0x81000000 0x1000000
>
> Downloading images to RAM using DFU is not something new, this is
> acheived in openmoko also.
>
> DFU on RAM can be used for extracting RAM contents to host using dfu
> upload. Perhaps this can be extended to io for squeezing out register
> dump through usb, if it is worth.
>
> Signed-off-by: Afzal Mohammed<afzal.mohd.ma@gmail.com>
> Cc: Heiko Schocher<hs@denx.de>
> Cc: Marek Vasut<marex@denx.de>
> Cc: Lukasz Majewski<l.majewski@samsung.com>
> Cc: Pantelis Antoniou<panto@antoniou-consulting.com>
> Cc: Gerhard Sittig<gsi@denx.de>
> Acked-by: Marek Vasut<marex@denx.de>
> Acked-by: Lukasz Majewski<l.majewski@samsung.com>
> ---
>
> v4:
>      avoid doing prefix increment in argument of simple_strtoul()
>      collect more tags
> v3: error used instead of printf
> v2: remove read/write enumerator define's, instead use new common ones
>
>   drivers/dfu/Makefile  |  1 +
>   drivers/dfu/dfu.c     |  7 +++--
>   drivers/dfu/dfu_ram.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++
>   include/dfu.h         | 18 ++++++++++++
>   4 files changed, 101 insertions(+), 2 deletions(-)
>   create mode 100644 drivers/dfu/dfu_ram.c

Thanks for this work! Hmm... minor comment. Could you add a entry in
README?

Beside of that:

Acked-by: Heiko Schocher <hs@denx.de>

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [PATCH v4 2/3] dfu: ram support

[Afzal Mohammed]

Hi Heiko,

On Tue, Sep 17, 2013 at 06:32:37AM +0200, Heiko Schocher wrote:

> Thanks for this work! Hmm... minor comment. Could you add a entry in
> README?
> 
> Beside of that:
> 
> Acked-by: Heiko Schocher <hs@denx.de>

Thanks, v5 has been posted with README entry.

Regards
Afzal