From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lukasz Majewski <l.majewski@samsung.com>
Date: Wed, 01 Aug 2012 09:16:47 +0200
Subject: [U-Boot] [PATCH v3 5/7] dfu:cmd: Support for DFU u-boot command
In-Reply-To: <50181267.7000005@wwwdotorg.org>
References: <1341308291-14663-1-git-send-email-l.majewski@samsung.com>
	<1343716623-8943-1-git-send-email-l.majewski@samsung.com>
	<1343716623-8943-6-git-send-email-l.majewski@samsung.com>
	<50181267.7000005@wwwdotorg.org>
Message-ID: <20120801091647.6a8ba9d5@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

Hi Stephen Warren,

> On 07/31/2012 12:37 AM, Lukasz Majewski wrote:
> > Support for u-boot's "dfu <interface> <dev> [list]" command.
> 
> > +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.

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

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

-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group