From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lukasz Majewski <l.majewski@samsung.com>
Date: Fri, 27 Jul 2012 15:15:23 +0200
Subject: [U-Boot] [PATCH v2 3/7] dfu: DFU backend implementation
In-Reply-To: <20120727115848.5D50E200347@gemini.denx.de>
References: <1341308291-14663-1-git-send-email-l.majewski@samsung.com>
	<1341416922-13792-1-git-send-email-l.majewski@samsung.com>
	<1341416922-13792-4-git-send-email-l.majewski@samsung.com>
	<20120727115848.5D50E200347@gemini.denx.de>
Message-ID: <20120727151523.41406989@amdc308.digital.local>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Wolfgang Denk,

> Dear Lukasz Majewski,
> 
> In message <1341416922-13792-4-git-send-email-l.majewski@samsung.com>
> 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?

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



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

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

Ok, no problem with this.

> 
> 
> Best regards,
> 
> Wolfgang Denk
> 



-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group