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

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

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;

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 Mohammedafzal.mohd.ma@gmail.com Cc: Heiko Schocherhs@denx.de Cc: Marek Vasutmarex@denx.de Cc: Lukasz Majewskil.majewski@samsung.com Cc: Pantelis Antonioupanto@antoniou-consulting.com Acked-by: Lukasz Majewskil.majewski@samsung.com Acked-by: Marek Vasutmarex@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

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

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 Mohammedafzal.mohd.ma@gmail.com Cc: Heiko Schocherhs@denx.de Cc: Marek Vasutmarex@denx.de Cc: Lukasz Majewskil.majewski@samsung.com Cc: Pantelis Antonioupanto@antoniou-consulting.com Cc: Gerhard Sittiggsi@denx.de Acked-by: Marek Vasutmarex@denx.de Acked-by: Lukasz Majewskil.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

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

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.

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
participants (3)
-
Afzal Mohammed
-
Heiko Schocher
-
Marek Vasut